index.html 99 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta content="text/html; charset=UTF-8" http-equiv="Content-Type" /><title>Requirement For Standardizing Widgets</title><link href="style/widgets.css" rel="stylesheet" type="text/css" /><link href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" rel="stylesheet" type="text/css" /></head><body>
<div class="head">
<a href="http://www.w3.org/"><img alt="W3C" height="48" src="http://www.w3.org/Icons/w3c_home" width="72" /></a>

<h1> Requirement For Standardizing Widgets</h1>

<h2 class="no-num no-toc" id="w3c-working-group-note-27-september-2011">W3C Working Group Note 27 September 2011</h2>

<dl><dt>This version:</dt>

<dd><a href="http://www.w3.org/TR/2011/NOTE-widgets-reqs-20110927/">http://www.w3.org/TR/2011/NOTE-widgets-reqs-20110927/</a></dd>

<dt>Latest published version:</dt>

<dd><a href="http://www.w3.org/TR/widgets-reqs/">http://www.w3.org/TR/widgets-reqs/</a></dd>

<dt>Previous versions:</dt>
<dd><a href="http://www.w3.org/TR/2010/WD-widgets-reqs-20101026/">http://www.w3.org/TR/2010/WD-widgets-reqs-20101026/</a></dd>


<dt>Latest editor's draft:</dt>
<dd><a href="http://dev.w3.org/2006/waf/widgets-reqs/">http://dev.w3.org/2006/waf/widgets-reqs/</a></dd>
<dt>Editor:</dt>
<dd><a href="http://marcosc.com/">Marcos Cáceres</a></dd>
</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2011 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
<hr /></div>

<h2 class="no-num no-toc" id="abstract">Abstract</h2>

<p>This document lists the design goals and requirements that specifications would need
to address in order to standardize various aspects of widgets. A <em><a href="#widget">Widget</a></em> is an
interactive single purpose application for displaying and/or updating local data or data
on the Web, packaged in a way to allow a single download and installation on a user's
machine or mobile device. Typical examples of widgets include clocks, CPU gauges, sticky
notes, battery-life indicators, games, and widgets that make use of Web services, like
weather forecasters, news readers, e-mail checkers, photo albums, and currency
converters. </p>

<h2 class="no-num no-toc" id="status">Status of this Document</h2>
<p><em>This section describes the status of this document at the time of its publication.
  Other documents may supersede this document. A list of current W3C publications and the
  latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at
http://www.w3.org/TR/.</em></p>
<p>Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p>
<p>This document reflects three years of gathering and refining requirements
  for the <a href="#widget-family-of-specifications">Widget family of specifications</a>. The requirements were gathered by extensive
  consultation with W3C members and the public, via the Working Group's mailing lists
  (<a href="http://lists.w3.org/Archives/Public/public-appformats/">WAF archive</a>,

  <a href="http://lists.w3.org/Archives/Public/public-webapps/">WebApps archive</a>).  The Working Group's goal is to make sure
  that vendor's requirements for Widgets are complete and have been effectively captured.
  The <a href="#widget-family-of-specifications">Widget family of specifications</a> will set out to address as many requirements as
  possible (particularly the ones marked with the keywords <em class="ct">must</em> and
<em class="ct">should</em>).</p>

<p>This document is produced by the <a href="http://www.w3.org/2008/webapps/">Web
Applications</a> (WebApps) Working Group (WG). This <abbr title="Working Group">WG</abbr>
is part of the <a href="http://www.w3.org/2006/rwc/Activity">Rich Web Clients
Activity</a> and this activity is within the W3C's <a href="http://www.w3.org/Interaction/">Interaction Domain</a>. The public is encouraged to send
comments to the WebApps Working Group's public mailing list <a href="mailto:public-webapps@w3.org">public-webapps@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/public-webapps/">archive</a>). See <a href="http://www.w3.org/Mail/">W3C mailing list and archive usage guidelines</a>.</p>

<p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent
Policy</a>. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/42538/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the
deliverables of the group; that page also includes instructions for disclosing a patent.
An individual who has actual knowledge of a patent which the individual believes contains
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the
W3C Patent Policy</a>.</p>

<h2 class="no-num no-toc" id="table-of-contents">Table of Contents</h2><!--begin-toc-->
<ol class="toc">
 <li><a href="#introduction"><span class="secno">1 </span>Introduction</a></li>
 <li><a href="#conformance"><span class="secno">2 </span>Conformance</a></li>
 <li><a href="#design-goals"><span class="secno">3 </span>Design Goals</a></li>
 <li><a href="#requirements"><span class="secno">4 </span>Requirements</a>
  <ol class="toc">
   <li><a href="#packaging"><span class="secno">4.1 </span>Packaging</a>
    <ol class="toc">
     <li><a class="no-num req" href="#packaging-format">Packaging Format</a></li>
     <li><a class="no-num req" href="#media-type">Media Type</a></li>
     <li><a class="no-num req" href="#file-extension">File Extension</a></li>
     <li><a class="no-num req" href="#internal-abstract-structure">Internal Abstract Structure</a></li>
     <li><a class="no-num req" href="#reserved-resource-names">Reserved Resource Names</a></li>
     <li><a class="no-num req" href="#addressing-scheme">Addressing Scheme</a></li>
     <li><a class="no-num req" href="#multilingual-file-names">Multilingual File Names</a></li>
     <li><a class="no-num req" href="#localization-guidelines">Localization Guidelines</a></li>
     <li><a class="no-num req" href="#automatic-localization">Automatic Localization</a></li>
     <li><a class="no-num req" href="#device-independent-delivery">Device Independent Delivery</a></li>
     <li><a class="no-num req" href="#data-compression">Data Compression</a></li>
     <li><a class="no-num req" href="#derive-the-media-type-of-resources">Derive the Media Type of Resources </a></li></ol></li>
   <li><a href="#configuration-document"><span class="secno">4.2 </span>Configuration Document</a>
    <ol class="toc">
     <li><a class="no-num req" href="#format-and-schema">Format
and Schema</a></li>
     <li><a class="no-num req" href="#widget-metadata">Widget Metadata</a></li>
     <li><a class="no-num req" href="#authorship-metadata">Authorship  Metadata</a></li>
     <li><a class="no-num req" href="#copyright-notice-and-license-metadata">Copyright Notice and License Metadata</a></li>
     <li><a class="no-num req" href="#visual-rendering-dimensions">Visual Rendering Dimensions</a></li>
     <li><a class="no-num req" href="#declarative-bootstrap">Declarative Bootstrap</a></li>
     <li><a class="no-num req" href="#automated-bootstrap">Automated Bootstrap</a></li>
     <li><a class="no-num req" href="#iconic-representations">Iconic Representations</a></li>
     <li><a class="no-num req" href="#configuration-parameters">Configuration Parameters</a></li>
     <li><a class="no-num req" href="#author-defined-start-up-values-preferences"><span>Author-defined Start-up Values</span> (Preferences)</a></li>
     <li><a class="no-num req" href="#feature-access-declarations">Feature Access Declarations</a></li>
     <li><a class="no-num req" href="#configuration-document-independence">Configuration Document Independence</a></li>
     <li><a class="no-num req" href="#preferred-display-mode">Preferred Display Mode</a></li></ol></li>
   <li><a href="#application-programming-interfaces"><span class="secno">4.3 </span>Application Programming Interfaces</a>
    <ol class="toc">
     <li><a class="no-num req" href="#instantiated-widget-api">Instantiated Widget API</a></li>
     <li><a class="no-num req" href="#idl-definitions">IDL Definitions</a></li>
     <li><a class="no-num req" href="#configuring-runtime-properties">Configuring Runtime Properties</a></li>
     <li><a class="no-num req" href="#manipulation-of-author-defined-start-up-values">Manipulation of <span>Author-defined Start-up Values</span></a></li>
     <li><a class="no-num req" href="#widget-state-change-events">Widget State Change Events</a></li>
     <li><a class="no-num req" href="#network-state-change-events">Network State Change Events</a></li>
     <li><a class="no-num req" href="#modal-priority">Modal Priority</a></li>
     <li><a class="no-num req" href="#device-specific-apis-and-services">Device Specific APIs and Services</a></li>
     <li><a class="no-num req" href="#configuration-document-data">Configuration Document Data</a></li>
     <li><a class="no-num req" href="#scheme-handler">Scheme Handler</a></li>
     <li><a class="no-num req" href="#resolve-addressing-scheme">Resolve Addressing Scheme</a></li>
     <li><a class="no-num req" href="#display-mode-api-and-events">Display mode API and Events</a></li></ol></li>
   <li><a href="#user-experience"><span class="secno">4.4 </span>User experience</a>
    <ol class="toc">
     <li><a class="no-num req" href="#user-interface-accessibility">User Interface Accessibility</a></li>
     <li><a class="no-num req" href="#display-modes">Display Modes</a></li></ol></li>
   <li><a href="#user-agents"><span class="secno">4.5 </span>User Agents</a>
    <ol class="toc">
     <li><a class="no-num req" href="#remote-and-local-updates">Remote and Local Updates</a></li>
     <li><a class="no-num req" href="#multiple-widget-instances">Multiple Widget Instances</a></li>
     <li><a class="no-num req" href="#display-mode-switching">Display Mode Switching</a></li></ol></li>
   <li><a href="#security-and-digital-signatures"><span class="secno">4.6 </span>Security and Digital Signatures</a>
    <ol class="toc">
     <li><a class="no-num req" href="#runtime-security-exceptions">Runtime Security Exceptions</a></li>
     <li><a class="no-num req" href="#digital-signatures">Digital Signatures</a></li>
     <li><a class="no-num req" href="#multiple-signatures-and-certificate-chains">Multiple Signatures and Certificate Chains</a></li>
     <li><a class="no-num req" href="#signature-document-format">Signature Document Format</a></li>
     <li><a class="no-num req" href="#support-for-multiple-message-digest-algorithms">Support for Multiple Message Digest Algorithms</a></li>
     <li><a class="no-num req" href="#support-for-multiple-signature-algorithms">Support for Multiple Signature Algorithms</a></li>
     <li><a class="no-num req" href="#key-lengths">Key Lengths</a></li>
     <li><a class="no-num req" href="#key-usage-extension">Key Usage Extension</a></li>
     <li><a class="no-num req" href="#inclusion-of-revocation-information">Inclusion of Revocation Information</a></li>
     <li><a class="no-num req" href="#default-security-policy">Default Security Policy</a></li>
     <li><a class="no-num req" href="#widget-black-white-listing">Widget Black/White Listing</a></li>
     <li><a class="no-num req" href="#security-declarations">Security Declarations</a></li></ol></li></ol></li>
 <li><a class="no-num" href="#references">References</a></li>
 <li><a class="no-num" href="#acknowledgments">Acknowledgments</a></li></ol><!--end-toc-->

<h2 id="introduction"><span class="secno">1 </span>Introduction</h2>

<p>A <dfn id="widget">widget</dfn> is an interactive single purpose application for displaying and/or
updating local data or data on the Web, packaged in a way to allow a single download and
installation on a user's machine or mobile device. A widget may run as a stand-alone
application (meaning it can run outside of a Web browser), and it is envisioned that the kind of widgets being standardized by this effort will one day be embedded into  Web
documents. </p>
<p>In this document, the runtime environment in which a widget is run is referred
  to as a <dfn id="widget-user-agent">widget user agent</dfn>. Note that running widgets may be the specific purpose of a widget user agent, or it may be a mode of operation of a more generic user agent (e.g. a Web browser). A widget running on a widget user agent is referred to as an
  <dfn id="instantiated-widget">instantiated widget</dfn>. Prior to instantiation, a widget exists as a <dfn id="widget-package">widget package</dfn>. </p>

<p>Prior to this standardization effort, there was no
  standardized way to author, package, digitally sign, or
internationalize a widget package for distribution and deployment on the Web. In the
widget space, although many  widget user agents are now on the market, widgets
built for one widget user agent (e.g., Windows 8 Metro applications) are still not able to run on any other widget user
agent (Apple's Dashboard). This document, along with the <a href="#widget-family-of-specifications">Widget family of specifications</a>, attempt to address the interoperability issues.</p>

<p>This document lists the design goals and requirements that specifications need to
address in order to standardize how widgets are authored/scripted, digitally signed,
secured, packaged and deployed in a way that is device independent, follows <a href="http://www.w3.org/Consortium/mission">W3C principles</a>, and is as interoperable as
possible with existing market-leading user agents and existing Web browsers.</p>

<p class="note">To be clear, this specification describes the requirements for
installable/desktop or mobile widgets (akin to <a href="http://en.wikipedia.org/wiki/Dashboard_(software)">Apple's Dashboard</a>, <a href="http://widgets.opera.com/">Opera Widgets</a>, Windows 8's Metro Applications). This document does not
address the requirements of &quot;web widgets&quot;, such as <a href="http://code.google.com/apis/gadgets/index.html">iGoogle Gadgets</a> or <a href="http://gallery.live.com/devcenter.aspx">Windows Live Gadgets</a>, which are being specified by the
Open Ajax Alliance's IDE Working Group. </p>

<h2 id="conformance"><span class="secno">2 </span>Conformance</h2>

<p><em>This section is normative.</em></p>

<p>The key words <em class="ct">MUST</em>, <em class="ct">MUST NOT</em>, <em class="ct">required</em>, <em class="ct">not required</em>, <em class="ct">SHOULD</em>,

<em class="ct">should not</em>, <em class="ct">recommended</em>, <em class="ct">MAY</em>,
and <em class="ct">optional</em> in the normative parts of this document are to be
interpreted as described in <cite><a href="#rfc2119">RFC2119</a></cite>.</p>

<p>This specification only applies to one class of product: W3C Technical Reports. The
Working Group will attempt to standardize widgets by addressing the
<a href="#requirements-0">requirements</a> listed in this document through the <dfn id="widget-family-of-specifications">Widget family of
specifications</dfn>, which include:</p>

<ul><li><cite><a href="#widgets1">Widget Packaging and
Configuration</a></cite></li>

<li><cite><a href="#widget-updates">Widget Updates</a></cite></li>

<li><cite><a href="#widgets3">Widget Interface</a></cite></li>

<li><cite><a href="#digital-signatures-for-widgets">Digital Signatures for Widgets</a></cite></li>
<li><cite><a href="#widget-uris">Widget URIs</a></cite></li>

<li><cite><a href="#view-modes">View Modes</a></cite></li>
</ul><p class="note"><strong> Only normative statements marked with the keywords <em class="ct">MUST</em> and <em class="ct">SHOULD</em> are required to be standardized
by the Widget family of specifications. The Working Group will publish an
informative Working Group Note at the end of the standardization process listing any
requirements that were not formally addressed by the Widget family of
specifications.</strong></p>

<p>Although a number of specifications will be created to address the requirements
enumerated in this document, in some instances, it will be the amalgamation of multiple
parts of individual specifications that address a single requirement. Nevertheless,
this document speaks only of a conforming specification (defined below). The Working Group's choice to have multiple specifications address the following requirements, as
opposed to having a monolithic specification, was made for the following
reasons:</p>

<ul><li>Easier for multiple editors to maintain and edit, as each can check in and out the
relevant specifications they are editing.</li>

<li>Easier for the Working Group to discuss during teleconferences and face-to-face
meetings.</li>

<li>Easier for the public and experts to review.</li>

<li>Easier for implementers to implement, as each specification will be as modular as
possible.</li>

<li>Easier to print, for the purpose of review.</li>
</ul><p>A <dfn id="conforming-specification">conforming specification</dfn> is one that addresses one or more requirements
listed in this document. A conforming specification <em class="ct">SHOULD</em> attempt to
address requirements marked with the keywords <em class="ct"><q>should</q></em> or

<em class="ct"><q>may</q></em> unless there is a technically valid reason not to do so.
The validity of technical reasons for not addressing any requirements will be determined
by the Working Group members, and through communication with vendors and the public on the
Working Group's public mailing list <a href="mailto:public-appformats@w3.org">public-webapps@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/public-webapps/">archive</a>).</p>

<h2 id="design-goals"><span class="secno">3 </span>Design Goals</h2>

<p><em>This section is informative.</em></p>

<p>This section lists the <dfn id="design-goals-0">design goals</dfn> that the Working Group recommends a
conforming specification adopt when attempting to standardize the various standardizable
aspects of widgets.
The requirements are directly motivated by the following design goals. The design goals
are listed in alphabetical order.</p>

<dl><dt><dfn id="accessibility">Accessibility</dfn>:</dt>

<dd>
  <p>A conforming specification needs to support relevant accessibility guidelines, such
    as <cite><a href="#wcag-2.0">WCAG 2.0</a></cite>.</p>
</dd>

<dt><dfn id="compatibility-with-other-standards">Compatibility with other standards</dfn>:</dt>

<dd>
  <p>A conforming specification needs to maintain compatibility with, or directly make use
    of, other standards where possible.</p>
</dd>

<dt><dfn id="current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</dfn>:</dt>

<dd>
  <p>A conforming specification needs to consider the development practices currently used
    by widget developers and promote relevant industry best-practice, such as
  <cite><a href="#mwbp"><abbr title="Mobile Web Best Practices">MWBP</abbr></a></cite>.</p>
</dd>

<dt><dfn id="device-independence">Device independence</dfn>:</dt>

<dd>
  <p>A conforming specification needs to support relevant device independence
    guidelines.</p>
</dd>

<dt><dfn id="ease-of-authoring">Ease of authoring</dfn>:</dt>

<dd>
  <p>A conforming specification needs to specify solutions that are easy to use and avoid
    unnecessary complexity, meaning that a widget package should be easy for authors to
    create without requiring special or expensive proprietary software, and easy for end-users to acquire and
    install/run.</p>
</dd>

<dt><dfn id="internationalization-and-localization">Internationalization and localization</dfn>:</dt>

<dd>
  <p>A conforming specification needs to implement relevant internationalization and
    localization guidelines, such as <cite><a href="#i18n-xml">i18n-XML</a></cite> and

  <cite><a href="#bcp47">BCP 47</a></cite>, as well as consider current practical
    internationalization solutions used by the widget development community.</p>
</dd>

<dt><dfn id="interoperability">Interoperability</dfn>:</dt>

<dd>
  <p>A conforming specification needs to attempt to be as interoperable as possible with
    existing market-leading widget user agents.</p>
</dd>

<dt><dfn id="longevity">Longevity</dfn>:</dt>

<dd>
  <p>A conforming specification needs to be specified in such a way that it ensures that a
    widget package can still be processed well into the future (e.g. 100 years from the date
    the specification reaches <q>Recommendation Status as defined in the </q> <cite><a href="#w3c-process">W3C
      Process</a></cite> document).</p>
</dd>

<dt><dfn id="security">Security</dfn>:</dt>

<dd>
  <p>A conforming specification needs to address the security concerns of end-users,
    authors, distributors and device manufacturers by recommending appropriate security
    policies and programming behavior. A conforming specification must also consider the
    distribution and deployment security requirements as they relate to authors and
    vendors.</p>
</dd>

<dt><dfn id="web-and-offline-distribution">Web and offline distribution</dfn>:</dt>

<dd>
  <p>A conforming specification needs to deal with cases where an end-user acquires a
    widget package over <cite><a href="#http">HTTP</a></cite> or via some other non HTTP-based
    (offline) means, such as a local file system, Blue tooth or a
    Multimedia Message Service. In addition, a conforming specification needs to provide a
    means by which widgets can be updated when a new or different version of a widget becomes
    available. It must be possible to perform updates from online and offline sources.</p>
</dd>
<dt><dfn id="wider-community-benefit">Wider community benefit</dfn></dt>
<dd>
  <p> Any new technologies or processes defined by a conforming specification needs to designed in such a way that they are beneficial  the wider Web community at large. In other words, conforming specifications should try not to be insular to their problem domain, but should also consider the needs of the wider Web community. </p>
</dd>
</dl><h2 id="requirements"><span class="secno">4 </span>Requirements</h2>

<p><em>This section is normative.</em></p>

<p>This section enumerates the <dfn id="requirements-0">requirements</dfn> that a conforming specification
would need to address to standardize widgets. These requirements are directly motivated
by the design goals and are based on an iterative process of feedback from the public,
discussions with various vendors, and a <a href="http://www.w3.org/TR/widgets-land/">survey of market-leading widget user agents</a>.</p>

<h3 id="packaging"><span class="secno">4.1 </span>Packaging</h3>

<p>This section enumerates the requirements that a conforming specification needs to
address to standardize the packaging format of a widget. The objective of this section is
to ensure that a conforming specification recommends a general packaging format that is,
amongst other things:</p>

<ul><li>Already a  <em>de facto</em> standard on market-leading widget user agents
on both desktops and mobile devices.</li>

<li>Able to be used in multilingual contexts.</li>

<li>Suitable for mobile devices.</li>

<li>Able to support digital signatures.</li>

</ul><h4 class="no-num req" id="packaging-format"><dfn>Packaging Format</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> recommend a packaging format that
is royalty free, open, and widely implemented across market-leading widget user agents
and compatible with mobile devices. In addition, a conforming specification <em class="ct">MUST</em> specify exactly which aspects of the packaging format are to be supported
by conforming widget user agents.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#compatibility-with-other-standards">Compatibility with other standards</a>, <a href="#web-and-offline-distribution">Web and offline
distribution</a>, <a href="#device-independence">device independence</a>, <span>ease of use</span>,
<a href="#current-development-practice-or-industry-best-practice">current development practice or industry best-practice</a>,
<a href="#internationalization-and-localization">internationalization and localization</a>, <a href="#interoperability">interoperability</a>, and <a href="#longevity">longevity</a>.</dd>

<dt>Rationale:</dt>

<dd>To specify an interoperable and pervasive packaging format that is relatively easy
for vendors to implement, and easy for authors to use/access on any platform.</dd>
</dl><h4 class="no-num req" id="media-type"><dfn>Media Type</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> recommend that a conforming widget package be sent
over <cite><a href="#http">HTTP</a></cite> with a formally registered <cite><a href="#rfc2046" title="rfc2046">media type</a></cite> that is specific to the Widget family of specifications. The
Working Group <em class="ct">MUST</em> formally register the media type with the Internet Assigned Numbers
Authority (IANA). A conforming specification <em class="ct">MUST</em> specify how a widget user agent will process a widget package that was served with an unsupported media type or when the media type is unspecified.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#compatibility-with-other-standards">Compatibility with other standards</a>, <a href="#web-and-offline-distribution">Web and offline
distribution</a>, and <span>ease of use</span>.</dd>

<dt>Rationale:</dt>

<dd>To provide a formal means for an author to denote that a widget package conforms to
a W3C endorsed specification when a widget package is served over

<cite><a href="#http">HTTP</a></cite>. In addition, the <a href="#media-type">media type</a> could potentially
be used in conjunction with an auto-discovery mechanism to facilitate deployment of a widget package.</dd>
</dl><h4 class="no-num req" id="file-extension"><dfn>File Extension</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify a file extension that authors MAY assign to widget packages in contexts that rely on file extensions to indicate the content type, such is the case on many popular file systems. </p>

<dl><dt>Motivation:</dt>

<dd><a href="#device-independence">Device independence</a>, <span>ease of use</span>, <a href="#web-and-offline-distribution">Web and offline
distribution</a>, <a href="#interoperability">interoperability</a>, and <a href="#longevity">longevity</a>.</dd>

<dt>Rationale:</dt>

<dd>When a <cite><a href="#media-type">media type</a></cite> is not present, as is often the case when a
widget is instantiated locally from an end-user's storage device, the operating system
will sometimes use the file extension to associate the widget package with the
appropriate widget user agent. However, when the widget is distributed over
<cite><a href="#http"><abbr title="Hyper Text Transfer Protocol">HTTP</abbr></a></cite> and a
media type is present, a file extension will usually not be required. However, in some cases, a Web
server may rely on a file extension to correctly set a widget package's media type in
the <cite>HTTP</cite> headers. In addition, a  user agent that is aware of the content type of widgets may add the appropriate file extension automatically or include it as the default if the user is prompted for the file name during a saving process.</dd>
</dl><h4 class="no-num req" id="internal-abstract-structure"><dfn>Internal Abstract Structure</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> recommend a packaging format that
supports structuring resources into collections such as files and directories (understood
in this document in a broader sense than in some popular file systems, namely as forms of
generic logical containers). In addition, the packaging format <em class="ct">SHOULD</em>
allow authors to add and remove resources of a widget package without needing to
recreate the widget package.</p>

<dl><dt>Motivation:</dt>

<dd><span>Ease of use</span>, <a href="#interoperability">interoperability</a>, and <a href="#current-development-practice-or-industry-best-practice">current development practice or industry
best-practice</a>.</dd>

<dt>Rationale:</dt>

<dd>To provide authors with a format that is easy to use in a development process.</dd>
</dl><h4 class="no-num req" id="reserved-resource-names"><dfn>Reserved Resource Names</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> indicate if any resources (files
or directories or similar logical containers) are mandatory or reserved and what specific
function they serve in the widget package. A conforming specification <em class="ct">SHOULD</em> specify graceful error handling/recovery procedures if those resources
are used erroneously or missing.</p>

<dl><dt>Motivation:</dt>

<dd><span>Ease of use</span>, <a href="#compatibility-with-other-standards">compatibility with other standards</a>, and
<a href="#current-development-practice-or-industry-best-practice">current development practice or industry best-practice</a>.</dd>

<dt>Rationale:</dt>

<dd>To make it more efficient for widget user agents to locate reserved  resources at runtime.
For example, the packaging format may require authors to place all resources inside a
'<code>resources</code>' directory located at the root of the widget package.</dd>
</dl><h4 class="no-num req" id="addressing-scheme"><dfn>Addressing Scheme</dfn></h4>

<p>A conforming specification MUST recommend a hierarchical addressing scheme that can be used to address the individual resources within a widget package from within a configuration document. The hierarchical addressing scheme MUST be  capable of expressing both absolute and relative relationships between a resource and the widget package. In addition, the hierarchical addressing scheme MUST be interoperable with resources that might also need to address other resources within the widget package (e.g., HTML documents, CSS documents, JavaScript documents,  etc.). The hierarchical addressing scheme SHOULD be one that Web authors would feel comfortable using or to which they are already accustomed.</p>

<dl><dt>Motivation:</dt>

<dd><span>Ease of use</span>, <a href="#compatibility-with-other-standards">compatibility with other standards</a>,

<a href="#current-development-practice-or-industry-best-practice">current development practice or industry best-practice</a>, and
<a href="#security">security</a>.</dd>

<dt>Rationale:</dt>

<dd>To make it easy for authors to address resources from the configuration document or other relevant resources within the widget package. For example, addressing a custom icon within a widget package from the configuration document (e.g. <code>&lt;icon src=&quot;icons/cat.ico'/&gt;</code>). Or, for example, addressing an image within a widget package from within a HTML start file (e.g. <code>&lt;img src=&quot;/backgrounds/sky.png'&gt;</code>). </dd>

</dl><h4 class="no-num req" id="multilingual-file-names"><dfn>Multilingual File Names</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> recommend a packaging format that allows for non-ASCII
characters in file and directory names, allowing authors to create widgets suitable for
various cultures and languages, as well as multilingual contexts. The packaging format
MUST either provide some means to declare the character encoding  or specify what the character encoding
is. The <cite><a href="#utf-8">UTF-8</a></cite> character encoding <em class="ct">SHOULD</em> be either the default (if multiple encodings are
allowed) or sole encoding used.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#internationalization-and-localization">Internationalization and localization</a>, <a href="#current-development-practice-or-industry-best-practice">current development
practice or industry best-practice</a>, <span>ease of use</span>,
<a href="#interoperability">interoperability</a>, and <a href="#longevity">longevity</a>.</dd>

<dt>Rationale:</dt>

<dd>To allow authors to create files and folders using characters beyond the ASCII
character repertoire. Since packaged widgets are widely distributed, variation in
character encoding between different platforms or configurations may render a widget with
non-ASCII resources inoperable or otherwise degrade the user experience unless a
character encoding is used.</dd>
</dl><h4 class="no-num req" id="localization-guidelines"><dfn>Localization Guidelines</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> provide guidelines that explain to
authors how collections of resources  need to be structured for the purpose of internationalization.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#internationalization-and-localization">Internationalization and localization</a>, <a href="#current-development-practice-or-industry-best-practice">current development
practice or industry best-practice</a>, <span>ease of use</span>, and
<a href="#interoperability">interoperability</a>.</dd>

<dt>Rationale:</dt>

<dd>To both guide and encourage authors to localize content. For example, the
specification could mandate that authors place localized content into a strictly named
directory structure that denotes localized content (e.g. <code>'resources/en/</code>' for
all English content, and '<code>resources/en-AU/</code>' for further localized
Australian-English content, and so on).</dd>
</dl><h4 class="no-num req" id="automatic-localization"><dfn>Automatic Localization</dfn></h4>

<p>A conforming specification <em class="ct">SHOULD</em> specify a processing model that
automatically localizes content when authors follow the localization guidelines.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#internationalization-and-localization">Internationalization and localization</a>, <a href="#current-development-practice-or-industry-best-practice">current development
practice or industry best-practice</a>, <span>ease of use</span>, and
<a href="#interoperability">interoperability</a>.</dd>

<dt>Rationale:</dt>

<dd>To define an internationalization model, complete with graceful error handling, to reduce the
amount of engineering work an author needs to do in order to localize a widget.</dd>
</dl><h4 class="no-num req" id="device-independent-delivery"><dfn>Device Independent Delivery</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> recommend a packaging format that
is suitable for delivery on many devices, particularly Web-enabled mobile devices.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#device-independence">Device independence</a>, <a href="#web-and-offline-distribution">Web and offline distribution</a>, and
<a href="#interoperability">interoperability</a>.</dd>

<dt>Rationale:</dt>

<dd>To recommend a packaging format that is interoperable with desktops and for mobile
devices, where the widget space is currently growing.</dd>
</dl><h4 class="no-num req" id="data-compression"><dfn>Data Compression</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> recommend a packaging format that
  supports both decompressed data and <em class="ct">OPTIONAL</em> data compression. A
  conforming specification <em class="ct">SHOULD</em> also recommend at least one
  royalty-free default compression/decompression algorithm that is compatible with
  market-leading widget user agents and implementations of the packaging format on mobile
  devices.</p>
<dl><dt>Motivation:</dt>
  <dd><a href="#web-and-offline-distribution">Web and offline distribution</a>, <a href="#device-independence">device independence</a>, and <a href="#current-development-practice-or-industry-best-practice">current development practice or industry best-practice</a>.</dd>
  <dt>Rationale:</dt>
  <dd>To make a widget package smaller for delivery over <cite><a href="#http">HTTP</a></cite>,
    where the cost of data access is sometimes expensive for end-users. Compressing might
    also help with transfer speed when a widget package is sent over a communication channel
    with limited bandwidth, such as Bluetooth or infrared.
    Compressed widgets may also have a lesser impact on a device's battery during
    download.</dd>
</dl><h4 class="no-num req" id="derive-the-media-type-of-resources"><dfn>Derive the Media Type of Resources </dfn></h4>
<p>In the case that the packaging format does not support labeling resources with a <a href="#rfc2046" title="rfc2046">media type</a>, a conforming specification MUST either specify or recommend a means of deriving the media type of resources for the purposes of rendering. A conforming specification MAY define a means to override how a widget user agent  derives the media type of a resource (e.g., treat resources with the file extension <code>.php</code> as <code>text/html</code>), but MUST NOT force a widget user agent to process resources of one media type as that of another type (e.g. treating a jpeg image at <code>text/html</code>). </p>
<dl><dt>Motivation:</dt>
  <dd><a href="#web-and-offline-distribution">Web and offline distribution</a>, <a href="#device-independence">device independence</a>, and <a href="#current-development-practice-or-industry-best-practice">current development practice or industry best-practice</a>.</dd>
  <dt>Rationale:</dt>
  <dd>To allow appropriate rendering of resources by the widget user agent. For instance, for the sake of interoperability,  all widget user agents should  treat resources with a <code><a href="#html">.html</a></code> file extension as <code>text/htm</code>l (and not as <code>application/xhtml+xml</code>).</dd>
</dl><h3 id="configuration-document"><span class="secno">4.2 </span>Configuration Document</h3>
<p>This section enumerates the requirements that a conforming specification needs to
address in order to standardize the configuration document. The objective of this section is to
ensure that a conforming specification specifies a configuration document format that
defines:</p>

<ul><li>Metadata elements that can capture metadata about a widget, including its title, some
form of identification, and versioning information.</li>

<li>Metadata elements that can capture authorship information.</li>

<li>A bootstrapping mechanism that would enable a widget user agents to automatically
instantiate a widget.</li>

<li>Relevant configuration parameters.</li>
</ul><h4 class="no-num req" id="format-and-schema"><dfn>Format
and Schema</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify the configuration document
language using a common data interchange format, as well as the rules for
processing the configuration document language and any micro-syntaxes represented as
character data. A conforming specification <em class="ct">MUST</em> specify graceful error handling procedures for when metadata values are
  in error, or the values are impossible to satisfy or realize by the user agent. The
  metadata <em class="ct">MUST</em> be extractable, processable and reusable in other
  contexts (for instance, to create an online gallery of widgets). In addition, a conforming
  specification <em class="ct">SHOULD</em> make it clear to authors which elements are
  optional and which elements are mandatory. A conforming specification <em class="ct">SHOULD</em> specify a formal schema for the language, as well as define any
  configuration defaults. The schema <em class="ct">SHOULD</em> NOT be a normative part of the conforming
  specification, but <em class="ct">MUST</em> be suitable for use by conformance checkers. A conforming
  specification <em class="ct">MUST</em> recommend that configuration documents be encoded
  in <cite><a href="#utf-8">UTF-8</a></cite>. A conforming specification <em class="ct">MAY</em> specify the configuration document language using alternative
standardized data interchange formats  (e.g. JSON) and schema.</p>
<dl><dt>Motivation:</dt>

<dd><a href="#compatibility-with-other-standards">Compatibility with other standards</a>, <a href="#current-development-practice-or-industry-best-practice">current development practice
or industry best-practice</a>, <span>ease of use</span>, <a href="#internationalization-and-localization">internationalization
and localization</a>, <a href="#longevity">longevity</a>, <a href="#interoperability">interoperability</a>, and <a href="#accessibility">accessibility</a>.</dd>

<dt>Rationale:</dt>

<dd>To have a language in a format that is relatively easy for authors to read and write,
and provides effective internationalization support. An example of such a language is <cite><a href="#xml"><abbr title="eXtensible Markup Language">XML</abbr></a></cite>. XML  is generally accepted and
understood by widget authors and parsed by all market-leading widget user agents, and <abbr title="eXtensible Markup Language">XML</abbr> parsers
generally have reasonable support for <cite><a href="#unicode">Unicode</a></cite>, which allows for
effective internationalization and localization.</dd>
</dl><h4 class="no-num req" id="widget-metadata"><dfn>Widget Metadata</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify the structure and
semantics of  elements that represent metadata about a widget. More specifically, a conforming specification

  <em class="ct">MUST</em> specify the structure and semantics of elements that represent
data about the widget, including the name, version number, a unique identifier, and a
description of what a widget does.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a>,
<a href="#interoperability">interoperability</a>, and <a href="#accessibility">accessibility</a>.</dd>

<dt>Rationale:</dt>

<dd>To provide authors with a practical set of metadata elements that describe various
aspects of the widget that may be used in various contexts. </dd>
</dl><h4 class="no-num req" id="authorship-metadata"><dfn>Authorship  Metadata</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify the structure and
semantics  data about the authorship of a widget, including an
author's name, e-mail, and organization. </p>

<dl><dt>Motivation:</dt>

<dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a>, and
<a href="#interoperability">interoperability</a>.</dd>

<dt>Rationale:</dt>

<dd>To provide authors with a practical set of metadata elements that describe a widget
and its authorship that may be utilized within an application context (such as a menu) or
of importance to end-users.</dd>
</dl><h4 class="no-num req" id="copyright-notice-and-license-metadata"><dfn>Copyright Notice and License Metadata</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify the structure and
semantics of fields that explicitly reference, or otherwise include, a software license
agreement or notice. In addition, a conforming specification <em class="ct">MUST</em> provide a means to declare who holds the copyright for the widget, as well as a
model for how this data must be processed by a widget user agent.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a>, and
<a href="#interoperability">interoperability</a>.</dd>

<dt>Rationale:</dt>

<dd>To provide authors with a means to legally declare how a widget and its various
internal resources can be used by end-users. For example, an author may include a <abbr title="GNU is not Unix">GNU</abbr>-style license that allows others to reuse any source
code.</dd>

</dl><h4 class="no-num req" id="visual-rendering-dimensions"><dfn>Visual Rendering Dimensions</dfn></h4>

<p>For widgets that make use of a rendering context, a conforming specification
<em class="ct">SHOULD</em> specify an <em class="ct">OPTIONAL</em> means for an author to
declare the initial visual dimensions for an instantiated widget in a way that is device
independent (e.g. via <cite><a href="#css">CSS</a></cite> pixels). In the absence of user style sheets, a conforming specification <em class="ct">MUST</em> specify that styling by the author takes precedence over dimensional values declared in the configuration document or any dimensional values implicitly computed by the widget user agent. However, in the presence of user style sheets, user style sheets take precedence but MUST be applied in conformance to the cascade model and rules of behavior specified in <cite><a href="#css">CSS</a></cite>.</p>

<dl><dt>Motivation:</dt>

<dd><span>Ease of use</span>, <a href="#device-independence">device independence</a>, and <a href="#current-development-practice-or-industry-best-practice">current
development practice or industry best-practice</a>.</dd>

<dt>Rationale:</dt>

<dd>To set up the rendering context for an instantiated widget in a way that is
compatible on a range of devices.</dd>

</dl><h4 class="no-num req" id="declarative-bootstrap"><dfn>Declarative Bootstrap</dfn></h4>
A conforming
specification <em class="ct">MUST</em> specify a declarative bootstrap mechanism that
addresses the start file that is to be initially instantiated at runtime (the
instantiated widget). The bootstrap mechanism <em class="ct">MUST NOT</em> be able to
address or instantiate local files outside the scope of the widget package. However,
the bootstrapping mechanism <em class="ct">MAY</em> be able to address a resource on the
Internet, but only of a <a href="#rfc2046" title="rfc2046">media type</a> allowed by the automated bootstrap requirement (below)
or resources that are of media types supported by a widget user agent. A conforming
specification <em class="ct">MAY</em> also allow authors to declaratively bootstrap
proprietary resources (e.g. a Flash movie) within the widget package, so long as they are able to be
processed or instantiated by the widget user agent. If a bootstrap has not been declared
by an author, then automated bootstrapping <em class="ct">MUST</em> occur as described in
the <a href="#automated-bootstrap">automated bootstrap</a> requirement.


<dl><dt>Motivation:</dt>

<dd><span>Ease of use</span>, <a href="#current-development-practice-or-industry-best-practice">current development practice or industry
best-practice</a>, and <a href="#security">security</a>.</dd>

<dt>Rationale:</dt>

<dd>For example, bootstrapping could occur by dereferencing, via a relative reference,
the initial resource to be retrieved from within a widget package by a widget user agent
(e.g. '<code>/ui/clock.svg</code>'). Alternatively, the resource might be a HTML document
that when combined with the <a href="#visual-rendering-dimensions">visual rendering dimensions</a> requirement displays
at the appropriate size.</dd>

</dl><h4 class="no-num req" id="automated-bootstrap"><dfn>Automated Bootstrap</dfn></h4>

<p>A conforming specification <em class="ct">Should</em> specify an automated model for
finding the start file of the widget in the absence of a <a href="#declarative-bootstrap">declarative
bootstrap</a>. The automated bootstrap model <em class="ct">MUST NOT</em> be able to
address resources outside the scope of the widget package and <em class="ct">MUST
NOT</em> address resources on the Web over <cite><a href="#http"><abbr title="Hyper Text Transfer Protocol">HTTP</abbr></a></cite> or any other protocol. The
widget user agent <em class="ct">SHOULD</em> be allowed to select its preferred format
for the start file, and then it <em class="ct">SHOULD</em> locate that resource first before attempting to
locate other resources.</p>

<dl><dt>Motivation:</dt>

<dd><span>Ease of use</span>, <a href="#device-independence">device independence</a>, <a href="#current-development-practice-or-industry-best-practice">current development
practice or industry best-practice</a>, and <a href="#internationalization-and-localization">internationalization and
localization</a>.</dd>

<dt>Rationale:</dt>

<dd>For example, the conforming specification could specify a model that searches for a
default file name (<code>index.htm</code>, <code>index.html</code>,
<code>index.svg</code>, etc.) firstly within localized directory names, as required by
automatic localization, and then within the directories of the widget package. If that
search fails, then the widget user agent could try to find files with extensions &quot;.html,
.svg, etc.&quot; starting from the root directory.</dd>
</dl><h4 class="no-num req" id="iconic-representations"><dfn>Iconic Representations</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify a means to declare iconic
  representations of the widget for use as alternate or fallback content, standby indicator
  or in a non-running context. The conforming specification <em class="ct">should not</em> limit iconic representations to static images and it <em class="ct">SHOULD</em> provide support for
  alternative text representations of an icon where possible. A conforming specification <em class="ct">SHOULD</em> also recommend a default icon <a href="#rfc2046" title="rfc2046">media type</a> and file name.</p>
<dl><dt>Motivation:</dt>
  <dd><span>Ease of use</span>, <a href="#device-independence">device independence</a>, <a href="#current-development-practice-or-industry-best-practice">current development
    practice or industry best-practice</a>, <a href="#internationalization-and-localization">internationalization and
      localization</a>, <a href="#interoperability">interoperability</a>, and <a href="#accessibility">accessibility.</a></dd>
  <dt>Rationale:</dt>
  <dd>To provide authors with a visual means of representing widgets to end-users prior to
    instantiation. The icon may also serve as visual means for end-users to associate an icon
    with a widget. For example, a small graphic of a calendar showing today's date may
    represent a calendar widget.</dd>
</dl><h4 class="no-num req" id="configuration-parameters"><dfn>Configuration Parameters</dfn></h4>
<p class="no-num req">A conforming specification <em class="ct">MUST</em> specify a means
  to for authors to declare values of custom and predefined configuration parameters, all
  of which would be applied as a widget is instantiated. A conforming specification <em class="ct">MUST</em> specify the default values for specification-defined parameters
  in case a parameter is missing or the value supplied by the author is invalid. A
  conforming specification <em class="ct">SHOULD</em> allow a widget user agent to override author defined
  parameters in circumstances where it might be beneficial for users or has the potential
  to improve performance or stability of the widget user agent.</p>
<dl><dt>Motivation:</dt>
  <dd><span>Ease of use</span>, and <a href="#current-development-practice-or-industry-best-practice">current development practice or industry
    best-practice</a>.</dd>
  <dt>Rationale:</dt>
  <dd>To allow authors to declaratively control how a widget is configured during
    instantiation. And, in the absence of any declarations, allow the widget user agent to
    automatically configure a widget using default values. For example, the author might
    declare that the value for the parameter <code>width</code> = <code>50</code> indicating
    the <code>50</code> as the value for visual width. Or, in the absence of an
    author-declared width, the widget user agent will automatically set the <code>width</code> to some standardized value (e.g. <code>300</code>).</dd>
</dl><h4 class="no-num req" id="author-defined-start-up-values-preferences"><span>Author-defined Start-up Values</span> (Preferences)</h4>
<p class="no-num req">A conforming specification <em class="ct">MUST</em> specify a means
  to for authors to declare persistently stored name-values pairs that an author <em class="ct">MAY</em> use to configure a widget instance when the widget is first run. A conforming specification <em class="ct">MUST</em> allow authors to define which values are read only, meaning that those values MUST be protected from modification at runtime. A conforming specification <em class="ct">MUST</em> specify that these  values <em class="ct">MUST</em> be made available to the author at runtime via scripting.</p>
<dl><dt>Motivation:</dt>
  <dd><span>Ease of use</span>, and <a href="#current-development-practice-or-industry-best-practice">current development practice or industry
    best-practice</a>.</dd>
  <dt>Rationale:</dt>
  <dd>To allow authors to  configure a widget through declarative means using name value pairs (i.e., &quot;preferences&quot; for a widget). This would allow authors to, for instance, dynamically generate a widget to have predefined values that could be custom for an end-user. For example, a user might want a weather widget that defaults to their home city. When the widget is generated, the value of the home city is included in the configuration document so when the widget starts, the end-user is not required to specify which city they want to receive the weather forecast for. </dd>
</dl><h4 class="no-num req" id="feature-access-declarations"><dfn>Feature Access Declarations</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify or recommend a means to allow authors to
  declare that an instantiated widget will require access to formally standardized features that allow access to device-specific  capabilities or proprietary features (e.g. a proprietary API to access the camera on a device). A conforming specification <em class="ct">MAY</em> be specified in such a way that fallback relationships can be declared so that if one feature is unavailable, another can be declared as a possible substitute. In addition, a conforming specification <em class="ct">MUST</em> provide authors with a means of stating which features are optional and which features are mandatory for a widget to run.</p>

<dl><dt>Motivation:</dt>
  <dd><a href="#device-independence">Device independence</a>, <span>ease of use</span>, <a href="#security">security</a>, and <a href="#interoperability">interoperability</a>.</dd>
  <dt>Rationale:</dt>

  <dd>To allow authors to securely request access to device specific services and features, and to allow widgets to use proprietary features but with a degree of graceful degradation if a feature is unavailable to a particular widget user agent. </dd>
</dl><h4 class="no-num req" id="configuration-document-independence"><dfn>Configuration Document Independence</dfn></h4>
<p>A conforming specification <em class="ct">MUST</em> specify the configuration document
  format in such a way that it can be used independently of the widget package that contains it.
  A conforming specification <em class="ct">MAY</em> provide guidelines for how the
  configuration document can be used separately from a widget package.</p>
<dl><dt>Motivation:</dt>
  <dd><span>Ease of use</span>, <a href="#web-and-offline-distribution">Web and offline distribution</a>, and <a href="#device-independence">device
    independence</a>.</dd>
  <dt>Rationale:</dt>
  <dd>To allow the configuration document to be accessed by other applications
    (either on the server or on the client side) for unrelated purposes. For example, in the context of a widget gallery Web site, a
    server may automatically extract the configuration document from a widget package and
    serve it upon request. The extracted configuration document may then be used, for
    instance, for checking information about the widget without needing to download the
    complete widget package. This may be particularly useful for users of widgets on mobile
    devices, where the cost of downloading data can sometimes be expensive.</dd>
</dl><h4 class="no-num req" id="preferred-display-mode"><dfn>Preferred Display Mode</dfn></h4>
<p>A conforming specification MUST provide a means for author to indicate
at least one preferred display mode for a widget. In the absence of a
preferred mode, a conforming specification SHOULD provide a consistent
default display mode across all user agents. A conforming
specification SHOULD make it possible for an author to indicate to the
widget user agent which display modes the widget has been designed to
run in. The Widget User Agent MAY ignore the indications of display
mode supported, but SHOULD NOT ignore the preferred display mode.
</p>
<dl><dt>Motivation:</dt>
  <dd><span>Ease of use</span>, <a href="#web-and-offline-distribution">Web and offline distribution</a>, and <a href="#device-independence">device
    independence</a>.</dd>
  <dt>Rationale:</dt>
  <dd>To provide authors a means to indicate a preference over
how their widget is initially rendered, though this would not be not
guaranteed by the widget user agent. A means of declaring the
preferred display mode also provides authors some reassurance, as some
widgets may be better suited to being displayed in one display mode
over the others. As already stated, widget user agents may choose to
ignore the author's display mode preference, for example, if they do
not support the indicated display mode.
</dd>
</dl><h3 id="application-programming-interfaces"><span class="secno">4.3 </span>Application Programming Interfaces</h3>

<p>This section enumerates the requirements that a conforming specification needs to
address to standardize an <dfn id="api-for-widgets">API for widgets</dfn>. The objective of this section is to
ensure that a conforming specification specifies an API that allows authors to, amongst
other things:</p>

<ul><li>Manipulate the preferences and properties of an instantiated widget.</li>

<li>Capture widget-specific events.</li>

<li>Safely access services, resources, and other applications on the user's device.</li>

</ul><h4 class="no-num req" id="instantiated-widget-api"><dfn>Instantiated Widget API</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify a set of interfaces that
expose properties, methods, and events of an instantiated widget. These interfaces
<em class="ct">MUST</em> be encapsulated as a self-contained object, or some similar data
structure, in a non-object-oriented programming environment.</p>

<dl><dt>Motivation:</dt>

<dd><span>Ease of use</span>, <a href="#compatibility-with-other-standards">compatibility with other standards</a>, and
<a href="#current-development-practice-or-industry-best-practice">current development practice or industry best-practice</a>.</dd>

<dt>Rationale:</dt>

<dd>To allow authors to make their widgets interactive. See for example Apple's
<code><a href="#widget">widget</a></code> Object described in the <cite><a href="#dashboard-reference">Dashboard Reference</a></cite>

and Microsoft's <code>System.Gadget</code> Object described in the <cite><a href="#sidebar-reference">Sidebar
Reference</a></cite>.</dd>
</dl><h4 class="no-num req" id="idl-definitions"><dfn>IDL Definitions</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify the APIs in this section
in a standardized interface definition
language (e.g. <cite><a href="#web-idl">Web IDL</a></cite>).</p>

<dl><dt>Motivation:</dt>

<dd><a href="#compatibility-with-other-standards">Compatibility with other standards</a>, <a href="#current-development-practice-or-industry-best-practice">current development practice
or industry best-practice</a>, and <a href="#internationalization-and-localization">internationalization and
localization</a>.</dd>

<dt>Rationale:</dt>

<dd>To facilitate implementation in <cite><a href="#ecmascript">ECMAScript</a></cite>, which is already widely supported in
widget user agents. Facilitating the implementation of the APIs in ECMAScript will allow
authors to use existing ECMAScript code libraries such as <a href="http://jquery.com/">jQuery</a>, <a href="http://www.dojotoolkit.org/">Dojo</a>, and <a href="http://www.prototypejs.org/">Prototype</a>.</dd>

</dl><h4 class="no-num req" id="configuring-runtime-properties"><dfn>Configuring Runtime Properties</dfn></h4>

<p>A conforming specification <em class="ct">SHOULD</em> specify a set of interfaces that
expose relevant properties and methods of the widget user agent.</p>

<dl><dt>Motivation:</dt>

<dd><span>Ease of use</span>, <a href="#compatibility-with-other-standards">compatibility with other standards</a>, and

<a href="#current-development-practice-or-industry-best-practice">current development practice or industry best-practice</a>.</dd>

<dt>Rationale:</dt>

<dd>To allow authors to access to any relevant state information or helper methods
provided by the widget user agent. Such properties could include localization
information, operating environment details, availability of network access, etc. See for
example Microsoft's <cite><a href="#sidebar-reference">Sidebar Reference</a></cite>.</dd>
</dl><h4 class="no-num req" id="manipulation-of-author-defined-start-up-values"><dfn>Manipulation of <span>Author-defined Start-up Values</span></dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify or recommend a set of interfaces for
dynamically getting and setting persistently stored values for a widget instance set using the means provided by the <span class="no-num req"><span>author-defined start-up values</span></span>. A widget user
  agent <em class="ct">MUST</em> persistently retain a widget's <span class="no-num req"><span>author-defined start-up values</span></span> in the case
where a widget is re-instantiated or the widget user agent is restarted. A conforming specification <em class="ct">MUST</em> recommend an API that allows authors to iterate and modify the <span class="no-num req"><span>author-defined start-up values that are not set to read-only</span></span>, clear the values, add new values, get all the names of the values, and get the number of values currently stored. A conforming specification MUST specify that, if an author attempts to modify a value that is set as read-only, the API<em> </em>throw an appropriate access violation exception. </p>

<dl><dt>Motivation:</dt>

<dd><span>Ease of use</span>, <a href="#compatibility-with-other-standards">compatibility with other standards</a>, <a href="#web-and-offline-distribution">Web and
  offline distribution</a>, <a href="#security">security</a>, and <a href="#current-development-practice-or-industry-best-practice">current development practice or industry best-practice</a>.</dd>

<dt>Rationale:</dt>

<dd>To allow widgets to be closed and re-instantiated without the end-user having to
    re-input the <span class="no-num req"><span>author-defined start-up values</span></span> for an instantiated widget. For example, when using a weather
    widget, the end-user will want to store the preferred location for weather information,
    and not be asked to input that information again every time the widget is
    re-instantiated. The same would apply if the user has instantiated two instances of the
    same widget and would like to see the weather forecast for two different cities (e.g.,
    Paris and Sydney). When the widgets are re-instantiated, the corresponding weather
  information would be downloaded to match each widget's city <span class="no-num req"><span>value</span></span>.</dd>
</dl><h4 class="no-num req" id="widget-state-change-events"><dfn>Widget State Change Events</dfn></h4>

<p>A conforming specification <em class="ct">must</em> define a set of states in the
lifecycle of the instantiated widget as well as how and when an instantiated widget enters each state. Changes in states <em class="ct">must</em> have
associated events which can be consumed by event handlers, such as scripts. Additionally
the API <em class="ct">MUST</em> expose the current state. A conforming specification <em class="ct">MUST
NOT</em> require the widget user agent to send events to the widget immediately, and

<em class="ct">should</em> allow the widget user agent to dispatch the events at its
convenience.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a>, and <span>ease of
use</span>.</dd>

<dt>Rationale:</dt>

<dd>To allow authors to capture state-change events generated by the instantiated
widget.</dd>
</dl><h4 class="no-num req" id="network-state-change-events"><dfn>Network State Change Events</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify a means that allows
authors to check if a widget instance is connected to the network. A conforming
specification <em class="ct">MUST</em> define the scope of the term &quot;network&quot; and

<em class="ct">MUST</em> specify a means by which connection and disconnection events can
be captured by an author through script. A conforming specification <em class="ct">MUST
NOT</em> guarantee event delivery, as there may be cases where a device is running low on
resources (e.g., power) and can not afford to deliver them.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a>, and <span>ease of
use</span>.</dd>

<dt>Rationale:</dt>

<dd>To allow authors to programmatically capture when the widget user agent has acquired
or lost a network connection, particularly for cases when the device intermittently loses
and regains the network connection.</dd>
</dl><h4 class="no-num req" id="modal-priority"><dfn>Modal Priority</dfn></h4>

<p>A conforming specification <em class="ct">SHOULD</em> specify how an instantiated
widget (or any of its presentation contexts) should classify itself to the widget user
agent as critical, floating, output-only, etc.. Some of these mode changes may require
the end-user's attention, in which a case conforming specification <em class="ct">SHOULD</em> recommend that widget user agent find a suitable way to draw the
end-user's attention.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a>, <span>ease of
use</span>, and <a href="#accessibility">accessibility</a>.</dd>

<dt>Rationale:</dt>

<dd>An example of this kind of behavior can be seen on Mac OS X, where a program's icon
bounces in the dock when a program has a critical window to display.</dd>

</dl><h4 class="no-num req" id="device-specific-apis-and-services"><dfn>Device Specific APIs and Services</dfn></h4>

<p>A conforming specification <em class="ct">SHOULD</em> specify a mechanism, either
through an API or through the configuration document, which allows instantiated widgets
to bind to third-party APIs that allow access to device-specific resources and services.
A conforming specification is <em class="ct">not required</em> to specify any APIs to
device specific resources or services, but <em class="ct">SHOULD</em> provide some means
of binding to those APIs if they are available and the user agrees. A conforming
specification <em class="ct">SHOULD</em> specify that bindings <em class="ct">MUST
NOT</em> occur without consulting the user or a policy which exists to represent the end
user (or the owner of the device).</p>

<dl><dt>Motivation:</dt>

<dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a>, <span>ease of
use</span>.</dd>

<dt>Rationale:</dt>

<dd>To endow widgets with functionality beyond what is currently available to HTML
documents, allowing widgets to be used as means to bridge special device capabilities and
operating environment services with data on the Web. Examples of device-specific services
and resources that could be made available through script include cameras, SMS, GPS and
address books.</dd>

</dl><h4 class="no-num req" id="configuration-document-data"><dfn>Configuration Document Data</dfn></h4>

<p>A conforming specification <em class="ct">SHOULD</em> specify a means that allows
authors to access data they declared in the configuration document for the
widget package.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a>.</dd>

<dt>Rationale:</dt>

<dd>To allow authors at runtime to easily access metadata declared in the configuration
document.</dd>
</dl><h4 class="no-num req" id="scheme-handler"><dfn>Scheme Handler</dfn></h4>

<p>A conforming specification <em class="ct">SHOULD</em> specify a means that allows
authors to open <cite><a href="#iri">IRI</a></cite>s in an appropriate scheme handler (e.g., using the default Web Browser to open <cite><a href="#http">HTTP</a></cite> URIs).</p>

<dl><dt>Motivation:</dt>

<dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a>.</dd>

<dt>Rationale:</dt>

<dd>To allow authors to open a URL in the default system Web browser. For example, in a
news aggregator widget, to allow the end user to navigate to the source of a particular
news item. Alternatively, if the widget deems that a specific content may be better
experienced outside the context of the widget user agent, the user can be offered the
option of opening the content in the default system Web browser.</dd>
</dl><h4 class="no-num req" id="resolve-addressing-scheme"><dfn>Resolve Addressing Scheme</dfn></h4>
<p> A conforming specification MUST define a mechanism to set the base URI for any DOM instances that occur within the Widget, and it MUST define a mechanism that enables the construction of URI references between different resources within a widget package.<br /></p>
<dl><dt>Motivation:</dt>
  <dd><span>Current development practice or industry best-practice, interoperability, and security</span>.</dd>
  <dt>Rationale:</dt>
  <dd>To allow resources to be resolved and normalized within DOM
    attributes. For example, addressing a resource via an <cite><a href="#iri"><abbr title="Internationalized Resource
    Identifier">IRI</abbr></a></cite> reference (e.g. <code>&lt;img
      src=&quot;images/bg.png'/&gt;</code> where the <code>src</code> attribute
    resolves to something similar to
  &quot;<code>widget://engine/myWidget.wgt/images/bg.png</code>&quot; or &quot;<code>http://localhost/myWidget.wgt/images/bg.png</code>&quot;).</dd>
</dl><h4 class="no-num req" id="display-mode-api-and-events"><dfn>Display mode API and Events</dfn></h4>
<p>A conforming specification MUST specify an API to allow authors to
programmatically switch between display modes. A conforming user agent
MUST be allowed to ignore requests by the author to switch to an
unsupported display mode, but MUST throw an exception or error if it
will not perform the mode change. A conforming specification MUST also
provide a guaranteed means for authors to detect a change in display
mode. A conforming specification MUST provide a means for an author to
check the current display mode of a widget. </p>
  <dl><dt>Motivation:</dt>
    <dd><span>Current development practice or industry best-practice, interoperability, and security</span>.</dd>
    <dt>Rationale:</dt>
    <dd>To give authors a degree of control over the user experience of their widgets.</dd>
  </dl><h3 id="user-experience"><span class="secno">4.4 </span>User experience</h3>

<p>This section enumerates the requirements that a conforming specification needs to
address in order to standardize a user experience widgets. The objective of this
section is to ensure that a conforming specification make recommendations that would make widgets accessible and able to be rendered on a range of devices.</p>

<h4 class="no-num req" id="user-interface-accessibility"><dfn>User Interface Accessibility</dfn></h4>
<p>A conforming specification <em class="ct">MUST</em> specify that the language used to
  declare the user interface of a widget be a
  language that is accessible at the various levels specified by the <cite><a href="#wcag-2.0">WCAG
    2.0</a></cite> (perceivable, operable, understandable, and robust): specifically, the
  language <em class="ct">MUST</em> provide keyboard access to interactive graphical
  elements, and provide means to access the widget's functionality through a non-graphical
  UI. For the user interface language, the role and state of all interface elements <em class="ct">MUST</em> be
  available to screen readers and other assistive technologies, to allow relevant sections
  of text and functionality to be accessed.</p>
<dl><dt>Motivation:</dt>
  <dd><a href="#compatibility-with-other-standards">Compatibility with other standards</a>, <a href="#current-development-practice-or-industry-best-practice">current development practice
    or industry best-practice</a>, <span>ease of use</span>, and <a href="#accessibility">accessibility</a>.</dd>
  <dt>Rationale:</dt>
  <dd>To recommend a language, or a set of languages, that will allow authors to realize
    their designs, while at the same time remaining accessible to screen readers and other
    assistive technologies.</dd>
</dl><h4 class="no-num req" id="display-modes"><dfn>Display Modes</dfn></h4>
<p>A conforming specification <em class="ct">MUST</em> specify a set of display modes for
widgets that stipulate how widgets <em class="ct">SHOULD</em> be rendered at runtime when
in a specific mode. A conforming specification <em class="ct">SHOULD</em> also define
particular allowed, or disallowed, user-interaction behaviors for each
display mode; such as the ability for a widget to be dragged or
re-sized. For each display mode, the way in which the widget is
displayed <em class="ct">MUST</em> be specified so that the rendering of the Widget is as
consistent as possible across widget user agents. The display modes
<em class="ct">SHOULD</em> also be specified to interoperate with device independence best
practices and/or specifications. Proprietary display modes <em class="ct">MAY</em> be
supported by the Widget User Agent. </p>
<dl><dt>Motivation:</dt>
  <dd><a href="#compatibility-with-other-standards">Compatibility with other standards</a>, <a href="#current-development-practice-or-industry-best-practice">current development practice
    or industry best-practice</a>, <span>ease of use</span>, and <a href="#accessibility">accessibility</a>.</dd>
  <dt>Rationale:</dt>
  <dd>To provide authors with a variety of commonly widget
display modes and to help ensure that their widgets are renders as
consistently as possible across different Widget User Agents. In
addition, allowing proprietary display modes provides a means to
support innovative user experiences.</dd>
</dl><h3 id="user-agents"><span class="secno">4.5 </span>User Agents</h3>

<p>This section enumerates the requirements that a conforming specification needs to
address in order to standardize certain aspects of widget user agents. The objective of this
section is to ensure that a conforming specification recommends features that will make
widget user agents interoperate more effectively with each other and with
services on the Web.</p>

<h4 class="no-num req" id="remote-and-local-updates"><dfn>Remote and Local Updates</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify a model to allow widget
user agents to  check if a new version of a widget package has become
available online or from local storage. A conforming specification <em class="ct">MUST</em> recommend that an updated widget is downloaded only with the user's
consent and that users be able to cancel or defer updates. An automatic update <em class="ct">MUST</em> preserve the identity of a widget, meaning that that preferences
previously set by the user are retained after the update process. A conforming
specification <em class="ct">SHOULD</em> recommend that, when possible,  updates
be conducted over a secure communication channel. In addition, a conforming specification

<em class="ct">SHOULD</em> specify a means for updates to be authenticated. A conforming specification SHOULD
also define a mechanism to protect against downgrade attacks using ancient versions of
widgets. A conforming specification <em class="ct">SHOULD</em> specify that signature verification policies
be applied to updates in a manner that is consistent with those applied upon original
installation of the widget.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#security">Security</a>, <a href="#current-development-practice-or-industry-best-practice">current development practice or industry
best-practice</a>, and <a href="#interoperability">interoperability</a>.</dd>

<dt>Rationale:</dt>

<dd>To allow authors to provide updates for a widget package online. For example, the
author could declare in the configuration document an <cite><a href="#iri"><abbr title="Internationalized Resource Identifier">IRI</abbr></a></cite> for where the widget
user agent can check for updates. If an update to a widget package becomes available,
then the widget user agent could ask the end-user if they want to download the
widget.</dd>
</dl><h4 class="no-num req" id="multiple-widget-instances"><dfn>Multiple Widget Instances</dfn></h4>
<p>A conforming specification <em class="ct">MUST</em> recommend that a widget user agent
  allow multiple instances of a widget package to be instantiated. A conforming
  specification <em class="ct">MAY</em> recommend that implementations which have
  sufficient resources (CPU, memory, etc.) run widgets concurrently as separate
  processes.</p>
<dl><dt>Motivation:</dt>
  <dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a> and <a href="#interoperability">interoperability</a>.</dd>
  <dt>Rationale:</dt>
  <dd>To allow multiples instances of the same widget to be run at the same time, but
    possibly be configured differently. For example, instantiating two clock widgets where
    one displays the time for Amsterdam and the other displays the time for Boston.</dd>
</dl><h4 class="no-num req" id="display-mode-switching"><dfn>Display Mode Switching</dfn></h4>
<p>A conforming specification MUST allow a widget user agent to
dynamically change display mode of a widget. Switching from one mode
to another, however, MUST not cause the re-instantiation of the
Widget. Furthermore, it MUST be possible for a Widget to seamlessly
move between modes, maintaining runtime state and any processes that
are in progress.</p>
<dl><dt>Motivation:</dt>
  <dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a> and <a href="#interoperability">interoperability</a>.</dd>
  <dt>Rationale:</dt>
  <dd>To allow a widget user agent to have a degree of control
over how widgets are displayed for the purpose of mediating the user
experience. For example, the widget user agent my attempt to switch
all widgets into floating mode and then display them in a 3D carousel.
</dd>
</dl><h3 id="security-and-digital-signatures"><span class="secno">4.6 </span>Security and Digital Signatures</h3>

<p>This section enumerates the requirements that a conforming specification needs to
address in order to standardize industry standard signing and an adequate security model for
widgets. The objective of this section is to ensure that a conforming specification
specifies a security model that:</p>

<ul><li>Defines a robust and flexible digital signature scheme and processing model.</li>

<li>Makes security a fundamental part of the standardization process and permeates all
aspects of a conforming specification.</li>

<li>Limits the potential for widgets to perform harmful operations on end-user's machine
or device.</li>

</ul><h4 class="no-num req" id="runtime-security-exceptions"><dfn>Runtime Security Exceptions</dfn></h4>
<p>A conforming specification <em class="ct">MUST</em> specify runtime exceptions for
  when a widget's script attempts to perform an action it's not authorized to perform.</p>
<dl><dt>Motivation:</dt>
  <dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a> and <a href="#security">security</a>.</dd>

  <dt>Rationale:</dt>
  <dd>To provide the API with an error recovery mechanism for when a script attempts to
    perform a disallowed security-sensitive action. For example, a security exception might
    be thrown if a widget attempts to access the network but has not been granted permission
    by the widget user agent to do so.</dd>
</dl><h4 class="no-num req" id="digital-signatures"><dfn>Digital Signatures</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify a means to verify the
authenticity and data integrity of all resources in a widget package, with the exception
of any resources explicitly excluded by the specification (e.g. the digital signature
file itself). A conforming specification <em class="ct">MUST</em> provide these capabilities by specifying or
recommending a processing model for generating and verifying a digital signature
associated with a widget package. The digital signature scheme <em class="ct">MUST</em>

be compatible with existing Public Key Infrastructures (PKI), particularly
<cite><a href="#x.509v3">X.509v3</a></cite>.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#security">Security</a> and <a href="#current-development-practice-or-industry-best-practice">current development practice or industry
best-practice</a>.</dd>

<dt>Rationale:</dt>

<dd>To provide a means to verify the authenticity, check the data integrity and provide
persistent proof of origin of the widget package. Some vendors may choose to use digital
certificates as a means of quality assurance, whereby only widgets that meet a particular
level of quality and security receive a digital signature.</dd>
</dl><h4 class="no-num req" id="multiple-signatures-and-certificate-chains"><dfn>Multiple Signatures and Certificate Chains</dfn></h4>

<p>A conforming specification <em class="ct">SHOULD</em> recommend that it should be possible for a widget package to contain multiple independent digital signatures (i.e. it be possible to
include multiple signatures and associated certificate chains). A conforming
specification <em class="ct">MUST</em> specify the expected behavior when multiple signatures and certificate
chains are provided. A conforming specification <em class="ct">MUST</em> specify that if none of the
signatures and certificate chains can be verified, e.g. because of missing root
certificates or where any certificates in the chain have expired or are not yet valid,
then the widget package <em class="ct">SHOULD</em> be treated as unsigned (meaning that widget is treated as
if it had no digital signature).</p>

<dl><dt>Motivation:</dt>

<dd><a href="#web-and-offline-distribution">Web and offline distribution</a>, <a href="#device-independence">device independence</a>, and <a href="#current-development-practice-or-industry-best-practice">current development practice
or industry best-practice</a>.</dd>

<dt>Rationale:</dt>

<dd>To enable the inclusion of certificate chains that the receiving device can use to
build a certificate chain from the end entity certificate, which is then used to verify
the signature against the appropriate locally stored root certificate.</dd>

</dl><h4 class="no-num req" id="signature-document-format"><dfn>Signature Document Format</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> recommend a digital signature format that can be extracted and conveyed independently of
the widget package. A conforming specification <em class="ct">SHOULD</em> provide guidelines for how any
digital signature can be used separately from a widget package. An example of such use is to perform certificate chain validation and other checks related to the signature key information, without necessarily validating the referenced widget content at that time. Risks associated with separating time of verification and validation steps <em class="ct">MAY</em> need consideration.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#web-and-offline-distribution">Web and offline distribution</a>, <a href="#device-independence">device independence</a>, and <a href="#current-development-practice-or-industry-best-practice">current development practice or
industry best-practice</a>.</dd>

<dt>Rationale:</dt>

<dd>To allow   signature files to be extracted and used by other applications, either
on the server-side or on the client-side, for different purposes. For example, a server
may automatically extract the signature information from a widget package and serve it
upon request. The independent signature information may then be used, for instance, to
provide the user with information about the signer and associated trust level of the
widget package without needing to download the entire widget package. Additionally, if
combined with security declaration information, the signature information may allow a
security decision to be made about whether or not it will be possible for the widget user
agent to instantiate the widget; hence enabling the end-user or the widget user agent to
decide if widget package should be downloaded. This may be particularly useful for users
of widgets on mobile devices, where the cost of downloading data can sometimes be
expensive.</dd>
</dl><h4 class="no-num req" id="support-for-multiple-message-digest-algorithms"><dfn>Support for Multiple Message Digest Algorithms</dfn></h4>

<p>A conforming specification MUST specify at least one mandatory to support message digest algorithm. A conforming specification SHOULD recommend that other message digest algorithms may be supported. </p>

<dl><dt>Motivation:</dt>

<dd><a href="#security">Security</a> and <a href="#longevity">longevity</a>.</dd>

<dt>Rationale:</dt>

<dd>To provide a transitional means for developers to move towards using the more secure hashing algorithms. </dd>
</dl><h4 class="no-num req" id="support-for-multiple-signature-algorithms"><dfn>Support for Multiple Signature Algorithms</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> recommend that where a widget package is digitally
signed,  it MUST be possible to select from multiple message signature algorithms. A conforming specification <em class="ct">MUST</em> mandate that at least one signature algorithm be supported by a widget user agent.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#security">Security</a>, <a href="#longevity">longevity</a>, and <a href="#current-development-practice-or-industry-best-practice">current development practice or industry
best-practice</a>.</dd>

<dt>Rationale:</dt>

<dd>To   lessen the seriousness against the risk that weaknesses will be found with
a selected algorithm.</dd>
</dl><h4 class="no-num req" id="key-lengths"><dfn>Key Lengths</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> recommend that widget user agents
support processing signatures with key lengths of  2048
bits or greater.  A conforming
specification <em class="ct">MUST</em> recommend to authors that widget packages be signed with key
lengths of 2048 bits or greater.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#security">Security</a> and <a href="#longevity">longevity</a>.</dd>


<dt>Rationale:</dt>

<dd>To be in-line with current security recommendations and provide longevity of the
system security.</dd>
</dl><h4 class="no-num req" id="key-usage-extension"><dfn>Key Usage Extension</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify the expected use of valid key usage extensions
and when present (in end entity certificates) <em class="ct">MUST</em> specify that implementations verify
that the extension has the <code>digitalSignature</code> bit set (as defined in <cite><a href="#x.509v3">X.509v3</a></cite>). A conforming
specification <em class="ct">MUST</em> specify that implementations recognize the extended key usage
extension and when present (in end entity certificates) verify that the extension
contains the <code>id-kp-codeSigning</code> object identifier.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#security">Security</a>.</dd>

<dt>Rationale:</dt>

<dd>To maintain compliance to <cite><a href="#x.509v3">X.509v3</a></cite> (experience suggests that
if the use of the extended key usage extension is not explicitly required, then X.509v3
is not followed when it comes to key extension usage). Compliance ensures that only
certificates intended to be used (issued for) code signing can be used to sign widget packages.</dd>

</dl><h4 class="no-num req" id="inclusion-of-revocation-information"><dfn>Inclusion of Revocation Information</dfn></h4>

<p>A conforming specification <em class="ct">SHOULD</em> specify a means of packaging up-to-date revocation
information with a digital signature and associated certificate chain (e.g. a Certificate
Revocation List (<abbr title="Certificate Revocation List">CRL</abbr>) or Online
Certificate Status Protocol (<abbr title="Online Certificate Status Protocol">OCSP</abbr>) response stating that certificate has
not been revoked). In addition, a conforming specification <em class="ct">SHOULD</em> specify the behavior in
the case that the revocation information is not included or not complete. A conforming
specification <em class="ct">SHOULD</em> specify that if the revocation information is present the widget
processing environment <em class="ct">MUST</em> attempt to verify the revocation information. A conforming
specification <em class="ct">SHOULD</em> specify the behavior if revocation information is out of date or
otherwise invalid.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#security">Security</a></dd>

<dt>Rationale:</dt>

<dd>To enable an instantiated widget to obtain revocation information without having to query an online <abbr title="Certificate Revocation List">CRL</abbr> or OSCP server from each device. This is significantly more efficient and eases the load on CRL or OCSP servers.  Note, however, that the revocation information may not be as up to date as an online query. However, if this information is updated at the server in a timely manner before widget installations, then an online query would not be necessary at the client.</dd>
</dl><h4 class="no-num req" id="default-security-policy"><dfn>Default Security Policy</dfn></h4>

<p>A conforming specification <em class="ct">MUST</em> specify a default security policy
that limits the privileges afforded to a widget at runtime. The default security policy
<em class="ct">MUST</em> be specified in such a way that it forces a widget package to
explicitly request permission to use particular device capabilities (see also the
<a href="#security-declarations">Security Declarations</a> requirement).</p>

<dl><dt>Motivation:</dt>

<dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a> and
<a href="#security">security</a>.</dd>

<dt>Rationale:</dt>

<dd>To make the default behavior of a widget as benign as possible. For example, the
default security policy might be that a widget cannot access the network.</dd>

</dl><h4 class="no-num req" id="widget-black-white-listing"><dfn>Widget Black/White Listing</dfn></h4>

<p>A conforming specification <em class="ct">MAY</em> specify a mechanism that allows a
remote trusted authority to update black and/or white lists and the security policy
related to widget packages installed on the widget user agent.</p>

<dl><dt>Motivation:</dt>

<dd><a href="#current-development-practice-or-industry-best-practice">Current development practice or industry best-practice</a> and

<a href="#security">security</a>.</dd>

<dt>Rationale:</dt>

<dd>To provide the mechanisms that would enable the creation of trusted public
authorities for widgets. These authorities could serve to authorize or revoke widget
packages that other members of the community have found to exhibit undesirable aspects or
malicious behavior, which could potentially damage an end-user's device or breach their
privacy or security.</dd>
</dl><h4 class="no-num req" id="security-declarations"><dfn>Security Declarations</dfn></h4>
<p>A conforming specification <em class="ct">MUST</em> specify or recommend a means for
  declaring that an instantiated widget will require access to resources or services that
  have to the potential to introduce a security risk for an end user. A conforming
  specification <em class="ct">SHOULD</em> also make it possible to externalize and
  associate security declarations with a particular widget package (e.g., by allowing
  security declarations to be securely acquired from an external trusted authority over <cite><a href="#http">HTTP</a></cite>). This <em class="ct">MUST</em> include a means of declaring the APIs that a widget expects to access. When possible, a conforming specification <em class="ct">MUST</em> specify a means to verify the authenticity and integrity of security declarations included in the widget package (e.g. by using <a href="#digital-signatures">Digital Signatures</a>).</p>

<dl><dt>Motivation:</dt>
  <dd><a href="#security">Security</a>, and <a href="#current-development-practice-or-industry-best-practice">current development practice or industry
    best-practice</a>.</dd>
  <dt>Rationale:</dt>
  <dd>To declare the security intentions of the widget, allowing the widget user agent to,
    for example, confirm with the user before installing the widget, or adjust its policies
    before instantiating it. Example of security sensitive services that could require
    access-control include accessing end-user's storage device, or performing a cross-domain
    request.</dd>
</dl><h2 class="no-num" id="references"><dfn>References</dfn></h2>
<dl class="references"><dt><dfn id="ajax">Ajax</dfn></dt>

<dd><a href="http://www.adaptivepath.com/publications/essays/archives/000385.php">Ajax: A
New Approach to Web Applications</a>. J. J. Garrett. Adaptive Path.</dd>


  <dt><dfn id="bcp47">BCP 47</dfn></dt>
  <dd><cite><a href="http://www.rfc-editor.org/rfc/bcp/bcp47.txt">Tags for Identifying Languages</a></cite>, A. Phillips and M. Davis. September 2009.</dd>

  <dt><dfn id="css">CSS</dfn></dt>

  <dd><a href="http://www.w3.org/TR/CSS21/">Cascading Style Sheets, level 2, revision
  1</a>, B. Bos, T. Çelik, I. Hickson, and H. Wium Li.e. W3C.</dd>

  <dt><dfn id="dashboard-reference">Dashboard Reference</dfn></dt>

  <dd><a href="http://developer.apple.com/documentation/AppleApplications/Reference/Dashboard_Ref/index.html">
  Dashboard Reference</a>, Apple Computer, Inc. </dd>

  <dt><dfn id="digital-signatures-for-widgets">Digital Signatures for Widgets</dfn></dt>
  <dd><a href="http://dev.w3.org/2006/waf/widgets-digsig/">XML Digital Signatures for Widgets</a>. M. Cáceres, P. Byers, S. Knightley, F. Hirsch, M. Priestley (Work in Progress). W3C.</dd>

  <dt><dfn id="ecmascript">ECMAScript</dfn></dt>
  <dd><a href="http://www.ecma-international.org/publications/standards/Ecma-262.htm">ECMAScript
  Language Specification</a>, Third Edition. <abbr title="European Computer Manufacturers Association">ECMA</abbr>. </dd>

  <dt><dfn id="google-gadgets">Google Gadgets</dfn></dt>

  <dd><a href="http://desktop.google.com/script.html">Google Desktop Sidebar Scripting
  <abbr title="Application Programming Interface">API</abbr></a>, Google Inc.</dd>

  <dt><dfn id="html">HTML</dfn></dt>


  <dd><cite><a href="http://www.whatwg.org/specs/web-apps/current-work/">HTML - Living Standard</a></cite>.  I. Hickson. WHATWG. </dd>
   <dt><dfn id="http">HTTP</dfn></dt>

<dd><a href="http://www.ietf.org/rfc/rfc2616.txt">Hypertext Transfer Protocol --
HTTP/1.1</a>, R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, L. Masinter, P. Leach
and T. Berners-Lee. IETF. </dd>
  <dt><dfn id="i18n-xml">i18n-XML</dfn></dt>
  <dd><a href="http://www.w3.org/TR/xml-i18n-bp/">Practices for XML Internationalization</a>. Y. Savourel,  J. Kosek, R. Ishida.  Working Group Note. W3C.</dd>
  <dt><dfn id="iri">IRI</dfn></dt>

<dd><a href="http://www.ietf.org/rfc/rfc3987">Internationalized resource Identifiers
(IRIs)</a>, M. Duerst, M. Suignard. IETF. </dd>
<dt><dfn id="rfc2046" title="rfc2046">Media Type</dfn></dt>

<dd><a href="http://www.ietf.org/rfc/rfc2046.txt">Multipurpose Internet Mail Extensions
(MIME) Part Two: media types</a>, N. Freed and N. Borenstein. IETF.</dd>
  <dt><dfn id="mwbp">MWBP</dfn></dt>

  <dd><a href="http://www.w3.org/TR/mobile-bp/">Mobile Web Best Practices 1.0</a>. J.
  Rabin, C. McCathieNevile. W3C. </dd>
  <dt><dfn id="wcag-2.0">WCAG 2.0</dfn></dt>

<dd><a href="http://www.w3.org/TR/WCAG20/">Web Content Accessibility
Guidelines 2.0</a>, B. Caldwell,M. Cooper, L. Guarino Reid, G. Vanderheiden. W3C. </dd>


  <dt><dfn id="widgets1">Widget Packaging and Configuration</dfn></dt>
  <dd><a href="http://www.w3.org/TR/widgets/">Widget Packaging and XML
  Configuration</a>. M. Cáceres. W3C. </dd>


  <dt><dfn id="widget-updates">Widget Updates</dfn></dt>

  <dd><a href="http://dev.w3.org/2006/waf/widgets-updates/">Widget Updates</a>. M. Cáceres, R Tibbett, R. Berjon (Work in Progress). W3C.</dd>

  <dt><dfn id="rfc2119">RFC2119</dfn></dt>

<dd><a href="http://www.ietf.org/rfc/rfc2119.txt">Key words for use in RFCs to Indicate
Requirement Levels</a>, S. Bradner. IETF. </dd>
  <dt><dfn id="sidebar-reference">Sidebar Reference</dfn></dt>

  <dd><a href="http://windowssdk.msdn.microsoft.com/en-us/library/ms722795.aspx">Windows
  Sidebar Reference</a>, Microsoft Corporation.</dd>

  <dt><dfn id="unicode">Unicode</dfn></dt>

  <dd><em>The Unicode Standard</em>, The Unicode Consortium.</dd>
  <dt><dfn id="utf-8">UTF-8</dfn></dt>
<dd><a href="http://tools.ietf.org/html/rfc3629">UTF-8, a transformation format of ISO 10646</a>, F. Yergeau. IEFT. </dd>

  <dt><dfn id="web-idl">Web IDL</dfn></dt>
  <dd> <a href="http://dev.w3.org/2006/webapi/WebIDL/">Web IDL</a>. C. McCormack (Work in Progress). W3C.</dd>

  <dt><dfn id="widgets3">Widget Interface</dfn></dt>

  <dd><a href="http://dev.w3.org/2006/waf/widgets-api/">Widget Interface</a>. M. Cáceres (Work in Progress). W3C.</dd>


  <dt><dfn id="widget-uris">Widget URIs</dfn></dt>
  <dd><a href="http://dev.w3.org/2006/waf/widgets-uri/">Widget URIs</a>. M. Cáceres (Work in Progress). W3C.</dd>

    <dt><dfn id="w3c-process">W3C Process</dfn></dt>

  <dd><a href="http://www.w3.org/2005/10/Process-20051014/">World Wide Web Consortium
  Process Document</a>. I. Jacobs, W3C. </dd>

  <dt><dfn id="view-modes">View Modes</dfn></dt>
  <dd><a href="http://www.w3.org/TR/view-mode/">The 'view-mode' Media Feature</a>. R. Berjon and M. Cáceres (Work in Progress). W3C.</dd>

  <dt><dfn id="xml">XML</dfn></dt>
  <dd><a href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible Markup Language (XML)
    1.0 Specification (Second Edition)</a>, T. Bray, J. Paoli, C. M. Sperberg-McQueen, E.
  Maler. W3C.</dd>
<dt><dfn id="x.509v3">X.509v3</dfn></dt>
<dd><a href="http://www.ietf.org/rfc/rfc5280.txt">Internet X.509 Public Key
  Infrastructure Certificate and Certificate Revocation List (CRL) Profile</a>, D. Cooper,
  S. Santesson, S. Boeyen, R. Housley, and W. Polk. IETF.</dd>
</dl><h2 class="no-num" id="acknowledgments">Acknowledgments</h2>

<p>The editor would like to thank to the following people who have reviewed or otherwise contributed to this
document (ordered by first name): </p>
<p>Alexander Dreiling, Anne van Kesteren, Arthur Barstow, Arun Ranganathan, Bárbara Barbosa Neves Benoit Suzanne, Bert Bos, Bradford Lassey, Bryan Sullivan, Cameron McCormack, Charles McCathieNevile, Cliff Schmidt, Claudio Venezia, Coach Wei, Corin Edwards, Cynthia Shelly, Cyril Concolato, Dan Brickley, David Pollington, David Rogers, Dean Jackson, Doug Schepers, Ed Voas, Gene Vayngrib,Guido Grassel, Jay Sweeney, Jim Ley, Jon Ferraiolo, Jose Manuel Cantera Fonseca, Josh Soref, Kevin Lawver, Krzysztof Maczyński, Lachlan Hunt, Mark Baker, Marc Silbey, Mikko Pohja, Michael Smith, Nick Allott, Olli immonen, Paddy Byers, Philipp Heltewig, Richard Tibbett, Sally Cain, Sean Mullan, Stephen Paul Weber, Steven Faulkner, Thomas Landspurg, Yang Wong, Zachary Fitz-Walter.</p>
</body></html>