W3C

Web Applications Packaging Format Requirements

W3C Working Draft 21 August 2006

This version:
http://www.w3.org/TR/2006/WD-WAPF-REQ-20060821/
Latest version:
http://www.w3.org/TR/WAPF-REQ
Editor:
Marcos Caceres, QUT

Abstract

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".

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/.

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.

Table of Contents

1. Introduction

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.

1.1 Standardizing Application Packaging

When it comes to web distribution, a typical application package consists of four parts:

The package:
A fileresource that encapsulates or references the essential resources needed to deployparts of the application.
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 manifest:
A filedistinguished part insideof the package that describes how the application and host runtime environment should be configured when the application is instantiated. The manifest fileresource usually takes the form of an XML filedocument that declares properties and behaviours of various components of the application and the host runtime environment. For example, a config.xml file.
Components:
Files and folders that contain localized content like images, text, graphical user interface markup, style sheets and executable code.Images, text, graphical user interface markup, style sheets, executable code and other possible parts of the application. Components may be organized in folders or otherwise structured and may have versions tailored to localization purposes.

This document calls for the standardization of:

2. Design Goals

This section describes the design goals that the working group will follow in standardising the packaging fileresource format and the manifest fileresource and language used by web applications. The requirements outlined in section 3.1 and 3.2 are directly derived from the following design goals:

1. Ease of use
The packaging format and manifest language 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 of web applications.
2. Compatibility with other standards and industry best-practices
Where possible, the packaging format and manifest language should maintain compatibility with other standards and best practices in industry.
3. Web delivery
The packaging format and manifest language should be focused on web delivery and deployment.
4. Current development practice
The packaging format and manifest language should consider the development practices currently used by the web application development community.
5. Security
The packaging format and manifest language should consider the security concerns of end-users and should also consider the security requirements of authors.
6. Internationalization and localization
The packaging format and manifest language must support relevant internationalization and localization guidelines, as well as consider current solutions used by the web application development community.
7. Device independence
The packaging format and manifest language must support relevant device independence guidelines.
8. Reduce fragmentation of web application development space
The packaging format and manifest language must not further fragment the web application development space, particularly on the client-side. Reducing fragmentation will give authors a common implementation framework making it easier to develop applications.

3. Requirements

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.

3.1 Packaging Format Requirements

This section lists the requirements of the packaging format.

R1. Media Type

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.

Motivation:
Compatibility with other standards and industry best-practices, Web delivery, ease of use.

R2. File Extension

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.

Motivation:
Device independence, ease of use.

R3. Free and Widely Available Packaging Format

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.

Motivation:
Compatibility with other standards and industry best-practices, Web delivery, device independence, ease of use, current development practices, reduce fragmentation of web application development space, internationalization and localization.

R4. Internationalization

Packaging format must already be proven for global delivery and use.

Motivation:
internationalization and localization.

R5. Directory Structures and Long File NamesInternal package structure and naming of components

Packaging format must support directory structures and long file names.Packaging format must support adressability of declared components. Relative IRIs of components MUST be known from the package itself and components MUST be able to reference each other with it. Absolute IRI of a component MUST be constructible given its relative IRI and absolute IRI of the package using fragment identifiers. A syntax for embedding fragment identifiers pertaining to components MUST be specified.

Motivation:
ease of use, Compatibility with other standards and industry best-practices, current development practice.

R6. Data Compression

Packaging format should support optional data compression to make packages smaller.

Motivation:
Ease of use, Web delivery, device independence, current development practice.

R7. Device Independence

Packaging format must be suitable for delivery onto many devices, particularly mobile phones that are web-enabled.

Motivation:
web delivery, device independence.

R8. Web Application Manifest

The spec should define a basic and extensible set of application metadata and how to associate this data with the application package.

Motivation:
current development practice, device independence, ease of use, reduce fragmentation of web application development space.

3.2 Manifest Filedocument and Manifest Language Requirements

This section describes the requirements of the manifest.

R9. Application Metadata

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.

Motivation:
Current development practices.

R10. Author Metadata

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.

Motivation:
Current development practices.

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.

Motivation:
Current development practices.

R12. Visual Rendering Dimensions and Initial Position

When applicable, the manifest language should allow authors to declare the initial visual dimensions and initial position of an application.

Motivation:
Ease of use, device independence, current development practices.

R13. Application Bootstrapping

The manifest must define a mechanism to start the application, such as referencing an initial application file.

Motivation:
Ease of use, current development practice.

R14. Alternative Iconic Representations

The manifest should allow authors to declare alternative iconic 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.

Motivation:
Ease of use, device independence, current development practices, localization and internationalization.

R15. Configuration

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?

Motivation:
ease of use, current development practice.

R16. Access-Control and Security

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.

Motivation:
security, current development practice.

R17. Localization Strategy

The manifest may provide a means for authors to declare how localized content is organized.

Motivation:
internationalization and localization.

R18. XML Syntax

The manifest must be written in XML [XML]. XML provides support for Unicode [Unicode] and other internationalized character sets.

Motivation:
support for other standards, current development practice, ease of use, internationalization and localization.

Appendix

Packaging Formats

This table lists the packaging formats currently used in industry to bundle client-side web applications.

Packaging formats used by current client-side application runtimes
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

Manifest files and formats

This table details the manifest files and formats that are used in industry when packaging client-side web applications.

The details of manifest files used in conjunction with current packaging formats
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

References

[AOL ModuleT]
"AOL ModuleT: A Module Transport Microformat Profile", Shawn Carnell, Joe Dzikiewiczl, Kevin Lawver, and Paul Maneesilasan, AOL LLC, 2006. Available at http://developer.iamalpha.com/profile/
[Apple Dashboard]
"Dashboard Programming Topics", Apple Computer Inc, 4 April 2006. Available at: http://developer.apple.com/documentation/AppleApplications/Conceptual/Dashboard_ProgTopics/
[Apple pList]
"Introduction to Property List Programming Topics for Core Foundation", Apple Computer Inc, 7 February 2006. Available at http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFPropertyLists/index.html
[Google Gadgets]
"Google Desktop Sidebar Scripting API", Google Inc., 2006. Available at http://desktop.google.com/script.html
[Microsoft Gadgets]
"Gadget Development Overview", Brian Teutsch, Microsoft Inc., May 22, 2006. Available at http://microsoftgadgets.com/Sidebar/DevelopmentOverview.aspx
[Opera Config]
"Opera Widgets: Widget information file syntax", Arve Bersvendsen (Editor), Opera Software, 2006. Available at http://oxine.opera.com/widgets/documentation/widget-configuration.html
[RFC-2046]
"RFC2046: 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.
[RFC-2616]
"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
[Unicode]
The Unicode Consortium. The Unicode Standard, Version 3.2, defined by: The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27) and the Unicode Standard Annex #28: Unicode 3.2(http://www.unicode.org/reports/tr28)
[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
[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
[Zip]
".ZIP File Format Specification" PKWare Inc., January 2006. Available at http://www.pkware.com/business_and_developers/developer/popups/appnote.txt

Acknowledgements

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.