1. Introduction
Client-side web applications, or widgets, are typically self-contained applications for displaying and updating remote data, packaged in a way to allow a single download and installation on a client machine or mobile device. Just like authors of HTML documents, authors of widgets rely on various file formats and specifications to construct a user interface, script, package, digitally sign and deploy their applications. Figure 1 illustrates a typical architecture for widgets (please note that other architectures are also found on the web). The bottom most layer, which we refer to as the host runtime environment, is usually a piece of software that is either directly built on, or provides very similar functionality to, a web browser. Most host runtime environments will typically support HTTP, IRIs, and Unicode, as well as ECMAScript (JavaScript), CSS, the DOM, and some mechanism for rendering multimedia resources such as images and sounds.
Figure 1. The architecture of a typical widget.
To make development of widgets possible, the host runtime environment typically includes APIs that provides functionality that is currently specific to widgets, such as persistent storage and read/write access to a sand-boxed portion of an end-user's storage device. Also, because of the rise in popularity of Ajax-style development approaches, many host runtime environments now support the XMLHttpRequest object or some similar mechanism for making asynchronous data requests over HTTP. To construct the user interface of a widget, authors will typically rely on HTML or on some proprietary XML vocabulary supported by the host runtime environment.
Once an author has finished developing a widget, he or she will usually bundle all the resources that are needed to make the widget run into a single file, or package, and copy it on to a web server for distribution. Packaging is the process of bundling the widget's resources into an archive format (eg. a ZIP file) for the purpose of distribution and deployment. A package will usually include a resource that configures that widget, which is commonly referred to as a manifest, which contains instructions that declaratively instruct a host runtime environment how to install and run the packaged application. On the web server, a packaged widget will usually be associated with a particular media type that associates the package with a certain runtime environment on the end-user's computer.
In some cases, authors and/or vendors may choose to digitally sign a package as a secure means of distribution and deployment. A digitally signed package provides users with a means to verify the authenticity and the integrity of a package, as well as giving a user a degree of support for non-repudiation. User agents can verify the authenticity of a package by decrypting an encrypted hash of the content of the package (known as a digest) using the signer's public key; theoretically, only the signer's public key should be able to decrypt the digest. User agents can then check the integrity of a package by checking the hash of the package against the encrypted digest for equality. If the values do not match, then it is likely that the file is either corrupt or someone has tampered with the contents of the package after it was digitally signed. Non-repudiation refers to the fact that a digital signature makes it difficult for a signer to deny signing the contents of a package as only the signer should have access to the private key used to create the digital signature. An author or vendor may also include in the package a digital certificate, which they obtain from a certification authority, that a user can use to further verify the authenticity of the author and the package. To facilitate the process of verifying digital certificates, some host runtime environments include root certificates that host runtime environment can use to check the authenticity of digital certificates bundled with a package. (For more information on digital signatures, see the XML Digital Signatures Specification. For a general introduction to cryptography, see the book Cryptography Decrypted).
The paragraph below is at risk of being removed. Please let us know if there any good use cases for encryption.
In certain situations, an author may choose to encrypt particular resources within the package without affecting the ability for the widget to run. For instance, the author may choose to encrypt scripts or any resources they want to keep secure. It should be noted that encrypting resources is currently not a standard practice in the Widget development space, but may become a requirement as the popularity of widgets continues to grow.
1.1 Standardizing Widgets
There is currently no formally standardized way to script, package, sign and secure a widgets for distribution and deployment on the web. In the widget development space, each vendor has come up with their own solution to what is essentially the same set of problems (see Appendix). The Working Group hopes that by standardizing widgets developers will be able to author, package and deploy their widgets on a variety of platforms and devices in a standardized manner that is both easy to use and device independent.
The paragraph above currently only talks about advantages for developers. Need to discuss the advantages for vendors/implementors and for end-users.
1.1.1 Terms Related to widgets
As shown in Figure 1, a typical widget-architecture is composed of the a number of distinct parts that play multiple roles in the architecture of a widget:
- A host runtime environment:
- The software that hosts instances of a widget. Host runtime environments are either directly built on, or provide similar functionality to, a common web browser. Examples include Yahoo!'s Widget Engine, Microsoft Windows Vista Sidebar, and Apple's Dashboard.
- A media type:
- A pre-registered Media Type that
associates the package with a certain runtime environment on the end-user's
computer. For example, Opera's current '
application/x-opera-widgets'media type. - A packaging format:
- A self-contained structured resource that encapsulates the contents of a widget for the purposes of distribution and deployment. For example, Apple's Bundle format and related directory structures as specified in the Dashboard Reference.
- A manifest:
- A distinguished resource of the package that describes how the widget and
host runtime environment should be configured when the widget is instantiated.
The manifest may also define the relationship between resources in the package.
The manifest resource usually takes the form of an XML document that declares
properties and behaviors of various components of the widget and the host runtime
environment. For example, the '
config.xml'resource bundled with an Opera Widgets package. - APIs:
- A set of programming interfaces that provide functionality specific to widgets. Current Widget APIs range extensively in the level of functionality they provide an author; see for example Microsoft's API for Windows Vista in the Sidebar Reference and Apple's APIs for widgets in the Dashboard Reference.
- Resources:
- Images, text, graphical user interface markup, style sheets, executable scripts and other possible parts of the widget. Resources may be organized in directories and may have directories versions tailored for localization purposes.
1.1.2 Standardizable Aspects of a Widget
The Working Group has identified that the following aspects of widgets should be standardized:
-
The packaging format that authors
use to encapsulate and structure resources for distribution, including:
- The physical data format.
- The abstract internal structure (if any), including required resources and directories.
- The media type registration that authors could use to identify their packages as widgets when distributing over the web.
-
The manifest language that could be used
by authors to automate bootstrapping (automatically running an
instance of a widget) by declaring relationships between resources of a
package, as well as the various properties and settings of a widget and its
host runtime environment. More specifically, elements of the manifest format
that need to be standardized include:
- The structure and semantics of a vocabulary that would make up the manifest format.
- A bootstrapping mechanism that tells the host runtime environment which resource should be run first within a widget package.
- A means of addressing resources in a package.
- A means for distinguishing the manifest from other resources (ie. by using a reserved file name).
-
The APIs that authors can use to programmatically
access:
- Access preferences of each instance of a widget.
- Access runtime configuration properties and other relevant platform properties like localization information.
- Access to services particular to the device on which the widget has been instantiated (eg. camera, and the Short Message Service (SMS)).
- Access metadata values that the author declared in the manifest.
- Request that the host runtime environment check if an updated version of the widget is available for download.
- Capture events and access properties that are particular to each instance of a widget.
- The security model/context that governs the behavior of instantiated widgets.
Section 3 lists an exhaustive set of requirements that would be needed to standardize the various aspects of widgets listed above.
1.2 Conformance
Inputs that attempt to standardize Widgets as described in this document should conform to the requirements listed in Section 3.
As well as sections marked as non-normative, all diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "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 specification.
2. Design Goals
This section is non-normative.
This section describes the design goals that the Working Group will attempt to reach in standardizing the various standardizable aspects of a widget (as listed in Section 1.1.2). The requirements outlined in section 3.1 and 3.2 are directly motivated by the following design goals. The design goals are listed in alphabetical order, and the Working Group considers them all to be of equal importance.
- Compatibility with other standards
- Where possible, the standardizable aspects of a widget should maintain compatibility with, or directly make use of, other standards.
- Current development practice or industry best-practices
- The standardizable aspects of a widget should consider the development practices currently used by the widget development communities and promote other relevant industry best-practices.
- Device independence
- The standardizable aspects of a widget must support relevant device independence guidelines so that it is possible to run widgets on mobile devices.
- Ease of use
- The standardizable aspects of a widget should be easy to use and avoid unnecessary complexity: easy to edit by content authors, allow for robust interoperability, and provide effective usability, accessibility, and ease-of-use for the end-users.
- Internationalization and localization
- The standardizable aspects of a widget must support relevant internationalization and localization guidelines, as well as consider current practical internationalization solutions used by the widget development community.
- Security
- The standardizable aspects of a widget should consider the security concerns of end-users and should also consider the security and authenticity requirements of authors and vendors.
- Reduce fragmentation widget development space
- Where possible, the standardizable aspects of a widget should not further fragment the widget development space. Reducing fragmentation will give authors a common development framework making it easier to author, package, and deploy widgets across many host runtime environments. Once a specification for widgets has been created that addresses the requirements listed in this document (Section 3), it should give implementors the means to reduce fragmentation of the widget development space.
- Web delivery
- The standardizable aspects of a widget should be focused on web delivery and deployment, taking into considerations the best practices of the Mobile Web.
3. Requirements
This section list the requirements for standardizing the packaging format, manifest and application programming interfaces. These requirements are directly motivated by the Working Group's design goals (Section 2) for standardizing widgets and are based on feedback from the public, discussions with various vendors, and a survey of existing host runtime environments as detailed in the Appendix.
3.1 Packaging Format
This section lists the requirements of the packaging format to facilitate the creating, packaging, and deployment of widgets. The aim is to specify, amongst other things, a general packaging format that is suitable for both desktops and mobile devices, and able to be used in internationalized contexts.
R1. Media Type
When delivered over the web, the package format must be sent with a standardized Media Type. Media types may allow a user-agent to associate the package with an appropriate host runtime environment. The media type could potentially be used in conjunction with an auto-discovery mechanism, such as Atom Auto-Discovery, to facilitate deployment of a widget. (Inputs addressing this requirement should read "How to Register a Media Type for a W3C Specification" at the W3C and the Media Type Specification).
- Motivation:
- Compatibility with other standards, web delivery, ease of use.
R2. File Extension
The packaging format should use a consistent file extension when a widget is not intended to be distributed and deployed over HTTP. When a Media Type is not present, as is the case when a widget is instantiated locally from an end-user's storage device, the operating system may use the file extension to associate the package with the appropriate host runtime environment. However, when the widget is distributed over HTTP and a Media Type is present, a file extension may not be required but is nevertheless recommended. In some cases, web servers may also rely on a file extension to correctly set a package's media type in the HTTP headers.
- Motivation:
- Device independence, ease of use, web delivery.
R3. Free and Widely Available Packaging Format
The packaging format must be one that is royalty free, open, and widely implemented across a wide range of devices. The format used for packaging must be supported by existing user-agents, host runtime environments, and the operating systems on which authors are developing their widgets. The format should also be suitable for archiving widgets in such a way that it ensures longevity.
- Motivation:
- Compatibility with other standards, web delivery, device independence, ease of use, current development practices and industry best-practices, reduce fragmentation of widget development space, internationalization and localization.
R4. Internal Package Structure and Naming of Components/Directories
The packaging format must support structuring of resources in a manner that
authors are accustomed to, such as collections of files and directories. In
addition, it should be easy for authors (and automated systems) to add, modify,
remove and resign resources from a package. The packaging format may require
authors to put resources into specific directories (or similar containers) that
serve a specific function to the widget. For example, the packaging format may
require authors to place all contents inside a 'Resources' directory
located at the root of the package.
- Motivation:
- Ease of use, compatibility with other standards, current development practice or industry best-practices.
R5. Internal Packaging Addressing
The packaging format must specify a mechanism to address the individual
resources within the package, for instance, via relative IRIs. The packaging
format must also specify the base IRI from which resources can be addressed within
the package. For example, it may only be possible for an author to address
resources in the 'Resources' directory, but to not have the ability to
address resources at the root of the package.
- Motivation:
- Ease of use, compatibility with other standards, current development practice or industry best-practices.
R6. Internationalization and localization strategy
The packaging format should be suitable for a multilingual internationalized
context, giving authors the ability to create files and directories in any language
they choose. In addition, the packaging format must provide a single standardized
way for authors to structure localized content within the package (the localization
strategy). For example, the localization strategy would dictate that authors place
localized content into a strictly names directory structure that denotes the
language that the localized content is in (eg. 'Resources/en/' for all
english content, 'Resources/en-au/' for further localized
Australian-english content, and so on).
- Motivation:
- Internationalization and localization, current development practice or industry best-practices, ease of use.
R7. Data Compression
The packaging format should support optional data compression to make packages smaller.
- Motivation:
- Web delivery, device independence, current development practice or industry best-practices.
R8. Device Independence
The packaging format must be suitable for delivery onto many devices, particularly web-enabled mobile phones.
- Motivation:
- Device independence, web delivery.
R9. Digital Signature
The packaging format should allow authors (and other publishers) to digitally sign their widgets so that a user agent can verify the authenticity and the integrity of the package, as well as provide the user with some means for non-repudiation. Vendors may also use digital signatures as a means of quality assurance, whereby if a widget meets particular quality standards it receives a signature (together with a digital certificate).
R10. Encryption
This requirement is at risk, if you have a use case for this requirement then please let us know.
The packaging format may include one or more encrypted resources. If a resource has been encrypted, then the packaging format must include a resource that describes the encryption method used to encrypt a particular resource within the package. When encryption is used, it must only use the methods as specified by the XML Encryption Specification.
- Motivation:
- Security.
R11. Manifest resource
An instance of the packaging format must contain a manifest resource as specified in Section 3.2.
- Motivation:
- Current development practices and industry best-practices, device independence, ease of use, reduce fragmentation of widget development space.
3.2 Manifest Resource
This section describes the requirements of the manifest resource and a corresponding declarative language. The manifest language would generally allow authors to declare the metadata and other properties related to their widget, as well as provide a means to automatically instantiate the widget.
R12. Widget Metadata
The manifest language must provide a mechanism to declare metadata about the widget that is relevant to end-users, other authors, and the host runtime environment. This may include the widget's name, version, a unique identifier, creation date, update IRI, etc.
R13. Authorship Metadata
The manifest should provide a mechanism for an author to record information about the authorship of the widget. This metadata may include details like the name, email, and IRI of the author(s) that created the widget.
R14. Copyright Notice and License Metadata
The manifest should allow the author of the widget to explicitly reference, or otherwise include, a software license agreement or notice. Also, the manifest should allow authors to declare who holds the copyright for the widget.
R15. Visual Rendering Dimensions and Initial Position
When applicable, the manifest language should allow authors to declare the initial visual dimensions and initial position of a widget.
- Motivation:
- Ease of use, device independence, current development practices and industry best-practices.
R16. Application Bootstrapping
The manifest must define a bootstrapping mechanism that points to the main/root resource of the widget, such as referencing via a relative IRI the an initial resource to be run by host runtime environment. The bootstrapping mechanism must not be able to address resources outside the scope of the widget package or resources on the web.
R17. Alternative Representations
The manifest should allow authors to declare alternative representations of the widget for use as fallback content, standby indicator or in a non-running context, such as a small image icon. Because of the motivations listed below, iconic alternatives may not be limited to static images, but may also potentially include plain text, animations and/or sounds.
- Motivation:
- Ease of use, device independence, current development practices and industry best-practices, localization and internationalization.
R18. Default Preference Values
The manifest should provide authors with a means for setting the
default value of either custom or standard preferences for a widget. For example,
the author might declare that the value for the custom preference
'foo' is 'bar', and set a default preference that causes
the instantiated widget to be displayed on-top of all other elements on the
screen.
R19. Access-Control and Security
The manifest should provide a means for authors to declare their intentions to access resources outside the context of the widget. Example of sensitive resources include end-user's storage device, a service or domain on the Internet. On a mobile device security sensitive resources could include short message and voice-call services and access to the device's camera.
R20. XML
The manifest language must be defined using XML. XML is generally excepted and understood by widget development communities (see Appendix), and XML parsers generally have support for Unicode and other character encoding schemes that are required for effective internationalization and localization.
- Motivation:
- Compatibility with other standards, current development practice or industry best-practices, ease of use, internationalization and localization.
R21. Manifest independence
An author may provide a copy of the manifest separately to the package. The independent manifest may then be used, for instance, for checking information about the widget without needing to download the complete package. This may be particularly useful for mobile devices where download costs may be prohibitive.
- Motivation:
- Ease of use, web delivery, device independence.
3.3 Widget Scripting Interfaces
This section describes the requirements for a set of base scripting interfaces that an author can use to author a widget. Only host runtime environments that support scripting are required to fulfill the requirements of Section 3.3.
R22. Scripting Interfaces for Accessing an Instantiated Widgets
The host runtime environment must provide an author with a set of interfaces
that expose the properties, methods, and events of an instantiated widget. These
interfaces should be encapsulated as a self-contained object. The host runtime
environment must automatically create a unique instance of this object for every
widget instantiated by the user. See for example Apple's Widget Object
described in the Dashboard Reference and
Microsoft's System.Gadget Object described in the Sidebar Reference.
- Motivation:
- Ease of use, Compatibility with other standards, current development practice or industry best-practices.
R23. Scripting Interfaces for Accessing and Configuring Runtime Properties
The host runtime environment may provide an author with a set of interfaces that expose relevant properties and methods of the host runtime environment. Such properties may include localization information, operating environment details, availability of network access, etc. See for example Microsoft's Sidebar Reference.
- Motivation:
- Ease of use, Compatibility with other standards, current development practice or industry best-practices.
R24. Scripting Interfaces for Changing User Preferences
The host runtime environment must provide an author with a set of interfaces for dynamically getting and setting user preferences. The host runtime environment may implement a means to persistently store user preferences for each instance of an widget that is running.
- Motivation:
- Ease of use, Compatibility with other standards, current development practice or industry best-practices.
R25. Automatic updates
If it is the case that the author has declared in the manifest a IRI for where the widget can be updated, then the host runtime environment should periodically check over HTTP if the widget has been updated. The widget must be able to request that the user agent checks for an update, but widgets must not be able to change the update IRI that is declared in the manifest (see R12. Widget Metadata).
R26. Widget State Change Events
this refers to the different states or modes that a widget can be in. For example, it can be docked in a sidebar and so on...
R27. Accessing services
This requirement needs to address how services, like the camera,
SMS, and device specific services are made available to scripts. There are a number
of options here: either we either start defining a core set of APIs for things like
the camera (eg. Camera.takePicture(), Camera.activate(),
Camera.startRecording(), etc.), or we have some sort of generic mechanism
for getting at services (eg. getServiceProvider('Camera'); )
Please send us your feedback.
- Motivation:
- Compatibility with other standards, current development practice or industry best-practices, ease of use.
R28. ECMAScript Compatibility
All scripting interfaces described above (R22 to R27) must be implementable in ECMAScript.
- Motivation:
- Compatibility with other standards, current development practice or industry best-practices, internationalization and localization