Publishing WG Telco, 2017-10-16: Lifecycle, Locators

Author(s) and publish date

By:
Published:

See minutes online for a more detailed record of the discussions.

Lifecycle

Matt Garrish began working on a section for the “lifecycle” of a WP. In line with recent discussion, the (accepted) Pull Request is reduced to a series of general principles (e.g., it is not the goal to fork the Web, a Web Publication shouldn’t have to be it’s own app…) and technical issues and requirements on what should be achieved (e.g., continuous search). By listing this in the (upcoming) FPWD we would require contributions from the Browser world on how this fits, e.g., the view of browser contexts.

Locators

There is a Pull Request and an accompanying Locator document to review.

Originally, the locator document’s content was part of the pull request to the main WPUB spec, but it turned out to be way too long. Hence the proposal to fork that part into the separate document. The pull request itself for the WPUB spec only contains some general principles and delegates the main content to the other document.

The Locator document is also a spin-off, it is a slightly updated version of the Selectors and States WG Note, published by the Web Annotation Working Group. What it defines is a JSON based structure to “describe” possible selections in documents (within a WP or not), accommodating several different means of identifications (using a traditional fragment ID, using text matching, defining ranges, combining various selections into one). The use cases for this approach should fit the use cases for EPUBCFI.

The document relies on the Web Annotation model, but has two extensions to it

  • There are (at the moment, two) additional selector structures defined that are WPUB specific; the details are currently under discussion
  • It also defines a fragment ID that serializes the JSON structures; it is a question whether this is really necessary (knowing the administrative issues to register a fragment ID, as well as the complexity of the fragments themselves).

These details will have to be discussed in the future and the question whether a fragment ID format is necessary in the first place will also be decided. Several EPUBCFI use cases have been discussed at the meeting. The pull request has been merged.

Related RSS feed

Comments (0)

Comments for this post are closed.