Abstract
Widgets are small client-side Web applications for displaying
and updating remote data, that are packaged in a way to allow a single
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.
This document lists the design goals and requirements that specification
would need to address in order to standardize various aspects of widgets.
Status of this Document
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/.
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. 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. It is expected that this document will progress along the
W3C's Recommendation
Track Process.
This document is produced by the Web Application Formats
(WAF) 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 WAF Working Group's
public mailing list public-appformats@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
This document lists the design goals and requirements that
specifications need to address in order to standardize how widgets are
authored, 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.
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.
To be clear, this specification describes the requirements
for desktop style widgets (akin to Dashboard, Opera Widgets, and Yahoo!
Widgets). This document does not address the requirements of "web
widgets", such as iGoogle Gadgets or Windows Live Gadgets.
As shown 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.
The key words "MUST", "MUST NOT", "REQUIRED",
"SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
the normative parts of this document are to be interpreted as described in
RFC2119. For readability, these words
do not appear in all uppercase letters in this document.
This specification only applies to one class of product: W3C Technical
Reports. Inputs that attempt to standardize widgets as described in this
document must conform to the requirements
listed in this document.
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
should and may requirements 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 the widget development communities 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 (eg. 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.
- Rational:
- 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.
- Rational:
- 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.
- Rational:
- 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 specify mandatory
files or directories (or similar logical containers) that serve a specific
function in the widget resource, as well as error handling procedures if
those names are used erroneously or are missing.
- Motivation:
- Ease of use, Compatibility with other standards, current development practice or industry
best-practices.
- Rational:
- 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
a scheme to address the individual resources within the widget resource in
a manner that authors are accustomed to.
- Motivation:
- Ease of use, Compatibility with other standards, current development practice or industry
best-practices.
- Rational:
- 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 (eg.
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.
- Rational:
- 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.
- Rational:
- 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 (eg.
'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.
- Rational:
- 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.
- Rational:
- 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.
- Rational:
- To make a widget resource smaller for delivery over HTTP, where the cost of download data are
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.
- Motivation:
- Security, current
development practice or industry best-practices.
- Rational:
- 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 registeredMIME 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.
- Rational:
- 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.
- Rational:
- 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.
- Rational:
- 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.
- Rational:
- 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 other to reuse any source code.
R16. Visual Rendering
Dimensions and Initial Position
A conforming specification should specify a means
for an author to declare the initial visual dimensions and initial
position for an instantiated widget in a way that is device independent
(eg. via CSS pixels).
- Motivation:
- Ease of use, device
independence, current development practice or
industry best-practices.
- Rational:
- 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 that 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.
- Rational:
- 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 and Initial Position requirement displays at the
appropriate size and screen position.
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.
- Rational:
- 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, but should also support resources within
the scope of the widget resource.
- Motivation:
- Ease of use, device
independence, current development practice or
industry best-practices, internationalization and localization.
- Rational:
- 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.
- Rational:
- 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.
- Rational:
- 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 syntax, 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.
- Rational:
- 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 are 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 may 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.
- Rational:
- 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 for end-users.
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.
- Rational:
- 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.
- Rational:
- 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 specific for an
instantiated widget.
- Motivation:
- Ease of use, Compatibility with other standards, current development practice or industry
best-practices.
- Rational:
- To provide a means for authors to allow end-users to dynamically
change any preferences they have 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.
- Rational:
- To allow authors to programmatically capture when a change has
occurred in either the instantiated widget or possibly even the widget
user agent.
R28. 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
- Rational:
- 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.
R29. Accessing Resources,
Services, and Applications
A conforming specification may specify APIs to
access device-specific resources, services, and applications.
- Motivation:
- Compatibility with other standards, current development practice or industry
best-practices, ease of use.
- Rational:
- Examples of device-specific services and resources that could be made
available through script include cameras, SMS, and the address book.
However, this requirement is beyond the scope of the working group
charter. 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.
R30. 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
- Rational:
- To support a lanaguage that is already widely used in widget user
agents and to allow authors to use already existing ECMAScript code
libraries.
R31. XMLHttpRequest
A conforming specification must recommend that a
widget user agent implement the XMLHttpRequest object.
- Motivation:
- Current development practice or industry
best-practices, interoperability.
- Rational:
- 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.
- Motivation:
- Current development practice or industry
best-practices.
- Rational:
- To allow widget to communicate with each other.
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.
R33. 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.
- Rational:
- 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.
R34. Additional Digital
Certificates
A conforming specification may recommend that, aside
from including standard root certificates, widget user agent allow the
installation of digital certificates from other trusted sources.
- Motivation:
- Security, current
development practice or industry best-practices, Web and offline distribution, interoperability.
- Rational:
- To allow authors and publisher to sign widgets.
R35. 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.
- Rational:
- For example, a widget user agent may be used behind a firewall or
secure proxy.
R36. 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.
- Rational:
- 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.
R37. 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.
- Rational:
- 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 widgets is re-instantiated.
R38. 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.
- Rational:
- 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.
R39. 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.
- Rational:
- 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.
R40. 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.
- Rational:
- 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.
- Widgets 1.0: Packaging and Configuration
- Widget 1.0. M. Caceres.
W3C Working Draft. 13 October 2007. Available at http://www.w3.org/TR/2007/WD-widgets-20071013/
- 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
Application Formarts Working Group Charter. D. Jackson. November 15,
2005. Available at http://www.w3.org/2006/appformats/admin/charter.html
- CSS
- Cascading Style Sheets, level 2,
revision 1, B. Bos, T. Çelik, I. Hickson, and H. Wium Lie. 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
- Andrew Brown
- 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
- Jose Manuel Cantera Fonseca
- Kevin Lawver
- Krzysztof Maczyński
- Lachlan Hunt
- Marc Silbey
- Mark Baker
- Mikko Pohja
- Philipp Heltewig
- Stephen Paul Weber
- Thomas Landspurg
- Yang Wong
- Zachary Fitz-Walter