Abstract
This document lists the design goals and requirements that a
specification would need to address in order to standardize various
aspects of widgets. Widgets are small client-side Web
applications for displaying and updating remote data, that are packaged in
a way to allow download and installation on a client machine, mobile
phone, or mobile Internet device. Typical examples of widgets include
clocks, CPU gauges, sticky notes, battery-life indicators, games, and
those that make use of Web services, like weather forecasters, news
readers, email 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 25 June 2008 Last Call Working Draft version of the "Widgets 1.0: Requirements" document. The Last Call period ends on 1 August 2008. This version reflects nearly 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), or may be embedded into a
Web document. In this document, the runtime environment on which a widget
is run is referred to as a widget user agent and a
running widget is referred to as an instantiated widget. Prior to
instantiation, a widget exists as a widget
resource. For more information about 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 and 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 (known
also as widget engines) and existing Web browsers.
To be clear, this specification describes the requirements
for installable/desktop-style widgets (akin to Dashboard, Opera Widgets,
and Yahoo!'s Konfabulator Widgets). This document does not address the
requirements of "web widgets", such as iGoogle Gadgets or
Windows Live Gadgets.
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 a number of related specifications:
- Widgets 1.0: Packaging and Configuration
- Widgets 1.0: Automatic Updates
- Widgets 1.0: APIs and Events
- Widgets 1.0: Digital Signatures
Note, however, that not all requirements may be addressed by
those specifications, particularly requirements marked with the key word
may.
A conforming specification is one that
addresses all the requirements (particularly those that contain the words
must
or must not
) listed in this document.
A conforming specification must attempt to address all
requirements marked as should and may unless there is a
technically valid reason not to do so. The validity of technical reasons
for not addressing should or may 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 public-appformats@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.
- 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-practices:
- A conforming specification needs to consider the development practices
currently used by widget developers and promote relevant industry
best-practices.
- 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 software,
and easy for end-users to acquire and install/run.
- Internationalization and
localization:
- A conforming specification needs to support relevant
internationalization and localization guidelines, 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 and vendors 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.
4. Requirements
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 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:
- Already a de facto standard on market-leading widget user
agents on both desktops and mobile devices.
- Able to be used in multilingual contexts.
- Suitable for mobile devices.
- Able to support digital signatures.
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-practices, internationalization
and localization, 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. 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, 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. Note also that, in some cases, Web servers
may also rely on a file extension to correctly set a widget resource's
MIME type in the HTTP headers.
R3. Internal
Abstract Structure
A conforming specification must recommend a
packaging format that supports structuring resources into collections such
as files and directories (or similar 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, current
development practice or industry best-practices.
- Rationale:
- To provide authors with a format that is easy to use in a development
process.
R4. 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 must specify
graceful error handling/recovery procedures if those resources are used
erroneously or are missing.
- Motivation:
- Ease of use, Compatibility with other standards, current development practice or industry
best-practices.
- Rationale:
- To make it more efficient for widget user agents to locate the
resources they require 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.
R5. 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 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 are already accustomed to.
- Motivation:
- Ease of use, compatibility with other standards, current development practice or industry
best-practices, 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 (e.g.
new
Image('../images/pane.png')).
R6. Multilingual Resource Names
A conforming specification should recommend a
packaging format that is suitable for multilingual contexts, giving
authors the ability to name files and directories using characters from
the Unicode character repertoire; in
such a case, a conforming specification should
recommend the UTF-8 encoding.
- Motivation:
- Internationalization and
localization, current development practice or
industry best-practices, ease of use, interoperability, longevity.
- Rationale:
- To allow authors to create files and folders using characters beyond
the ASCII character repertoire.
R7. Internationalization Guidelines
A conforming specification must provide guidelines
that explain to authors how resources need be structured for the purpose
of internationalization.
- Motivation:
- Internationalization and
localization, current development practice or
industry best-practices, ease of use, 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,
'resources/en-au/' for further localized Australian-English
content, and so on).
R8. Automatic
Localization
A conforming specification should specify a
processing model that automatically localizes content when authors follow
the internationalization guidelines.
- Motivation:
- Internationalization and
localization, current development practice or
industry best-practices, ease of use, interoperability.
- Rationale:
- To define an internationalization model, complete with error handling,
the reduces the amount of engineering work an author needs to do in order
to localize a widget.
R9. Device
Independence
A conforming specification must recommend a
packaging format that is suitable for delivery onto many devices,
particularly Web-enabled mobile devices.
- Motivation:
- Device independence, Web and
offline distribution, interoperability.
- Rationale:
- To recommend a packaging format that is interoperable with desktops
and for mobile devices, where the widget space is currently growing.
R10. Data
Compression
A conforming specification should recommend a
packaging format that supports 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, current
development practice or industry best-practices.
- 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.
R11. Digital
Signature
A conforming specification must specify a means to
digitally sign resources in a widget resource and a processing model for
verifying the authenticity and the data integrity of the widget resource.
The digital signature scheme must be compatible with
existing Private Key Infrastructures (PKI), particularly X.509 digital certificates. In addition, the
recommended digital signature format should support
certificate chaining and the ability for a packaged to be signed by
multiple authorities (i.e., multiple signatures).
- Motivation:
- Security, current
development practice or industry best-practices.
- Rationale:
- To provide a means to verify authenticity, check data integrity, and
provide a means of non-repudiation for users. Some vendors may choose to
use digital certificates as a means of quality assurance, where by only
widgets that meet a particular level of quality and security receive a
digital signature.
R12. MIME Type
A conforming specification must recommend that a
conforming widget resource be sent over HTTP with a
formally registered MIME Type. The
Working Group must formally register the MIME type
with the Internet Assigned Numbers Authority (IANA).
- Motivation:
- Compatibility with other standards, Web and offline distribution, 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.
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:
- Metadata elements that can capture metadata about a widget, including
it's title, some form of identification, and versioning information.
- Metadata elements that can capture authorship information.
- A bootstrapping mechanism that would enable a widget user agents to
automatically instantiate a widget.
- Relevant configuration parameters.
R13. Widget
Metadata
A conforming specification must specify the
structure and semantics of elements that represent metadata about the
widget. The conforming specification must describe a
model for how that metadata is to be processed by a widget user agent. 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-practices, interoperability.
- 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.
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, email, 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-practices, 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 should specify the
structure and semantics of fields that explicitly reference, or otherwise
include, a software license agreement or notice, and 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-practices, interoperability.
- Rationale:
- To provide authors with a means to legally declare how a widget and
it's 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
A conforming specification should specify a 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).
- Motivation:
- Ease of use, device
independence, current development practice or
industry best-practices.
- Rationale:
- To set up the rendering context for an instantiated widget in a way
that scales 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 it may be able to address a resource on the
Web over HTTP but only of the MIME types 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
compatible with the widget user agent. If a bootstrap has not been
declared by an author, then automated bootstrapping must occur as describe in the automated bootstrap requirement.
- Motivation:
- Ease of use, current
development practice or industry best-practices, security.
- Rationale:
- For example, bootstrapping could occur by referencing, via a relative
IRI the, the initial resource to be run by
a widget user agent (eg '
/ui/clock.svg'). Alternatively, the
bootstrap might be a Web page that when combined with the visual rendering dimensions requirement displays at
the appropriate size.
R18. Automated
Bootstrap
A conforming specification may 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, 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-practices, 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, 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 form 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 SHOULD provide 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-practices, internationalization and localization.
- Rationale:
- To provide authors with a visual means of representing widget 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, an a small
graphic of a calendar may represent a calendar widget.
R20. Configuration Parameters
A conforming specification must
specify a means to declare values of either custom or predefined
configuration parameters, which would be applied as a widget is
instantiated. A conforming specification must specify
the default values for parameters in case a parameter is missing or the
value supplied by the author is invalid.
- Motivation:
- Ease of use, current
development practice or industry best-practices.
- 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"', or in its
absence, the widget user agent will automatically set the
width to "300".
R21. Security
Declarations
A conforming specification must specify a means for
declaring that the instantiated widget will require access to resources or
services that may introduce a security risk for an end user.
- Motivation:
- Security, current
development practice or industry best-practices.
- Rationale:
- To declare the security intentions of the widget, allowing the widget
user agent to respond accordingly by adjusting its security policies and
warning the end-user. Example of security sensitive services that could
require access-control include accessing end-user's storage device, or
performing a cross-domain request.
R22. XML, Micro-Syntaxes and
Schema
A conforming specification must specify the
configuration document language using XML, as well as the
rules for processing the configuration document language and any
micro-syntaxes represented as character data or in XML attributes. A
conforming specification should specify a formal
schema for the language, as well as define any configuration defaults.
- Motivation:
- Compatibility with other standards, current development practice or industry
best-practices, ease of use, internationalization and localization,
longevity.
- Rationale:
- To have a language in a format that is relatively easy for authors to
read and write, and provides effective internationalization support.
XML is generally accepted and understood by
widget authors and parsed by all market-leading widget engines, and
XML parsers generally have reasonable support
for Unicode and other character
encodings that provide effective internationalization and localization.
R23. 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 should provide guidelines for how the configuration
document can be used separately from a widget resource.
- Motivation:
- Ease of use, Web and offline
distribution, 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 different
purposes. For example, a server may automatically extract the
configuration document from a widget resource and serve it upon request.
The independent 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 a 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:
- Manipulate the preferences and properties of an instantiated widget.
- Capture widget-specific events.
- Safely access services, resources, and other applications on a user's
device.
R24. Instantiated
Widget API
A conforming specification must specify a set of
interfaces that expose the 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, current development practice or industry
best-practices.
- 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.
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, current development practice or industry
best-practices.
- Rationale:
- Such properties could include localization information, operating
environment details, availability of network access, etc. See for example
Microsoft's Sidebar Reference.
R26. Getting and Setting
Preferences
A conforming specification must specify a set of
interfaces for dynamically getting and setting preferences that are unique
for an instantiated widget.
- Motivation:
- Ease of use, Compatibility with other standards, current development practice or industry
best-practices.
- Rationale:
- To provide a means for authors to allow end-users to dynamically
change any preferences 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 that are able to be
captured through script.
- Motivation:
- Current development practice or industry
best-practices, ease of use.
- Rationale:
- To allow authors to programmatically capture when a change has
occurred in either the instantiated widget or possibly even the widget
user agent.
R28. Network State Change
Events
A conforming specification must specify a means that
allows authors to check if the widget resource 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.
- Motivation:
- Current development practice or industry
best-practices, ease of use.
- Rationale:
- To allow authors to programmatically capture when the widget user
agent has acquired or lost a network connection.
R29. Modal Priority
A conforming specification should specify how an
instantiated widget (or any of its windows) should to categorize 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 case the
widget user agent should find a suitable and non-intrusive way to draw the
end-user's attention.
- Motivation:
- Current development practice or industry
best-practices, ease of use
- 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.
- Motivation:
- Current development practice or industry
best-practices, 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 system 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 book.
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. ECMAScript
Compatibility
A conforming specification must specify the APIs
proposed in this section in such a way that they are implementable in
ECMAScript.
- Motivation:
- Compatibility with other standards, current development practice or industry
best-practices, internationalization
and localization
- Rationale:
- To support a language that is already widely used in widget user
agents and to allow authors to use already existing ECMAScript code
libraries.
R32. XMLHttpRequest
A conforming specification must recommend that a
widget user agent implement the XMLHttpRequest object.
- Motivation:
- Current development practice or industry
best-practices, interoperability.
- Rationale:
- To allow the creation of Ajax-style
applications.
R33. Cross-Widget
Communication
A conforming specification may specify a model and
API to allow multiple instantiated widgets to securely communicate with
each other.
- Motivation:
- Current development practice or industry
best-practices.
- Rationale:
- To allow widget to communicate with each other. For example, when a
news widget receives a news item about a particular company, it could
tell a stock widget stock quotes widget to display any changes in that
company's share price.
R34. 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-practices.
- Rationale:
- To allow widget 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.
R35. 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-practices.
- Rationale:
- To allow authors to easily access metadata they declared in the
configuration document at runtime.
R36. Open Default
System Web Browser
A conforming specification SHOULD specify a means
that allows authors to open URLs in a browsing contexts outside the widget
engine.
- Motivation:
- Current development practice or industry
best-practices.
- Rationale:
- To allow author 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.
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 a language that is well-suited for creating user interfaces and
is accessible.
R37. 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 various
levels: it should provide keyboard access to
interactive graphical elements, and provide means to access the widget's
functionality through an non-graphical UI. The declared interface may also be accessible to screen readers, allowing
relevant sections of text and functionality to be accessed by non-visual
means.
- Motivation:
- Compatibility with other standards, current development practice or industry
best-practices, ease of use.
- 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 similar 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.
R38. Additional Digital
Certificates
A conforming specification may recommend that, aside
from including standard root certificates, widget user agent allow
end-users to install digital certificates from other trusted sources.
- Motivation:
- Security, current
development practice or industry best-practices, Web and offline distribution, interoperability.
- Rationale:
- To allow authors and publisher to sign widgets.
R39. End-user Declared
Proxy
A conforming specification should recommend that
widget user agents allow end-users to explicitly input a proxy server
through which all HTTP-based request are made.
- Motivation:
- Security, current
development practice or industry best-practices, interoperability.
- Rationale:
- For example, a widget user agent may be used behind a firewall or
secure proxy.
R40. Automatic
Updates
A conforming specification should specify a model to
allow widget user agents to automatically check if a new version of a
widget resource has become available online. Updating must preserve the
identity of the widget and should be conducted over a secure communication
channel.
- Motivation:
- Security, current
development practice or industry best-practices, 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.
R41. Persistent
Storage of Preferences
A conforming specification must recommend that a
widget user agent implement a means to persistently store user preferences
for each instantiated widget.
- Motivation:
- Current development practice or industry
best-practices, Web and offline distribution,
Security.
- Rationale:
- To allow widgets to be closed and re-instantiated without the end-user
having 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.
R42. Multiple Widget
Instances
A conforming specification must recommend that a
widget user agent allow multiple instances of a widget resource to be
instantiated and run concurrently as separate processes.
- Motivation:
- Current development practice or industry
best-practices, 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.
4.6 Security
This section enumerates the requirements that a conforming specification
needs to address to standardize an adequate security model for widgets.
The objective of this section is to ensure that a conforming specification
specifies a security model that:
- Makes security a fundamental part of the standardization process.
- Insures that widgets won't be able to perform harmful operations on
end-user's machines or devices.
R43. 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 authors to explicitly request permission to
use particular capabilities (see also Security
Declarations).
- Motivation:
- Current development practice or industry
best-practices, security.
- Rationale:
- To make the default state of a widget as benign as possible. For
example, the default security policy might be that a widget cannot access
the network.
R44. Runtime Security
Exceptions
A conforming specification must specify runtime
exceptions for when the API attempts to perform an action it it not
authorized to perform.
- Motivation:
- Current development practice or industry
best-practices, 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 engine to do
so.
References
Normative References
- ECMAScript
- ECMAScript
Language Specification, Third Edition. ECMA, December 1999. Available at http://www.ecma-international.org/publications/standards/Ecma-262.htm
- 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
- 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.
- Unicode
- The Unicode Standard, The Unicode Consortium, Version 5.
- 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/
- XMLHttpRequest
- The XMLHttpRequest
object. A. van Kesteren. 2006. W3C Working Draft, Available at http://www.w3.org/TR/XMLHttpRequest/
- X.509
- CCITT, Recommendation X.509: The Directory Authentication
Framework, 1988.
- IRI
- Internationalized resource
Identifiers (IRIs), M. Duerst, M. Suignard. IETF, January 2005.
RFC3987 is Available at http://www.ietf.org/rfc/rfc3987
- 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
- XML Digital Signatures
- XML-Signature Syntax and
Processing. D. Eastlake, J. Reagle, and D. Solo. W3C Recommendation,
February 2002. Available at http://www.w3.org/TR/xmldsig-core/
- Zip
- .ZIP
File Format Specification. PKWare Inc., September 2007. Available at
http://www.pkware.com/documents/casestudies/APPNOTE.TXT
- 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
- 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
- Charter
- Web Applications
Working Group Charter. D. Jackson. November 15, 2005. Available at http://www.w3.org/2008/webapps/charter/
- 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
- Google Gadgets
- Google Desktop Sidebar
Scripting API,
Google Inc., 2006. Available at http://desktop.google.com/script.html
- 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/
- Yahoo! Widgets Reference
- Yahoo!
Widget Engine Reference 3.1 Reference Manual Yahoo! Inc., April 14,
2006. Available at http://Widgets.yahoo.com/gallery/dl_item.php?item=WidgetEngineReference_3.1.1.pdf
Acknowledgments
The editor would like to thank to the following people who have
contributed to this document (ordered by first name):
- Alexander Dreiling
- Anne van Kesteren
- Arthur Barstow
- Arun Ranganathan
- Benoit Suzanne
- Bert Bos
- Bradford Lassey
- Cameron McCormack
- Cliff Schmidt
- Claudio Venezia
- Coach Wei
- Corin Edwards
- Dan Brickley
- David Pollington
- Dean Jackson
- Debra Polson
- 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
- Marc Silbey
- Mark Baker
- Mikko Pohja
- Mike(tm) Smith
- Philipp Heltewig
- Stephen Paul Weber
- Thomas Landspurg
- Yang Wong
- Zachary Fitz-Walter