You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1499 lines
99 KiB
1499 lines
99 KiB
<!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 "web widgets", 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><icon src="icons/cat.ico'/></code>). Or, for example, addressing an image within a widget package from within a HTML start file (e.g. <code><img src="/backgrounds/sky.png'></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 ".html,
|
|
.svg, etc." 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., "preferences" 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 "network" 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><img
|
|
src="images/bg.png'/></code> where the <code>src</code> attribute
|
|
resolves to something similar to
|
|
"<code>widget://engine/myWidget.wgt/images/bg.png</code>" or "<code>http://localhost/myWidget.wgt/images/bg.png</code>").</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>
|