W3C

Widgets 1.0: Requirements

W3C Working Draft 15 September 2008

This version:
http://www.w3.org/TR/2008/WD-widgets-reqs-20080915/
Latest published version:
http://www.w3.org/TR/widgets-reqs/
Previous versions:
http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/
http://www.w3.org/TR/2008/WD-widgets-reqs-20080414/
http://www.w3.org/TR/2007/WD-widgets-reqs-20070705/
http://www.w3.org/TR/2007/WD-widgets-reqs-20070209/
http://www.w3.org/TR/2006/WD-WAPF-REQ-20061109/
http://www.w3.org/TR/2006/WD-WAPF-REQ-20060821/
Latest editor's draft
http://dev.w3.org/2006/waf/widgets-reqs/
Version history:
Twitter messages (non-editorial changes only): http://twitter.com/widgetspecs (RSS)
Editor:
Marcos Caceres, Invited Expert

Abstract

This document lists the design goals and requirements that specifications would need to address in order to standardize various aspects of widgets. A Widget 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.

Status of this Document

Publication as a Working Draft 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.

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 W3C technical reports index at http://www.w3.org/TR/.

You can always find the latest Editor's Draft of this document in the W3C's CVS repository; it is updated on a fairly regular basis.

This is the 15 September 2008 Second Last Call Working Draft version of the "Widgets 1.0: Requirements" document (formerly "Widgets 1.0: Requirements"). The Last Call period ends on 13 October 2008. This version reflects over two years of gathering and refining requirements for the Widgets 1.0 family of specifications. The requirements were gathered by extensive consultation with W3C members and the public, via the Working Group's mailing lists (WAF archive, WebApps archive). The purpose of this Last Call is to give external interested parties a final opportunity to publicly comment on the list of requirements. The Working Group's goal is to make sure that vendor's requirements for Widgets are complete and have been effectively captured. The Widgets 1.0 family of specifications will set out to address as many requirements as possible (particularly the ones marked with the keywords must and should).

This document is produced by the Web Applications (WebApps) Working Group (WG). This WG is part of the Rich Web Clients Activity and this activity is within the W3C's Interaction Domain. The public is encouraged to send comments to the WebApps Working Group's public mailing list public-webapps@w3.org (archive). See W3C mailing list and archive usage guidelines.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures 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 Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. Introduction

A widget 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. In this document, the runtime environment in which a widget is run is referred to as a widget user agent. 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 genetic user agent (eg. a Web browser). A widget running on a widget user agent is referred to as an instantiated widget. Prior to instantiation, a widget exists as a widget resource. For more information and definitions related to widgets, see the Widget Landscape document.

As argued by the Widget Landscape document, there is currently no formally standardized way to author, package, digitally sign or internationalize a widget resource for distribution and deployment on the Web. In the widget space, although many successful widget user agents are now on the market, widgets built for one widget user agent are generally not able to run on any other widget user agent.

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 W3C principles, and is as interoperable as possible with existing market-leading user agents and existing Web browsers.

To be clear, this specification describes the requirements for installable/desktop or mobile widgets (akin to Apple's Dashboard, Opera Widgets, Opera Mobile Widgets. or Yahoo!'s Konfabulator Widgets). This document does not address the requirements of "web widgets", such as iGoogle Gadgets or Windows Live Gadgets, which are being specified by the Open Ajax Alliance's IDE Working Group. Please see the Widget Landscape document for a discussion on the differences between widgets and web widgets.

2. Conformance

This section is normative.

The key words MUST, MUST NOT, required, not required, SHOULD, should not, recommended, MAY, and optional in the normative parts of this document are to be interpreted as described in RFC2119.

This specification only applies to one class of product: W3C Technical Reports. The working group will attempt to standardize widgets by addressing the requirements listed in this document through the Widgets 1.0 family of specifications, which include:

Note: Only normative statements marked with the keywords MUST and SHOULD are required to be standardized by the Widgets 1.0 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 Widgets 1.0 family of specifications.

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. Never the less, 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 (e.g. HTML5), was made for the following reasons:

A conforming specification is one that addresses one or more requirements listed in this document. A conforming specification SHOULD attempt to address requirements marked with the keywords should or may 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 Working Group members, and through communication with vendors and the public on the Working Group's public mailing list public-webapps@w3.org (archive).

3. Design Goals

This section is informative.

This section lists the design goals that the working group recommends a conforming specification adopt when attempting to standardize the various standardizable aspects of widgets identified in the Widget Landscape document. The requirements are directly motivated by the following design goals. The design goals are listed in alphabetical order.

Accessibility:
A conforming specification needs to support relevant accessibility guidelines, such as WCAG 2.0.
Compatibility with other standards:
A conforming specification needs to maintain compatibility with, or directly make use of, other standards where possible.
Current development practice or industry best-practice:
A conforming specification needs to consider the development practices currently used by widget developers and promote relevant industry best-practice, such as MWBP and MWABP.
Device independence:
A conforming specification needs to support relevant device independence guidelines.
Ease of use:
A conforming specification needs to specify solutions that are easy to use and avoid unnecessary complexity, meaning that a widget resource should be easy for authors to create without requiring special or expensive propriety software, and easy for end-users to acquire and install/run.
Internationalization and localization:
A conforming specification needs to implement relevant internationalization and localization guidelines, such as i18n-XML and BCP 47, as well as consider current practical internationalization solutions used by the widget development community.
Interoperability:
A conforming specification needs to attempt to be as interoperable as possible with existing market-leading widget user agents.
Longevity:
A conforming specification needs to be specified in such a way that it ensures that a widget resource can still be processed well into the future (e.g. 100 years from date of the a specification reaching Recommendation Status W3C Process).
Security:
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.
Web and offline distribution:
A conforming specification needs to deal with cases where an end-user acquires a widget resource over HTTP or via some other non HTTP-based (offline) means, such as a local file system, Bluetooth 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.

4. Requirements

This section is normative.

This section enumerates the requirements 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 survey of market-leading widget user agents.

4.1 Widget Resource Packaging

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:

R1. Packaging Format

A conforming specification MUST 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 MUST specify exactly which aspects of the packaging format are to be supported by conforming widget user agents.

Motivation:
Compatibility with other standards, Web and offline distribution, device independence, ease of use, current development practice or industry best-practice, internationalization and localization, and longevity.
Rationale:
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.

R2. MIME Type

A conforming specification MUST recommend that a conforming widget resource be sent over HTTP with a formally registered MIME Type that is specific to the Widgets 1.0 Family of specifications. The Working Group MUST formally register the MIME type with the Internet Assigned Numbers Authority (IANA). A conforming specification MUST specify how a widget user agent will process a widget resource that was served with an unsupported MIME type or when the MIME type is unspecified.

Motivation:
Compatibility with other standards, Web and offline distribution, and ease of use.
Rationale:
To provide a formal means for an authors to denote that a widget resource conforms to an appropriate specification when a widget resource is served over HTTP. In addition, the MIME type could potentially be used in conjunction with an auto-discovery mechanism, such as Atom Auto-Discovery, to facilitate deployment of a widget resource.

R3. File Extension

A conforming specification MUST specify a file extension for widget resources not intended to be sent over HTTP. In addition, a conforming specification SHOULD recommend that a widget resource always contains a file extension, even when being sent over HTTP.

Motivation:
Device independence, ease of use, Web and offline distribution, and longevity.
Rationale:
When a MIME Type is not present, as is 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 resource with the appropriate widget user agent. However, when the widget is distributed over HTTP and a MIME type is present, a file extension may not be required. Also note, in some cases, Web servers may rely on a file extension to correctly set a widget resource's MIME type in the HTTP headers.

R4. Internal Abstract Structure

A conforming specification MUST 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 SHOULD allow authors to add and remove resources of a widget resource without needing to recreate the widget resource.

Motivation:
Ease of use and current development practice or industry best-practice.
Rationale:
To provide authors with a format that is easy to use in a development process.

R5. Reserved Resources and Directory Names

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

Motivation:
Ease of use, compatibility with other standards, and current development practice or industry best-practice.
Rationale:
To make it more efficient for widget user agents to dereference resources at runtime. For example, the packaging format may require authors to place all resources inside a 'resources' directory located at the root of the widget resource.

R6. Addressing Scheme

A conforming specification MUST specify or recommend an addressing scheme to address the individual resources within the widget resource at runtime. The addressing scheme MUST be able to address individual widget instances, while potentially allowing widgets to address each other. The addressing scheme MUST NOT expose the underlying file system (if any) to the instantiated widget and an instantiated widget MUST NOT be able to address resources outside the widget resource via the addressing scheme. The addressing scheme SHOULD be one that web authors would feel comfortable using or to which they are already accustomed.

Motivation:
Ease of use, compatibility with other standards, current development practice or industry best-practice, and security.
Rationale:
To allow resources to be resolved and normalized within DOM attributes. To make it easy for authors to address and load resources into their instantiated widgets, either declaratively or programmatically. For example, addressing a resource via an IRI reference (e.g. <img src="images/bg.png'/> where the src attribute resolves to something akin to "widget://myWidget/images/bg.png"). To disable access by widget instances to the underlying file system (if any) or other resources which are not instances of the same widget or resources contained in the widget resource used to create the current set of widget instances.

R7. Multilingual Resource Names

A conforming specification MUST 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 for a declaration of the character encoding used or specify what it is. The UTF-8 character encoding SHOULD be either the default (if multiple encodings are allowed) or sole encoding used.

Motivation:
Internationalization and localization, current development practice or industry best-practice, ease of use, interoperability, and longevity.
Rationale:
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.

R8. Localization Guidelines

A conforming specification MUST provide guidelines that explain to authors how resources need to be structured for the purpose of internationalization.

Motivation:
Internationalization and localization, current development practice or industry best-practice, ease of use, and interoperability.
Rationale:
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. 'resources/en/' for all English content, and 'resources/en-au/' for further localized Australian-English content, and so on).

R9. Automatic Localization

A conforming specification SHOULD specify a processing model that automatically localizes content when authors follow the localization guidelines.

Motivation:
Internationalization and localization, current development practice or industry best-practice, ease of use, and interoperability.
Rationale:
To define an internationalization model, complete with error handling, to reduce the amount of engineering work an author needs to do in order to localize a widget.

R10. Device Independence Delivery

A conforming specification MUST recommend a packaging format that is suitable for delivery to many devices, particularly Web-enabled mobile devices.

Motivation:
Device independence, Web and offline distribution, and interoperability.
Rationale:
To recommend a packaging format that is interoperable with desktops and for mobile devices, where the widget space is currently growing.

R11. Data Compression

A conforming specification MUST recommend a packaging format that supports both uncompressed data and OPTIONAL data compression. A conforming specification SHOULD 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.

Motivation:
Web and offline distribution, device independence, and current development practice or industry best-practice.
Rationale:
To make a widget resource smaller for delivery over HTTP, where the cost of data access is sometimes expensive for end-users. Compressing might also help with transfer speed when a widget resource 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.

4.2 Configuration Document

This section enumerates the requirements that a conforming specification needs to address to standardize the configuration document. The objective of this section is to ensure that a conforming specification specifies a configuration document format that defines:

R12. Format and Schema

A conforming specification MUST 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 SHOULD specify a formal schema for the language, as well as define any configuration defaults. The schema SHOULD NOT be a normative part of the conforming specification, but MUST be suitable for use by conformance checkers. A conforming specification MUST recommend that configuration documents be encoded in Unicode's UTF-8. A conforming specification MAY specify the configuration document language using alternative standardized data interchange formats (e.g. JSON) and schema.

Motivation:
Compatibility with other standards, current development practice or industry best-practice, ease of use, internationalization and localization, longevity, and accessibility.
Rationale:
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 as language is XML. XML is generally accepted and understood by widget authors and parsed by all market-leading widget user agents, and XML parsers generally have reasonable support for Unicode, which allows for effective internationalization and localization.

R13. Widget Metadata

A conforming specification MUST specify the structure and semantics of XML elements that represent metadata about a widget. The conforming specification MUST describe a model for how that metadata is to be processed by a widget user agent. A conforming specification MUST specify graceful error handling procedures for all metadata elements for when values are in error, or contradictory to the system, or declared erroneously by an author. The metadata MUST be extractable, processable and reusable in other contexts (for instance, to create an online gallery). In addition, a conforming specification SHOULD make it clear to authors which elements are optional and which elements are mandatory.

Motivation:
Current development practice or industry best-practice, interoperability, and accessibility.
Rationale:
To provide authors with a practical set of metadata elements that describe various aspects of the widget that may be used in various contexts. An example of reuse of metadata could include the ability to combine the widget metadata with GRDDL to produce RDF metadata descriptions about a widget.

R14. Authorship and Widget Metadata

A conforming specification MUST specify the structure and semantics of elements that represent data about the authorship of a widget, including an author's name, e-mail, and organization. In addition, a conforming specification MUST 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.

Motivation:
Current development practice or industry best-practice, and interoperability.
Rationale:
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.

R15. Copyright Notice and License Metadata

A conforming specification MUST specify the structure and semantics of fields that explicitly reference, or otherwise include, a software license agreement or notice. In addition, A conforming specification MUST 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.

Motivation:
Current development practice or industry best-practice, and interoperability.
Rationale:
To provide authors with a means to legally declare how a widget and its various resources can be used by end-users. For example, an author may include a GNU-style license that allows others to reuse any source code.

R16. Visual Rendering Dimensions

For widgets that make use of a rendering context, a conforming specification SHOULD specify an OPTIONAL means for an author to declare the initial visual dimensions for an instantiated widget in a way that is device independent (e.g. via CSS pixels). A conforming specification MUST 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.

Motivation:
Ease of use, device independence, and current development practice or industry best-practice.
Rationale:
To set up the rendering context for an instantiated widget in a way that is compatible on a range of devices.

R17. Declarative Bootstrap

A conforming specification MUST specify a declarative bootstrap mechanism that addresses the start file that is to be initially instantiated at runtime (the instantiated widget). The bootstrap mechanism MUST NOT be able to address or instantiate local resources outside the scope of the widget resource. However, the bootstrapping mechanism MAY be able to address a resource on the Internet, but only of a MIME type allowed by the automated bootstrap requirement (below) or resources that are of media types supported by a widget user agent. A conforming specification MAY also allow authors to declaratively bootstrap proprietary resources within the widget resource, 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 MUST occur as described in the automated bootstrap requirement.

Motivation:
Ease of use, current development practice or industry best-practice, and security.
Rationale:
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. '/ui/clock.svg'). Alternatively, resource might be a HTML document that when combined with the visual rendering dimensions requirement displays at the appropriate size.

R18. Automated Bootstrap

A conforming specification Should specify an automated model for finding the start file of the widget in the absence of a declarative bootstrap. The automated bootstrap model MUST NOT be able to address resources outside the scope of the widget resource and MUST NOT address resources on the Web over HTTP or any other protocol. The widget user agent SHOULD be allowed to select its preferred format for the start file, and then it should locate that resource first before attempting to locate other resources.

Motivation:
Ease of use, device independence, current development practice or industry best-practice, and internationalization and localization.
Rationale:
For example, the conforming specification could specify a model that searches for a default file name (index.htm, index.html, index.svg, etc.) firstly within localized directory names, as required by automatic localization, and then within the directories of the widget resource. If that search fails, then the widget user agent could try finding files with extensions ".html, .svg, etc." starting from the root directory.

R19. Iconic Representations

A conforming specification MUST 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 should not limit iconic representations to static images and it SHOULD provide support for alternative text representations of an icon where possible. A conforming specification SHOULD also recommend a default icon MIME type and file name.

Motivation:
Ease of use, device independence, current development practice or industry best-practice, internationalization and localization, and accessibility.
Rationale:
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.

R20. Configuration Parameters

A conforming specification MUST 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 MUST 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 SHOULD 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.

Motivation:
Ease of use and current development practice or industry best-practice.
Rationale:
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 width = 50 indicating the 50 as the value for visual width. Or, in the absence of an author-declared width, the widget user agent will automatically set the width to some standardized value (eg. 300).

R21. Security Declarations

A conforming specification MUST 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 SHOULD also make it possible to externalize and associate security declarations with a particular widget resource (e.g., by allowing security declarations to be acquired from an external trusted authority over HTTP(S)). This MUST include a means of declaring the APIs that a widget expects to access. When possible, a conforming specification MUST specify a means to verify the authenticity and integrity of security declarations included in the widget resource (e.g. by using Digital Signatures).

Motivation:
Security and current development practice or industry best-practice.
Rationale:
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.

R22. Configuration Document Independence

A conforming specification MUST specify the configuration document in such a way that it can be used independently of the widget resource that contains it. A conforming specification MAY provide guidelines for how the configuration document can be used separately from a widget resource.

Motivation:
Ease of use, Web and offline distribution, and device independence.
Rationale:
To allow the configuration document to be extracted and used 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 resource 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 resource. This may be particularly useful for users of widgets on mobile devices, where the cost of downloading data can sometimes be expensive.

4.3 Scripting Interfaces

This section enumerates the requirements that a conforming specification needs to address to standardize an API for widgets. The objective of this section is to ensure that a conforming specification specifies an API that allows authors to, amongst other things:

R23. Instantiated Widget API

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

Motivation:
Ease of use, compatibility with other standards, and current development practice or industry best-practice.
Rationale:
To allow authors to make their widgets interactive. See for example Apple's widget Object described in the Dashboard Reference and Microsoft's System.Gadget Object described in the Sidebar Reference.

R24. Web IDL Definitions

A conforming specification MUST specify the APIs in this section in Web IDL or a similar standardized interface definition language.

Motivation:
Compatibility with other standards, current development practice or industry best-practice, and internationalization and localization
Rationale:
To facilitate implementation in ECMAScript, 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.

R25. Configuring Runtime Properties

A conforming specification SHOULD specify a set of interfaces that expose relevant properties and methods of the widget user agent.

Motivation:
Ease of use, compatibility with other standards, and current development practice or industry best-practice.
Rationale:
To allow authors to access the 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 Sidebar Reference.

R26. Storage of Instance Specific Preferences

A conforming specification MUST specify a set of interfaces for dynamically getting and setting preferences for the widget instance.

Motivation:
Ease of use, Compatibility with other standards, and current development practice or industry best-practice.
Rationale:
To provide a means for authors to allow end-users to dynamically change any settings they may have set in the past.

R27. Widget State Change Events

A conforming specification must 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 must have associated events which can be consumed by event handlers, such as scripts. Additionally the API must expose the current state. A conforming specification MUST NOT require the widget user agent to send events to the widget immediately, and should allow the widget user agent to dispatch the events at its convenience.

Motivation:
Current development practice or industry best-practice, and ease of use.
Rationale:
To allow authors to capture state-change events generated by the instantiated widget.

R28. Network State Change Events

A conforming specification MUST specify a means that allows authors to check if the widget instance is connected to the network. A conforming specification MUST define the scope of the term network and MUST specify a means by which connection and disconnection events can be captured by an author through script. A conforming specification MUST NOT guarantee event delivery, as there may be cases where a device is running low on power and can not afford to deliver them.

Motivation:
Current development practice or industry best-practice, and ease of use.
Rationale:
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.

R29. Modal Priority

A conforming specification SHOULD 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 SHOULD recommend that widget user agent find a suitable way to draw the end-user's attention.

Motivation:
Current development practice or industry best-practice, ease of use, and accessibility.
Rationale:
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.

R30. Device Specific APIs and Services

A conforming specification SHOULD 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 not required to specify any APIs to device specific resources or services, but SHOULD provide some means of binding to those APIs if they are available and the user agrees. A conforming specification SHOULD specify that bindings MUST NOT occur without consulting the user or a policy which exists to represent the end user (or the owner of the device).

Motivation:
Current development practice or industry best-practice, and ease of use.
Rationale:
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.

Note: There are other WGs working on this requirements such as the Ubiquitous Web Applications Working Group (UWA-WG), and the Open Mobile Alliance (OMA) Device Capabilities Working Group.

R31. XMLHttpRequest

A conforming specification MUST recommend that a widget user agent implement the XMLHttpRequest object specification.

Motivation:
Current development practice or industry best-practice and interoperability.
Rationale:
To allow the creation of Ajax-style applications.

R32. Cross-Widget Communication

A conforming specification MAY specify a model and API to allow multiple instantiated widgets to securely communicate with each other. A conforming specification attempting to address cross-widget communication SHOULD provide a way for users to be aware of widget dependencies and to introduce widgets to each other ("pairing" and "unparing").

Motivation:
Current development practice or industry best-practice.
Rationale:
To allow widgets to communicate with each other. For example, when a news widget receives a news item about a particular company, it could tell a stock quotes widget to display any changes in that company's share price.

R33. Icon API

A conforming specification SHOULD specify a means that allows authors to control the iconic representation of a widget resource at runtime.

Motivation:
Current development practice or industry best-practice, and accessibility.
Rationale:
To allow widgets to communicate events and state changes to the user in contexts outside the running widget. For instance, for a weather widget, an icon could change to reflect the current weather conditions.

R34. Configuration Document Data

A conforming specification SHOULD specify a means that allows authors to access data they declared in the configuration document for the widget resource.

Motivation:
Current development practice or industry best-practice.
Rationale:
To allow authors at runtime to easily access metadata declared in the configuration document.

R35. Open Default System Web Browser

A conforming specification SHOULD specify a means that allows authors to open IRIs in a browsing context outside the widget user agent.

Motivation:
Current development practice or industry best-practice.
Rationale:
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.

4.4 User Interface Language

This section enumerates the requirements that a conforming specification needs to address to standardize a user interface language for widgets. The objective of this section is to ensure that a conforming specification mandates an accessible language that is well-suited for creating user interfaces.

R36 Language Accessibility

A conforming specification MUST specify that the language used to declare the user interface of a widget be either HTML or a language that is accessible at the various levels specified by the WCAG 2.0 (perceivable, operable, understandable, and robust): specifically, the language MUST 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 MUST be available to screen readers and other assistive technologies, to allow relevant sections of text and functionality to be accessed.

Motivation:
Compatibility with other standards, current development practice or industry best-practice, ease of use, and accessibility.
Rationale:
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.

4.5 User Agents

This section enumerates the requirements that a conforming specification needs to address 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 Web services.

R37. Automatic Updates

A conforming specification MUST specify a model to allow widget user agents to automatically check if a new version of a widget resource has become available online or from local storage. A conforming specification MUST 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 MUST preserve the identity of a widget, meaning that that preferences previously set by the user are retained after the update process. A conforming specification SHOULD recommend that, when possible, automatic updates be conducted over a secure communication channel. In addition, a conforming specification SHOULD 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 SHOULD specify that signature verification policies be applied to updates in a manner that is consistent with those applied upon original installation of the widget.

Motivation:
Security, current development practice or industry best-practice, and interoperability.
Rationale:
To allow authors to provide updates for a widget resource online. For example, the author could declare in the configuration document an IRI for where the widget user agent can be check for updates. If an update to a widget resource becomes available, then the widget user agent could ask the end-user if they want to download the widget.

R38. Multiple Widget Instances

A conforming specification MUST recommend that a widget user agent allow multiple instances of a widget resource to be instantiated. A conforming specification MAY recommend that implementations which have sufficient resources (CPU, memory, etc.) run widgets concurrently as separate processes.

Motivation:
Current development practice or industry best-practice and interoperability.
Rationale:
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.

R39. Persistent Storage of Preferences

A conforming specification MUST recommend that a widget user agent implement a means to persistently store user preferences for each widget. A widget user agent MUST persistently retain a widget's preference in the case where a widget is re-instantiated or the widget user agent is restarted.

Motivation:
Current development practice or industry best-practice, Web and offline distribution, and security.
Rationale:
To allow widgets to be closed and re-instantiated without the end-user having to reset the preferences 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 preference.

R40. Runtime Security Exceptions

A conforming specification MUST specify runtime exceptions for when a widget's script attempts to perform an action it's not authorized to perform.

Motivation:
Current development practice or industry best-practice and security.
Rationale:
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.

4.6 Security and Digital Signatures

This section enumerates the requirements that a conforming specification needs to address 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:

R41. Digital Signatures

A conforming specification MUST specify a means to verify the authenticity and data integrity of all resources in a widget resource, with the exception of any resources explicitly excluded by the specification (e.g. the digital signature file itself). A conforming specification MUST provide these capabilities by specifying or recommending a processing model for generating and verifying a digital signature associated with a widget resource. The digital signature scheme MUST be compatible with existing Public Key Infrastructures (PKI), particularly X.509v3.

Motivation:
Security and current development practice or industry best-practice.
Rationale:
To provide a means to verify the authenticity, check the data integrity and provide persistent proof of origin of the widget resource. 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.

R42. Multiple Signatures and Certificate Chains

A conforming specification SHOULD recommend that it should be possible for a widget resource to contain multiple independent digital signatures (i.e. it be possible to include multiple signatures and associated certificate chains). A conforming specification MUST specify the expected behavior when multiple signatures and certificate chains are provided. A conforming specification MUST 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 resource SHOULD be treated as unsigned (meaning that widget is treated as if it had no digital signature).

Motivation:
Web and offline distribution, device independence, and current development practice or industry best-practice.
Rationale:
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.

R43. Signature Document Independence

A conforming specification MUST recommend a digital signature format that allows for the signature value(s) and associated certificate chain(s) (if any) associated to the widget resource to be used independently of the widget resource. A conforming specification SHOULD provide guidelines for how any digital signature can be used separately from a widget resource.

Motivation:
Web and offline distribution, device independence, and current development practice or industry best-practice.
Rationale:
To allow the digital signature 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 resource 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 resource without needing to download the entire widget resource. 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 resource 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.

R44. Support for Multiple Message Digest Algorithms

A conforming specification MUST recommend that where the integrity of data is protected using a message digest, it MUST be possible to use the SHA-1 message digest algorithm or the SHA-256 message digest algorithm. Due to known weaknesses in the SHA-1 algorithm and the expected lifetime of implementations, a conforming specification MUST strongly recommend the use of SHA-256 to ensure that the overall security of the solution is maintained.

Motivation:
Security and longevity.
Rationale:
To provide a transitional means for developers to move towards using the more secure SHA-256 hashing algorithm.

R45. Support for Multiple Signature Algorithms

A conforming specification MUST recommend that where a widget resource is digitally signed, either the DSA Signature algorithm and the RSA Signature algorithm be used. A conforming specification MUST recommend that widget user agents support processing of digital signatures created with the DSA signature algorithm or the RSA signature algorithm.

Motivation:
Security, longevity, and current development practice or industry best-practice.
Rationale:
To support two algorithms to mitigate against the risk that weaknesses are found with a selected algorithm.

R46. Key Lengths

A conforming specification MUST recommend that widget user agents support processing RSA Signature with key lengths up to at least 2048 bits. In addition, a conforming specification MUST recommend support for DSA Signature with key lengths up to at least 2048 bits. A conforming specification MUST recommend to authors that widget packages be signed with RSA with key lengths of at least 2048 bits or be signed with DSA with key lengths of at least 2048 bits.

Motivation:
Security and longevity.
Rationale:
To be in-line with current security recommendations and provide longevity of the system security.

R47. Key Usage Extension

A conforming specification MUST specify the expected use of valid key usage extensions and when present (in end entity certificates) MUST specify that implementations verify that the extension has the digitalSignature bit set (as defined in X.509v3). A conforming specification MUST specify that implementations recognize the extended key usage extension and when present (in end entity certificates) verify that the extension contains the id-kp-codeSigning object identifier.

Motivation:
security.
Rationale:
To maintain compliance to X.509v3 (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 resources.

R48. Inclusion of Revocation Information

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

Motivation:
Security.
Rationale:
To provide up-to-date revocation information, when it is needed by the widget user agent, without requiring a query to an online CRL or OSCP server from each device. This is a lot more efficient and eases the load on CRL or OCSP servers.

R49. Default Security Policy

A conforming specification MUST specify a default security policy that limits the privileges afforded to a widget at runtime. The default security policy MUST be specified in such a way that it forces a widget package to explicitly request permission to use particular device capabilities (see also the Security Declarations requirement).

Motivation:
Current development practice or industry best-practice and security.
Rationale:
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.

R50. Widget Black/White Listing

A conforming specification MAY 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.

Motivation:
Current development practice or industry best-practice and security.
Rationale:
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.

References

Normative References

HTML
HTML 4.01 Specification, D. Raggett, A. Le Hors, I. Jacobs, 24 December 1999. Available at http://www.w3.org/TR/html401/
HTTP
Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, L. Masinter, P. Leach and T. Berners-Lee, June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt
HTTP Over TLS. E. Rescorla. May 2000. http://www.ietf.org/rfc/rfc2818.txt
IRI
Internationalized resource Identifiers (IRIs), M. Duerst, M. Suignard. IETF, January 2005. RFC3987 is Available at http://www.ietf.org/rfc/rfc3987
MIME Type
Multipurpose Internet Mail Extensions (MIME) Part Two: media types, N. Freed and N. Borenstein, November 1996. Available at http://www.ietf.org/rfc/rfc2046.txt.
RFC2119
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt
Unicode
The Unicode Standard, The Unicode Consortium, Version 5.
WCAG 2.0
Web Content Accessibility Guidelines 2.0, B. Caldwell,M. Cooper, L. Guarino Reid, G. Vanderheiden, 30 April 2008. W3C Candidate Recommendation. Available at http://www.w3.org/TR/2008/CR-WCAG20-20080430/
Web IDL
Web IDL. C. McCormack. W3C Working Draft 29 August 2008. Available at http://www.w3.org/TR/WebIDL/
X.509v3
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, D. Cooper, S. Santesson, S. Boeyen, R. Housley, and W. Polk. May 2008. RFC5280 is available at http://www.ietf.org/rfc/rfc5280.txt
XMLHttpRequest
The XMLHttpRequest object, A. van Kesteren, 2006, W3C Working Draft. Available at http://www.w3.org/TR/XMLHttpRequest/

Informative References

Ajax
Ajax: A New Approach to Web Applications. J. J. Garrett. February 18, 2005. Adaptive Path. Available at http://www.adaptivepath.com/publications/essays/archives/000385.php
APIs and Events
Widgets 1.0: APIs and Events. M. Caceres. Forthcoming W3C Working Draft. Latest Editor's Draft available at http://dev.w3.org/2006/waf/widgets-api/
Atom Auto-Discovery
Atom Autodiscovery, M. Pilgrim, P. Ringnalda. ATOMPUB Working Group (Draft), May 2005-. Available at http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html
Bluetooth
Bluetooth Core Specification 2.1. Available at http://www.Bluetooth.com/NR/rdonlyres/F8E8276A-3898-4EC6-B7DA-E5535258B056/6545/Core_V21__EDR.zip
BCP 47
Tags for Identifying Languages. A. Phillips and M. Davis. Best Current Practice 47 September 2006. Available at http://www.rfc-editor.org/rfc/bcp/bcp47.txt
CSS
Cascading Style Sheets, level 2, revision 1, B. Bos, T. Çelik, I. Hickson, and H. Wium Li.e., W3C Candidate Recommendation 19 July 2007. Available at http://www.w3.org/TR/CSS21
Dashboard Reference
Dashboard Reference, Apple Computer, Inc, May 2006. Available at http://developer.apple.com/documentation/AppleApplications/Reference/Dashboard_Ref/index.html
Digital Signatures
Widgets 1.0: Digital Signatures. M. Caceres. W3C Working Draft. Latest Editor's Draft available at http://dev.w3.org/2006/waf/widgets-digsig/
DSA Signature
FIPS PUB 186-2. Digital Signature Standard (DSS). U.S. Department of Commerce/National Institute of Standards and Technology. http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf
ECMAScript
ECMAScript Language Specification, Third Edition. ECMA, December 1999. Available at http://www.ecma-international.org/publications/standards/Ecma-262.htm
Google Gadgets
Google Desktop Sidebar Scripting API, Google Inc., 2006. Available at http://desktop.google.com/script.html
GRDDL
Gleaning Resource Descriptions from Dialects of Languages (GRDDL). D. Connolly. W3C Recommendation. 11 September 2007 http://www.w3.org/TR/2007/REC-grddl-20070911/
HTML5
HTML 5: A vocabulary and associated APIs for HTML and XHTML. I. Hickson and D. Hyatt. W3C Working Draft 22 January 2008. http://www.w3.org/TR/2008/WD-html5-20080122/
i18n-XML
Practices for XML Internationalization. Y. Savourel, J. Kosek Best Richard IshidaW3C Working Group Note 13 February 2008 http://www.w3.org/TR/xml-i18n-bp/
MWBP
Mobile Web Best Practices 1.0. J. Rabin, C. McCathieNevile, W3C Recommendation, July 2008. Available at http://www.w3.org/TR/mobile-bp/
MWABP
Mobile Web Application Best Practices. B. Sullivan. A. Connors, W3C Working Draft (Recommendation), July 2008. Available at http://www.w3.org/TR/mwabp/
Packaging and Configuration
Widgets 1.0: Packaging and Configuration. M. Caceres. W3C Working Draft. Latest Editor's Draft available at http://dev.w3.org/2006/waf/widgets/
RDF
RDF/XML Syntax Specification (Revised), Dave Beckett, Editor, W3C Recommendation, 10 February 2004, . Available at http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/
Remote and Local Updates
Widgets 1.0: Remote and Local Updates. M. Caceres. Forthcoming W3C Working Draft. Latest Editor's Draft available at http://dev.w3.org/2006/waf/widgets-updates/
RSA Signature
RFC 2437. PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski, J. Staddon. October 1998. http://www.ietf.org/rfc/rfc2437.txt
Runtime Security Policies
Widgets 1.0: Runtime Security Policies. Forthcoming W3C Working Draft. No draft publicly available.
Sidebar Reference
Windows Sidebar Reference, Microsoft Corporation, 2006. Available at http://msdn2.microsoft.com/en-us/library/aa965853.aspx
Widget Landscape
Widgets 1.0: The Widget Landscape. M. Caceres. W3C Working Draft (Working Group Note). Available at http://www.w3.org/TR/widgets-land/
W3C Process
World Wide Web Consortium Process Document. I. Jacobs, W3C. 14 October 2005. Available at http://www.w3.org/2005/10/Process-20051014/
XML
Extensible Markup Language (XML) 1.0 Specification (Second Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, 6 October 2000. Available at http://www.w3.org/TR/REC-xml/
XML i18n Best Practices
W3C Best Practices for XML Internationalization. Y. Savourel, J. Kosek, and R. Ishida. W3C Working Group Note, 13 February 2008. Available at http://www.w3.org/TR/xml-i18n-bp/

Acknowledgments

The editor would like to thank to the following people who have contributed to this document (ordered by first name):