Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document specifies the design goals and requirements for a specification that would give developers a standardized way to author, package, and deploy client-side Web applications.
The type of Web applications that are addressed by this document are usually small client-side applications for displaying and updating remote data, packaged in a way to allow a single download and installation on a client machine. The application may execute outside of the typical Web browser interface. Examples include clocks, stock tickers, news casters, games and weather forecasters. Some existing industry solutions go by the names "widgets", "gadgets" or "modules".
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/.
This is the 9 November 2006 2nd Public Working Draft of the Client-Side Web Applications (Widgets) Requirements. This document is produced 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.
This document former title was "Web Applications Packaging Format Requirements". It has been renamed to more clearly reflect the contents of the document.
This document is purely informational and contains no testable assertions. However, inputs standardizing Client-Side Web Applications (Widgets) should attempt to conform, to the best of their ability, to the Requirements listed in Section 3.
The WAF Working Group provides these requirements for general information and as of the date of its publication makes no commitment that any of the requirements will be satisfied in a follow-on specification for Client-Side Web Applications (Widgets).
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.
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.
Client-side Web applications are typically small self-contained applications for displaying and updating remote data, packaged in a way to allow a single download and installation on a client machine. Just like authors of HTML documents, authors of client-side Web Applications rely on various file formats and specifications to structure, code, package, and deploy their applications. Figure 1 illustrates a typical architecture for client-side Web applications (please note that other architectures are also found on the Web). The bottom most layer, which we call 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, URIs, and Unicode, as well as ECMAScript (JavaScript), CSS, the DOM, and some mechanism for rendering multimedia resources such as images and sounds. They will also include an API for that provides functionality that is currently specific to client-side Web Applications, such as persistent storage and read/write access to a sandboxed 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 create the user interfaces of a client-side Web application, authors will typically rely on either HTML or on some proprietary XML vocabulary supported by the host runtime environment.
Figure 1. The anotomy of a typical client-side Web Application.
Once an author has finished developing a client-side Web Applications, he or she
will package the application and put in on a web server for deployment.
Application Packaging is the process of bundling the application and its
resources into an archive format (eg. a .zip file [ZIP]) for the purpose of distribution and deployment. A package
bundle will usually include a manifest, which is a set of instructions
that declaratively instruct a host runtime environment how to install and run the
packaged application. Application packaging is used on both the server-side, as is
the case with Sun's JEE
.war files and .ear files and Microsoft's .NET
.cab files, and on the client-side, as is the case with widgets or
gadgets such as those distributed by Apple, Opera, Yahoo! and Microsoft. On the web
server, a packaged client-side Web Application will usually be associated with a
particular media type that associates the package with a certain runtime
environment on the end-user's computer.
There is currently no standardized way to package a client-side Web applications for distribution and deployment on the Web. In the client-side Web application development space, each vendor has come up with their own solution to what is essentially the same problem (see Appendix). The Working Group hopes that by standardizing client-side Web applications developers will be able to author, package and deploy their applications on a variety of platforms in a standardized manner that is both easy to use and device independent.
As shown in Figure 1, a typical client-side Web application is composed of the following distinct parts:
application/x-opera-widgets' media type.config.xml' resource bundled with an
Opera Widget package [Opera Config].This document outlines the requirements that would be needed to standardise the following:
This section describes the design goals that the Working Group will follow in standardizing the packaging format, the manifest resource and language, and the scripting interfaces used by client-side Web applications. The requirements outlined in section 3.1 and 3.2 are directly derived from the following design goals:
This section describes the requirements that the Working Group feels are essential to having an effective media type, packaging format, manifest language and programing interfaces. These requirements are directly motivated by the Design Goals of this document.
This section lists the requirements of the packaging format to facilitate the creating, packaging, and deployment of client-side Web applications.
When delivered over the Web, the package format must be sent with a standardized media type [RFC-2046]. Media types may allow a user-agent to associate the package with an appropriate runtime environment. The media type could potentially be used in conjunction with an auto-discovery mechanism, such as Atom Auto-discovery [Atom Autodiscovery], to facilitate deployment of an application.
The packaging format should use a consistent file extension when the application is not intended to be distributed and deployed over HTTP [RFC-2616]. When a media type is not present, as is the case when an application 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 runtime environment. However, when the application 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 an application's media type in the HTTP headers.
The packaging format must be one that is royalty free, open, and widely implemented on current delivery platforms. It must also be supported by current user-agents, runtimes, and the operating systems for which authors are developing client-side Web applications.
The packaging format must already be proven for global delivery and use.
The packaging format should support structuring of resources in a manner that authors are accustomed to, such as files and directories. The packaging format may specify a mechanism to address the individual components within the package, for instance, via IRIs [RFC3987].
The packaging format should support optional data compression to make packages smaller.
The packaging format must be suitable for delivery onto many devices, particularly mobile phones that are Web-enabled.
The packaging format should support a mechanism to allow authors to digitally sign their packaged applications. The packaging format may also support some other mechanism to verify that the resources held within the package have not been tempered after they have been packaged.
A package may include a particular resource (a manifest) that describes various aspects of the client-side Web application, including metadata relating to the authors and the relationship and function of resources in the package. The requirements for a manifest format and manifest language are discussed in Section 3.2.
This section describes the requirements of the manifest format and language. The manifest language would generally allow users to describe the metadata and other properties related to their application, as well as potentially provide a means to automatically start the application.
The manifest language must provide a mechanism to declare metadata about the application that is relevant to end-users, other authors, and the host runtime environment. This may include the application's name, version, a unique identifier, publication date, etc.
The manifest should provide a mechanism for an author to record information about the authorship of the application. This metadata may include details like the name, email, and IRI of the authors that created the application.
The manifest should allow the copyright holder of the application to explicitly reference, or include, a software license agreement or notice. Also, the manifest should allow authors to declare who holds the copyright for the application.
When applicable, the manifest language should allow authors to declare the initial visual dimensions and initial position of an application.
The manifest must define a mechanism to start the application, such as referencing an initial application resource.
The manifest should allow authors to declare alternative representations of the application 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.
The manifest should provide authors with a means for configuring the properties of their application. The manifest may also provide authors with a means to configure the properties of the host runtime environment.
The manifest may provide a means for authors to declare their intentions to access security sensitive resources, such as an end-user's storage device or a service on the Internet.
The manifest may provide a means for authors to declare how localized content is organized within the package.
The manifest must be defined using the XML syntax [XML]. XML is generally excepted and understood by Web authors and provides support for Unicode [Unicode] and other internationalized character sets that are vital for internationalization and localization.
This section describes the requirements for a set of base scripting interfaces that an author can use to author a client-side Web application. Only runtime environments that support scripting are required to fulfill the requirements of Section 3.3.
The runtime must provide an author with a set of interfaces that expose the
properties, methods, and events of an instantiated client-side Web application. These
interfaces should be encapsulated as a self-contained object. The runtime must
automatically create a unique instance of this object for every client-side
application instantiated by the user. See for example Apple's Widget
Object [Dashboard] and Microsoft's
System.Gadget Object [Sidebar API].
The runtime may provide an author with a set of interfaces that expose relevant properties and methods of the runtime environment. Such properties may include localization information, operating environment details, availability of network access, etc. See, for example, Microsoft's Windows Sidebar Reference [Sidebar API].
The runtime must provide an author with a set of interfaces for dynamically getting and setting user preferences. The runtime may implement a means to persitantly store user preferences for each instance of an application that is running.
All scripting interfaces described above (R19 to R21) must be implementable in ECMAScript [ECMAScript].
This section includes a survey of popular runtime environments for client-side Web Applications. The information in this Appendix is only as current as the date of publication of this document and there is no guarantee that it is accurate. Please double check the information found here through the References. The aim of this section is to identify for each vendor:
In addition to the Design Goals, researching the questions listed above has provided the Working Group with the means to define the Requirements for authoring, packaging, and deploying client-side Web applications.
This table lists the packaging formats currently used by various vendors to bundle client-side Web applications.
| Runtime | Container Format | File Extension | Media Type |
|---|---|---|---|
| Runtime | Container Format | File Extension | Media Type |
| Yahoo! Widgets Engine | Zip, folder, proprietary flat-file | .widget | application/vnd.yahoo.widget |
| Microsoft Sidebar | Zip, Cab, folder | .gadget | application/x-windows-gadget |
| Google Desktop | Zip | .gg | app/gg |
| Opera Browse | Zip | .wdgt | application/x-opera-widgets |
| Apple Dashboard | Zip, Apple bundle | .wdgt or .zip | application/x-macbinary |
| AOL Modules | Zip | .html | text/html |
This table lists the formats of the manifest files various vendors are using as part of packaging client-side Web applications. It also identifies what markup language authors are required to use when declaring the user interface of client side Web applications.
| Runtime | Manifest Format | Manifest File | UI Markup |
|---|---|---|---|
| Runtime | Manifest Format | Manifest File | UI Markup |
| Yahoo! Widgets Engine | Proprietary XML [Yahoo! Widgets Reference] | *.kon | Proprietary XML [Yahoo! Widgets Reference] |
| Microsoft Sidebar | Proprietary XML [Microsoft Gadgets] | gadget.xml | HTML + CSS |
| Google Desktop | Proprietary XML [Google Gadgets] | gadget.gmanifest | Proprietary XML [Google Gadgets] |
| Opera Widgets | Proprietary XML [Opera Config] | config.xml | HTML + CSS |
| Apple Dashboard | Proprietary XML [Apple pList] | Info.plist | HTML + CSS |
| AOL Modules (any capable UA) | Microformat [AOL ModuleT] | index.html | HTML + CSS |
This table lists both the localization strategies and describes the security models of various
| Runtime | Localization Strategy | Security Model |
|---|---|---|
| Yahoo! Widgets Engine | Directory-based +JS | Manifest |
| Microsoft Sidebar | Directory-based + JS | Browser based |
| Google Desktop | Directory-based + JS | Internal |
| Opera Widgets | None, recreate Widget or use JS | Manifest + Browser |
| Apple Dashboard | Directory-based + JS | Access Keys |
| AOL Modules (any capable UA) | None, recreate Widget or use JS | Browser based |
| Runtime | Localization strategy | Security Model |
This document was produced with the participation of the following Web Application Formats Working Group participants:
The Web Application Formats Working Group has benefited in its work from the participation and contributions of a number of people not currently members of the Working Group, including in particular those named below. Affiliations given are those current at the time of their work with the WG.