Skip to content
This repository has been archived by the owner on Jun 27, 2023. It is now read-only.

Technical Summaries

Jump to bottom
Tzviya edited this page Feb 12, 2018 · 6 revisions

This group has many technical discussions. We go into a lot of detail and down technical rabbit holes. This is a place to post technical summaries for the benefit of newcomers and those who cannot attend meetings on a regular basis. If you have expertise in an area, please add a summary.

Thank you!

2018-02-12 | Where are we going? Where have we been?

A Web Publication is a discoverable and identifiable collection of resources. Information about the Web Publication is expressed in a machine-readable document called a manifest, which is what enables user agents to understand the bounds of the Web Publication and the connection between its resources.

The Infoset

We have a minimum set of requirements for the Infoset (or a better term) descriptive properties:

  • Required: address
  • Recommended: accessibility, base direction, canonical identifier, creator, language, modification date, privacy policy, publication date, title structural properties:
  • Required: default reading order, resource list
  • Recommended: Table of Contents

The Address is the "entry point" to the publication, which must resolve to an HTML document, which MUST link to the manifest.

Manifest.

This is where things get exciting. We have reached consensus around the point that User Agents need to know what is in the Publication in order to process it. At this point, we have specified very little. "A manifest is a specific serialization of a Web Publication's infoset." And, we've agreed to use JSON.

Much of the discussion over the last few months has been about this section. Web App Manifest is a JSON document that was written for the original use case of linking to the JSON document from an HTML page so that a User Agent can detect that it is an app, process the manifest, and treat it like a native app by installing it on the home screen. We are looking at using this model for publications so that a UA can detect that something is a publication, process the manifest, and then... We have to document what happens next. Our next step is to document what extensions might be available in WAM and bring those to their Working Group.

WP Lifecycle

Closely related to whether we adopt WAM or a WAM extension is the concept of the Lifecycle of the WP. This section is meant to document in broad terms how a User Agent handles a WP. Some of the detail currently in this section will fall away if we work WAM. It is possible that we will propose extensions to WAM. It is possible WAM will adopt some of our ideas. Along with the details of the algorithms is a necessary [appendix] https://w3c.github.io/wpub/#webidl) detailing a WebIDL for publications. This follows the model of WAM. Thank you to Hadrien Gardeur for his extensive work on these two sections.

Affordances

It is difficult to understand the lifecycle if we don't identify what the user agent should provide to the user. We have begun to outline this in the Affordances section and on Github. Documenting what we expect to happen with use cases and technically will guide the way to technical specifications.

##Feedback Have a comment? question? use case? concern? Contact the group on GitHub or email us at W3C Publishing Working Group public-publ-wg@w3.org

Clone this wiki locally