This specification defines digital publishing based on a fully native representation of publications within the Open Web Platform.
This first public working draft provides a preliminary outline of a Web Publication. Many details are under active consideration within the Publishing Working Group and are subject to change. The most prominent known issues have been identified in this document and links provided to comment on them.
In particular, the Working Group seeks feedback on the following issues:
For millenia now, the written word has been the primary means of encoding and sharing ideas and information. The publication as a bounded edition, made public, has been used to carry intellectual and artistic works of innumerable form: novels, plays, poetry, journals, magazines, newspapers, articles, laws, treatises, pamphlets, atlases, comics, manga, notebooks, memos, manuals, and albums of all sorts.
More recently, with the advent of the information age, print has been ceding ground to digital, and the Web has become a major forum for the public dissemination of ideas. But the Web is unbounded: information and resources are only loosely connected through hyperlinks. While this model has helped the Web thrive in many areas, it has proven problematic for traditional information publishing—users often cannot access works in their entirety, especially when offline, and have not been able to easily access, compile and download content for curation and personal use. That, in turn, has fed the continuing development of non-Web document formats to redress these problems, and made it necessary to create both Web-ready content and alternative offline renditions to ensure publications are fully available.
This specification aims to reduce these barriers and reinvigorate publishing by combining the best aspects of both models—the persistent availability and portability of bounded publications with the pervasive accessibility, addressability, and interconnectedness of the Open Web Platform.
This specification only defines requirements for the production and rendering of valid Web Publications. As much as possible, it leverages existing Open Web Platform technologies to achieve its goal—that being to allow for a measure of boundedness on the Web without changing the way that the Web itself operates.
Moreover, the specification is designed to adapt automatically to updates to Open Web Platform technologies in order to ensure that Web Publications continue to interoperate seamlessly as the Web evolves (e.g., by referencing the latest published versions instead of specific versions).
Further, this specification does not attempt to constrain the nature of a Web Publication: any type of work that can be represented on the Web constitutes a potential Web Publication.
Wherever appropriate, this document relies on terminology defined by the note on "Publishing and Linking on the Web" [[!publishing-linking]], including, in particular, user, user agent, browser, and address.
An identifier is metadata that can be used to refer to a Web Content in a persistent and unambiguous manner. URLs, URNs, DOIs, ISBNs, or PURLs are all examples of persistent identifiers frequently used in publishing.
A manifest represents structured information about a Web Publication, such as informative metadata, a list of all primary and secondary resources, and a default reading order.
For the purposes of this specification, non-empty is used to refer to an element, attribute or property whose text content or value consists of one or more characters after whitespace normalization, where whitespace normalization rules are defined per the host format.
A primary resource is one that is listed in the default reading order.
A secondary resource is one that is required for the processing or rendering of a Web Publication.
In this specification, the general term URL is used as in other W3C specifications like HTML [[!html]], and is defined by URL Standard of the WhatWG [[!url]]. In particular, such a URL allows for the usage of characters from Unicode following [[!rfc3987]]. See the note in the HTML5 document for further details.
A Web Publication is a collection of one or more primary resources, organized together through a manifest into a single logical work with a default reading order. The Web Publication is uniquely identifiable and presentable using Open Web Platform technologies.
This specification defines two conformance classes: one for Web Publications and one for user agents that process them.
A Web Publication is conformant to this specification if it meets the following criteria:
A user agent is conformant to this specification if it meets the following criteria:
The name "infoset" may change depending on feedback. Although this term has a different meaning for individuals familiar with XML, alternatives such as "properties" and "metadata" do not fully capture the nature or purpose.
A Web Publication is defined by a set of properties and features known as its information set (infoset). The infoset is both abstract and concrete. It is abstract in the sense that it represents a set of information that a user agent has to be able to compile about the Web Publication, but it also becomes concrete when the user agent creates an internal representation of the information.
The infoset does not require a specific serialization. It is primarily compiled from a Web Publication's manifest, whose serialization requirements are defined in . It is therefore possible to express the same infoset via different manifests, although a Web Publication will only have one manifest.
Although the manifest is the primary source of the infoset, some information may be obtained independent of it. For example, fallback rules for properties defined in the following subsections allow a user agent to compile information that the author has not provided in the manifest, whether as an intentional optimization or by accidental omission.
The Web Publication infoset MUST include the following information:
In addition, the infoset SHOULD include the following information:
These requirements reflect the current minimum consensus, though a number of issues remain open that could change whether an item is required or recommended. See the following sections for more information.
Ignoring issues such as location, serialization, etc. What is the minimum viable manifest? (Note: this is now specifically related to the infoset.)
Whether the minimum manifest must include any metadata, or a specific slot to handle metadata. (Note: this is now more specifically related to the infoset.)
The title provides the human-readable name of the Web Publication.
When specified in the manifest, the title MUST be non-empty.
If a user agent requires a title and one is not available in the infoset, it MAY create one. This specification does not mandate how such a title is created. The user agent might:
title element found in a primary resource in the default reading order;A user agent is not expected to produce a meaningful title [[WCAG20]] for a Web Publication when one is not specified.
(See also issue #24.) The question is whether the manifest MUST include a title or not.
The language specified in the Web Publication's infoset identifies the natural language(s) of its content.
This language is not used in the processing or rendering of the Web Publication (including the manifest), and is not a replacement for identifying the language of each resource as defined by its format. It instead allows a user agent to ability to provide supplementary enhancements, such as the ability to download a custom dictionary or the preload a language-specific text-to-speech module.
When specified, the language MUST be a tag that conforms to [[!BCP47]].
If a user agent requires the language and one is not available in the infoset, it MAY attempt to determine the language. This specification does not mandate how such a language tag is created. The user agent might:
If a language tag cannot be determined, the value "und" (undetermined) MUST be used.
The question is whether the manifest MUST include the language(s) of the content or not.
A Web Publication's canonical identifier is an identifier that designates and resolves to the preferred version of the Web Publication. The canonical identifier SHOULD be an address, but, if not, it MUST be possible to make a one-to-one mapping to an address (e.g., a DOI can be resolved to a URL via a DOI resolver).
If assigned, this canonical identifier MUST be unique to the Web Publication.
If the canonical identifier is a URL, it can be used as the target of a "canonical"
link [[!rfc6596]] (e.g., a [[html]] link element whose rel attribute has
the value canonical or a Link HTTP header field [[rfc5988]] similarly identified).
A Web Publication's address is a URL that refers to a Web Publication and enables the retrieval of a representation of the manifest of the Web Publication.
The availability of this address does not preclude the creation and use of other identifiers and/or addresses to retrieve a representation of a Web Publication in whole or part.
The infoset MUST include a list of the primary resources of the Web Publication, regardless of whether a primary resource is also used as a secondary resource in another context (e.g., an image might be embedded in an HTML document and also be rendered directly in a user agent via a link to view the raw image).
The infoset also SHOULD list secondary resources, although the list is not required to be exhaustive.
The discussion led to the question whether the manifest/infoset MUST list all Secondary resources or not. In this sense, this became a duplicate of issue #23 ended up at the same question.
The question is whether the manifest/infoset MUST list all Secondary resources or not.
The default reading order is a specific progression through the primary resources.
A user might follow alternative pathways through the content, but in the absence of such interaction the default reading order defines the expected progression from one primary resource to the next.
The default reading order MUST include at least one primary resource.
The default reading order is either specified directly in the manifest or a link is provided to an
[[!html]] nav element whose list of links are processed to create one.
The process for extracting a default reading order from a nav element are as follows:
href attribute of all
a elements;If a user agent requires a default reading order and one is not provided in the infoset, it MAY attempt to construct one. This specification does not mandate how such a default reading order is created. The user agent might:
nav element to use;Define the primary resources of a Web Publication to be the files referenced in the first
There is a consensus that a Web Publication must have a reading order (a list of primary resources) and must/should have a table of contents (the main navigation entry point).
The table of contents provides access to major sections of the Web Publication. There are no requirements on the completeness of the table of contents, except that, when specified, it MUST link to at least one primary resource.
The table of contents is either specified directly in the manifest or a link is provided to an [[!html]]
nav element containing one.
If a user agent requires a table of contents and one is not specified, it MAY construct one. This specification does not mandate how such a table of contents is created. The user agent might:
role
attribute value doc-toc);This question arises only if this mechanism is accepted: the question is whether a table of contents navigation element can refer, via links, to any resource that is not listed as a primary resource.
The issue of using the HTML nav element as a possible encoding of the table of
contents is mentioned or explicitly addressed in a number of issues listed below.
Define the primary resources of a Web Publication to be the files referenced in the first
There is a consensus that a Web Publication must have a reading order (a list of primary resources) and must/should have a table of contents (the main navigation entry point).
A manifest is a specific serialization of a Web Publication's infoset.
The requirements for a conforming Web Publication manifest are as follows:
Format of the Manifest (JSON, XML, embedded into HTML, etc.).
Should the table of contents be a separate HTML file or is the listing of primary resources in the manifest an implicit table of contents?
If we have a collection of information about a web publication as a whole ("manifest") that exists separately from most of the publication's resources, we need to find a way to associate the manifest with the other publication resources.
Placeholder for UA discovering and obtaining a manifest.
Placeholder for UA processing of manifest and creation of infoset.
Placeholder for UA initiating an enhanced reading experience.
Placeholder for UA updating manifest and/or WP content.
This section contains placholders for possible reading enhancements the UA may/should/must provide. The list is subject to addition, modification and removal as the enhancements get discussed in more detail.
Placeholder for offline reading of a publication.
Placeholder for inter-publication search.
Placeholder for paginated reading experience.