Options for Processing a Manifest

This page outlines possible options for processing a Web Publication manifest.

Option 1 - Adopt Web App Manifest (WAM) without modification

At the most basic level, using only the existing WAM extension point for manifest members, Web Publications would have to be constrained as follows:

• No ability to link to a manifest from non-HTML resources
• No ability to load a manifest in a user agent and have the publication initiated
• No ability to link to multiple publications from a single resource, as only the first link is recognized

As a result, every Web Publication will have to have at least one HTML resource that links to the manifest.

Assuming no changes to WAM, a Web Publication would also have to embed its reading system (or initiating the reading experience would have to be triggered by some other means than a manifest). Although WAM provides an extension for new members to set up the environment for an application, the user agent is not the application.

Whether current Web Publication infoset properties that facilitate reading system behaviours belong in the manifest would also be called into question. This information would more properly belong with the application code.

Option 2 - Extend Web App Manifest (WAM)

The following list contains candidate changes to improve handling of Web Publications. Not all are critical to achieve.

• Add support for "manifest" HTTP Link header to allow linking from non-HTML resources.
• Allow support for more than the first manifest link found to allow a resource to belong to more than one Web Publication
• Allow for initiation of the Web Publication (reading enhancements) by the user agent instead of just installation.
• Allow for initiation of enhanced reading when a web publication manifest is directly loaded in the user agent.

All of these changes would have significant impacts on WAM:

• Adding Link header support would require adding precedence of the manifest link to use.
• Adding support for more than one manifest would change the installation process from an accept/dismiss prompt to having to compile up possible publications and allowing users to pick from all the available choices.
• Adding support for more than one manifest might also require using title parameter/attribute on links to provide labels, otherwise the manifests have to be retrieved and parsed.
• Allowing for reading initiation has no corollary for apps. WAM sets up the environment for an app to run in, but web publications seek to have the user agent be the application. This likely requires the ability to differentiate a manifest for a web publication from a general app, which may mean a different media type for the manifest and/or rel value.
• Initiation from a manifest doesn't make sense for apps, as there needs to be an HTML page to install. Similarly, installing without a manifest, which is possible, might be problematic for initiating a web publication (needs more investigation).

Option 3 - Define a new processing model

This option provides the greatest flexibility, but comes with the price of having to define processing and initiation in full. It would also require a new rel value and media type.

By not using WAM, the Web Publications specification could focus on initiating the reading experience, and allow the user agent to be the application that handles the content.