Packaging Web Applications
Requirements

Introduction

Application Packaging is the process of bundling an application and its resources into an archive format (eg. a .zip file) 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 developers 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.

Standardizing Application Packaging

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

The package:

A file that encapsulates the essential resources needed to deploy the application.

A MIME type:

A pre-registered MIME type that associates the package with a certain runtime environment on the end-user's computer. For example, Opera's application/x-opera-widgets MIME type.

A manifest:

A file inside the package that describes how the application and host runtime environment should be configured when the application is instantiated. The manifest file usually takes the form of an XML file that declares properties and behaviours of various components of the application and the host runtime environment. For example, a config.xml file.

Resources:

Files and folders that contain localized content like images, text, graphical user interface markup, style sheets and executable code.

This document calls for the standardization of:

• The way web applications are packaged, including:
  • The file format.
  • The file extension.
  • The MIME type associated with the package format.
• The manifest used to declare the various properties and settings of an application and its host runtime environment, including:
  • The file name of the manifest (or other means of containment).
  • The language elements, structure and semantics of the manifest.

Design Goals

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:

Ease of use

The packaging format and manifest language should be easy to use and should avoid unnecessary complexity.

Compatibility with other standards

Where possible, the packaging format and manifest language should maintain compatibility with other standards.

Web delivery

The packaging format and manifest language should be focused on web delivery.

Current development practice

The packaging format and manifest language should consider the development practices currently used by the web application development community.

Security

The packaging format and manifest language should consider the security concerns of end-users.

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.

Device independence

The packaging format and manifest language must support relevant device independence guidelines.

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.

Packaging Format Requirements

This section lists the requirements of the packaging format.

MIME Type

When delivered over the web, the package format should be sent with a standardized MIME type. MIME types allow user-agents to associate the package with the appropriate runtime environment.

Motivation:

Web delivery, ease of use.

File Extension

Packaging format must have a consistent file extension. When a MIME type is not present, the operating system may use the file extension to associate the package with the appropriate host runtime environment.

Motivation:

Web delivery, device independence, ease of use.

Widely Available Packaging Format

The packaging format must be one that is implemented that has been widely implement on current platforms. It must also be supported by current user-agents, runtimes, and the operating systems on which users are developing web applications.

Motivation:

Web delivery, device independence, ease of use, current development practices.

Internationalization

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

Motivation:

internationalization and localization.

Directory Structures and Long File Names

Packaging format must support directory structures and long file names.

Motivation:

ease of use, current development practice.

Data Compression

Packaging format may support data compression to make packages smaller.

Motivation:

Web delivery, device independence, current development practice.

Device Independence

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

Motivation:

web delivery, device independence.

A Manifest File

Packaging format must include a manifest file. The file name given to a manifest file must be standardized.

Motivation:

current development practice, web delivery, device independence, ease of use.

Manifest File and Manifest Language Requirements

This section describes the requirements of the manifest.

Application Metadata

The manifest must declare metadata about the application that is relavant to end-users, other developers, and the host runtime environment. This may include the application's name, version, a unique identifier, copyright notice, publication date, etc.

Motivation:

current development practices.

Author Metadata

The manifest should allow a user to record information about the authorship of the application. This may include details like the name, email, and URL of the people that created the application.

Motivation:

current development practices.

Main View

The manifest should reference a file that host runtime environment can use as the initial user interface.

Motivation:

ease of use, current development practice.

Iconic Representations

The manifest should allow developers to reference alternative representations of the web application. Alternatives could include a set of images, animations, or sounds that represent the application in different states.

Motivation:

ease of use, device independence, current development practices, localization and internationalization.

Property Declaration Elements

The manifest must provide a means for developers to declare properties.

Motivation:

ease of use, current development practice.

Access-Control Strategy

The manifest may provide a means for developers to declare their intentions to access networked resources.

Motivation:

security, current development practice.

Localization Strategy

The manifest may provide a means for developers to declare how localized content is stored.

Motivation:

internationalization and localization.

Unicode and Other Character Sets

The manifest must provide support for Unicode and other character sets.

Motivation:

internationalization and localization.

XML Syntax

The manifest must make use of XML syntax.

Motivation:

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