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 packaging 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 21 August 2006 First Public Working Draft of the Web Applications Packaging Formats 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.
The WG intends to publish one or more additional Working Drafts of this document. However, the final maturity level of this document is expected to be a Working Group Note.
This document is purely informational and contains no conformance statements or testable assertions.
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 a Web Application Packaging Format.
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.
Application Packaging is the process of bundling an application and its resources into an archive format (eg. a .zip
file [ZIP]) for the purpose of distribution and deployment.
A package bundle usually includes a manifest, which is a set of instructions that tell 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 such as those distributed by Apple, Opera, Yahoo! and Microsoft.
Currently, there is no standardized way to package an application for distribution and deployment on the web. Each vendor has come up with their own solution to what is essentially the same problem (see Appendix). The working group hopes that by standardising application packaging authors will be able to distribute and deploy their applications across a variety of platforms in a standardized manner that is both easy to use and device independent.
When it comes to web distribution, a typical application package consists of four parts:
application/x-opera-widgets
media type.config.xml
file.This document calls for the standardization of:
This section describes the design goals that the working group will follow in standardising the packaging file format and the manifest file and language used by 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 packaging format and manifest language. These requirements are directly motivated by the design goals.
This section lists the requirements of the packaging format.
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 packaging format should use a consistent file extension when the application is not intended to be instantiated 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 web applications.
Packaging format must already be proven for global delivery and use.
Packaging format must support directory structures and long file names.
Packaging format should support data compression to make packages smaller.
Packaging format must be suitable for delivery onto many devices, particularly mobile phones that are web-enabled.
The spec should define a basic and extensible set of application metadata and how to associate this data with the application package.
This section describes the requirements of the manifest.
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 may include details like the name, email, and URL 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 file.
The manifest should allow authors to declare alternative iconic representations of the application, 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 a means for authors to configure the properties of their application.
Should this document also include as a requirement 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.
The manifest must be written in XML [XML]. XML provides support for Unicode [Unicode] and other internationalized character sets.
This table lists the packaging formats currently used in industry to bundle client-side web applications.
Application | Container Format | Extension | media type |
---|---|---|---|
Application | Container Format | Extension | media type |
Yahoo! Widgets | Zip, proprietary flat-file [Yahoo! Widgets Reference] | .widget | application/vnd.yahoo.widget |
Microsoft Sidebar Gadgets | Zip, Cab, folder | .gadget | application/x-windows-gadget |
Google Desktop Gadgets | Zip | .gg | app/gg |
Opera Widgets | Zip | .wdgt | application/x-opera-widgets |
Apple Dashboard Widgets | Zip,bundle | .wdgt or .zip | application/x-macbinary |
AOL Modules | Zip | .html |
text/html |
This table details the manifest files and formats that are used in industry when packaging client-side web applications.
Application | Manifest Format | Manifest Extension | UI Markup | Host Runtime | Localization Strategy | Security Model |
---|---|---|---|---|---|---|
Application | Manifest Format | Manifest Extension | UI Markup | Runtime | Localization strategy | Security Model |
Yahoo! Widgets | Proprietary XML [Yahoo! Widgets Reference] | *.kon | Proprietary XML [Yahoo! Widgets Reference] | Yahoo! Widget Engine | Directory-based +JS | Manifest |
Microsoft Sidebar Gadgets | Proprietary XML [Microsoft Gadgets] | gadget.xml | HTML+CSS | Internet Explorer | Directory-based + JS | Browser |
Google Desktop Gadgets | Proprietary XML [Google Gadgets] | gadget.gmanifest | Proprietary XML [Google Gadgets] | Google Desktop sidebar |
Directory-based + JS | Internal? |
Opera Widgets | Proprietary XML [Opera Config] | config.xml | XHTML+CSS | Opera | undefined | Manifest+Browser |
Apple Dashboard Widgets | Proprietary XML [Apple pList] | info.plist | XHTML+CSS | Safari/WebKit+Quartz | Directory-based + JS | Access Keys |
AOL Modules | Microformat [AOL ModuleT] | index.html | XHTML+CSS | Any capable UA | ? | Browser |
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.