-
Notifications
You must be signed in to change notification settings - Fork 20
[Publishing WG] CR Transition for pub manifest and audiobooks
- Publication Manifest
- Editor's draft: https://w3c.github.io/pub-manifest/
- Expected publication date: @@@@
- Audiobooks
- Editor's draft: https://w3c.github.io/audiobooks/
- Expected publication date: @@@@
- Publication Manifest: https://w3c.github.io/pub-manifest/#abstract
- Audiobooks: https://w3c.github.io/audiobooks/#abstract
- Publication Manifest: https://w3c.github.io/pub-manifest/#sotd
- Audiobooks: https://w3c.github.io/audiobooks/#sotd
[TODO: eg minutes, CfC in GitHub, email]
Major changes to Publication Manifest since FPWD include:
- removal of the "canonical manifest" as a json-ld representation, with focus now on the "internal representation" (emphasize that the internal representation can be in any language);
- addition/use of
language
anddirection
keywords in the JSON-LD context for expressing the global language and direction of manifest text (also for local overrides) -inLanguage
now only identifies the language(s) of the content; - clarifications to how the base URL for the manifest is obtained;
- a significant rewrite of the manifest processing algorithm to use the Infra specification language and data types;
- moved the WebIDL representation of the internal representation to an informative appendix, as it is a representation of the final data not a requirement to produce;
- addition of the
alternate
property to provide alternative media representations of resources; - addition of the required
conformsTo
property to identify the profile a manifest conforms to;
A list of all changes to Publication Manifest since FPWD is available at: https://github.com/w3c/pub-manifest/commits/master
The Publication Manifest specification partially meets the original objective of defining Web Publications. Work on Web Publications was suspended due to a lack of interest at this time from publishers, plus significant differences of opinion in terms of how they are expected to function on the web and in browsers. The group generally agreed on the manifest format for expressing information about publications, however, so driving Publication Manifest forward puts a stake in the ground for returning to Web Publications while also enabling the creation of other formats for which there is more interest (audiobooks). Defining a common manifest format also aids in future interoperability, which was another goal of Web Publications. The Publication Manifest format is also largely translatable to and from the EPUB 3 Package Document, so this provides a potential future pathway for an EPUB 4, another goal of Web Publications.
In terms of the Use Cases and Requirements for Web Publications, Publication Manifest satisfies the following manifest-based requirements:
- Req 1. Make use of OWP features - The manifest is serialized using JSON-LD and is grounded in the schema.org vocabulary, both common web technologies. The use of these technologies is also intended to simplify SEO, as the manifest metadata can be harvested by web crawlers.
- Req 2. Horizontal dependencies - The Publication Manifest specification has passed accessibility, internationalization, and privacy and security reviews.
- Req 4. Identification of publication - The manifest includes a canonical identifier field for uniquely identifying a publication. This identifier should resolve to the publication when the publication is available online.
- Req 5. Identification of resources - The manifest uses a reading order and resources list to identify all the resources that are within the bounds of a publication. A separate links field for non-essential resources is also provided.
- Req 6. Technical and descriptive metadata - The publication manifest defines both a set of descriptive properties (title, creators, publication dates, etc.) and structural metadata (reading order, resources and links) for describing publications.
- Req 7. Resource discoverability and importance - All resources of a publication are easily retrieved from a manifest. The importance of resource is differentiated based on whether they are in the reading order and resource list (necessary for rendering the publication) or in the links section (supplementary).
- Req 8. Default reading order - The reading order defines the author's preferred sequencing of content.
-
Req 9. Table of contents - The manifest allows the resource containing the table of contents to be identified through the use of the
contents
relation. A recommended format for expressing tables of contents in HTML is also provided. - Req. 11 Random access - Some features described are supported, such as identifying previews and adding labels for resources.
- Req 13. Mixed media - The manifest allows publication resources of any type to be defined. It is only at the profile level that restrictions get placed on the content (e.g., audiobooks).
-
Req 14. Synchronized media - The manifest is intended to work with output of the synchronized media community group. The addition of the
alternate
keyword was done for this purpose, for example. - Req 15. Data resources - The publication manifest does not restrict the types of resources that can be included in a publication.
-
Req 23. Publication and resource durations - The manifest includes both a general
duration
property for the overall duration of a publication, and alength
property to express the duration of each property. - Req. 28 Offlining resources - The manifest provides sufficient information about the resources of a publication to allow a user agent to bring it offline.
-
Req. 33 Discover descriptive metadata - The
rel
attribute can be used to identify resources that contain metadata records. - Req. 34 Discover changes to resources - To determine if resources have been added or removed, the reading order and resource list of two versions of a manifest can be compared.
JSON-LD 1.1 (on the @direction
keyword usage)
Practically all the work happened on GitHub, see the separate section on issues below. This included comments from outside of the Working Group.
- TAG Review
- @@@@@
- I18N Horizontal review
- A11y Horizontal review
-
Publication Manifest:
- Open issues minus editorial or postponed: https://tinyurl.com/y38cxuhv
- Same as above, but including closed issues: https://tinyurl.com/y378byy6
Note: the Publication Manifest document was originally developed within a larger framework called "Web Publications". That line of work has been paused, but the manifest part of the document was re-used as the starting basis for Publication Manifest. The issues for Web Publications listed below are only for completeness, because they (partially) contributed to the development of the Publication Manifest (the relevant open issues were transferred to the pub-manifest repository):
- Open issues minus editorial or postponed: https://tinyurl.com/yygspsdm
- Same as above, but including closed issues: https://tinyurl.com/y2ohwaqm
-
Audiobooks:
- Open issues minus editorial, deferred, or transferred to best practices: https://tinyurl.com/y67bemer
- Same as above, but including closed issues: https://tinyurl.com/yxfp7yz3
None.
Interested implementers for Publication Manifest and Audiobooks will be provided with a test suite using the Web Platform tests model. These specifications will be testing all MUST and SHOULD statements, and for Audiobooks, there will be additional manual User Agent Behaviour tests. The Working Group will provide details for implementers on how to run the tests and assistance with any issues encountered. Implementers should log issues against the Github projects for visibility.
As Publication Manifest is largely a vocabulary of terms, a comparison of the vocabulary to the structures and metadata of the EPUB 3 Package Document will also be carried out. This comparison is intended to show that there is already real-world precedent in publishing for the information included in the manifest, and a pathway for translating EPUB content (and vice versa).
Additionally, implementations will need to show that they are capable of ingesting and transforming a manifest into an internal representation using the algorithm defined in the Publication Manifest document. These transforms ensure that any authoring conveniences used in the authored manifest are normalized and sanitized, and result in a predictable data structure.
Publication Manifest and Audiobooks must have at least 2 passing tests for each feature in the specifications. For the Audiobooks User Agent Behaviours tests, all implementations should meet all of the behaviour requirements that are applicable to them.