Copyright © 2018 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
This specification defines a collection of information that describes the structure of Web Publications so that user agents can provide user experiences well-suited to reading publications, such as sequential navigation and offline reading. This information includes the default reading order, a list of resources, and publication-wide metadata.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
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:
This document was published by the Publishing Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation. Comments regarding this document are welcome. Please send them to public-publ-wg@w3.org (subscribe, archives).
Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 March 2017 W3C Process Document.
This section is non-normative.
The Web is a lonely place. It is unbounded: resources live out their lives on remote servers scattered across the globe, only reachable by addresses sometimes known to only a few people. But life on the Web is not all doom and gloom. Through the power of Web pages, these resources can be brought together to create amazing experiences.
Web sites add another layer of relationship—this time between pages—but the relationship is a tenuous one that typically depends on hyperlinks to add cohesion. Without a user that understands how to follow the connections, a Web site is still no more than a loose coupling of information.
The preceding is not a critique of the Web, but meant to highlight that the modern Web is very much an active, event-driven experience. Users follow the necessary paths to obtain the information they need.
The traditional publishing model, sometimes called the print model, differs from the Web model in that the publisher packages all the information together and thereby establishes the common pathway through it. The user can passively follow the content page-by-page, or actively find other pathways via a table of contents or index. It is a model that has worked to bind information in a cohesive way for millennia, and continues to be an important model alongside the Web. The publication as a bounded edition, made public, is 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.
Attempts to reproduce this model on the Web, however, have had to work around its loose coupling of information: sometimes publications are compressed into a single page; sometimes they are broken across multiple pages and hyperlinked together. These models both have flaws, however: single-page publications are often so large they render slowly, especially on low-power devices; multi-page publications cannot be easily taken offline because their common thread cannot be established.
As a result, users have had trouble accessing, compiling and downloading Web content for curation and personal use. That, in turn, has fed the continuing development of non-Web digital formats to redress these problems, and made it necessary to create both Web-ready content and alternative renditions for offline use.
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. To do so, it adds an unobtrusive definition of interrelation to the Web model: the Web Publication.
This section is non-normative.
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 manifest includes metadata that describe the Web Publication, as a publication has an identity and nature beyond its constituent resources. The manifest also provides a list of all the resources that belong to the Web Publication and a default reading order, which is how it connects resources into a single contiguous work.
A Web Publication is discoverable in one of two ways: resources either include a link to the manifest (via
an HTTP Link header or an [html] link element), or the manifest can be loaded directly by
a compatible user agent.
With the establishment of Web Publications, user agents can build new experiences tailored specifically for their unique reading needs.
This section is non-normative.
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 dated 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.
The specification is also intended to facilitate different user agent architectures for the consumption of Web Publications. While a primary goal is that traditional Web user agents (browsers) will be able to consume Web Publications, this should not limit the capabilities of any other possible type of user agent (e.g., applications, whether standalone or running within a user agent, or even Web Publications that include their own user interface). As a result, the specification does not attempt to architect required solutions for situations whose expected outcome will vary depending on the nature of the user agent and the expectations of the user (e.g., how to prompt to initiate a Web Publication, or at what point or how much of a Web Publication to cache for offline use).
The working group is investigating integration with the work done on [appmanifest] to avoid duplication of concerns both in the expression and serialization of a manifest and in the processing and compilation of the infoset. It is expected, however, that there will be differences in the processing models of each (e.g., the initiation of the reading experience for Web Publications versus installation for applications).
The working assumption is that both applications and publications can use the same manifest and serialization to express the information necessary to initiate themselves.
The initial stage of evaluating this assumption involves:
The next stage will involve the serialization of the infoset in JSON to see how this expression of the manifest can be aligned with the expression of the [appmanifest]. Wherever semantically possible, the terms used and defined for [appmanifest] will be reused, and, conversely, some of the members defined for Web Publications may be generally useful for applications and may be added to the [appmanifest] as a common pool of information. To avoid possible future conflicts, care will be taken to use a naming scheme that clearly separates terms to be used for Web Publications only.
This specification consequently should be read and understood in this context of an ongoing investigation, and that significant changes may occur in the future.
This section will be updated with each release to reflect the current status of this work, and describe the evolving relationship.
See also issue #32 in the GitHub tracker for more discussion about integration.
Wherever appropriate, this document relies on terminology defined by the W3C Note "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 Web Content in a persistent and unambiguous manner. URLs, URNs, DOIs, ISBNs, and 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 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.
The general term URL is defined by the URL Standard [url]. It is used as in other W3C specifications, like HTML [html]. In particular, a URL allows for the usage of characters from Unicode following [rfc3987]. See the note in the HTML5 specification for further details.
A Web Publication is a collection of one or more 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.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, RECOMMENDED, REQUIRED, and SHOULD are to be interpreted as described in [RFC2119].
This specification defines two conformance classes: one for Web Publications and one for user agents that process them.
A Web Publication conforms to this specification if it meets the following criteria:
A user agent conforms to this specification if it meets the following criteria:
As the serialization of the manifest remains an open issue, specifics about how properties are compiled into the infoset remain unspecified. This includes, but is not limited to, what specific names the properties will have in the infoset, whether the names in the manifest will be the same as those in the infoset and/or whether mappings to properties from known vocabularies will be used.
The name "infoset" might 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 of the collected information.
This section is non-normative.
A Web Publication is defined by a set of properties known as its information set (infoset). The infoset is logically divided into two sets of properties: those that describe the publication and those that express key structures. These classifications only exist for the purposes of understanding the function of the properties, however.
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 compile about the Web Publication, but it also becomes concrete when the user agent creates an internal representation of that information.
The infoset is primarily compiled from a Web Publication's manifest, whose serialization requirements are defined in 4.4 Serialization. Some information can be obtained outside the manifest, however. 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 requirements for the expression of infoset properties are as follows:
REQUIRED: address
REQUIRED: default reading order and resource list
RECOMMENDED: table of contents
These requirements reflect the current minimum consensus, though a number of issues remain open that could change whether an item is required or recommended. Refer to the property descriptions for more information.
Accessibility metadata allows the discovery of features and affordances of the Web Publication that enable its use by users with different reading requirements and needs.
How to express accessibility metadata remains to be determined. This could be a grouping of properties from schema.org, for example, or could be split out into a list of individual properties.
A Web Publication's address is a URL that represents the primary entry point for the Web Publication. This URL MUST resolve to an [html] document.
The referenced document SHOULD be a resource of the Web Publication. It can be any resource, including one that is not listed in the default reading order. The document MUST link to the manifest to ensure that user agents can locate that document.
If the document is not a Web Publication resource, user agents SHOULD load the first document in the default reading order when initiating the Web Publication.
Providing access on the referenced document to navigation aids that facilitate consumption of the content improves the usability of the Web Publication, particularly in user agents that do not support Web Publications (e.g., include a table of contents on the page, or provide a link to one).
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, whether in whole or in part.
This issue raises a number of questions:
There is not yet consensus in the group on these issues, or on the name "entry page".
The base direction identifies the display direction for infoset properties.
The value of this property MUST be one of:
ltrrtlautoIf not specified, the value ltr SHOULD be assumed.
If property values are harvested from another resource, such as the table of contents, precedence SHOULD be given to the base direction specified in the resource, when provided.
A Web Publication's canonical identifier is a unique identifier that 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 a Web Publication is hosted at more than one address, this identifier allows a user agent to identify the shared relationship between the versions and to determine which of the available addresses is primary.
The canonical identifier is also intended to provide a measure of permanence above and beyond the Web Publication's address. Even if a Web Publication is permanently relocated to a new address, for example, the canonical identifier will provide a way of locating the new location (e.g., a DOI registry could be updated with the new URL, or a redirect could be added to the URL of the canonical identifier).
When assigned, the canonical identifier needs to be unique to one and only one Web Publication, independent of its address(es). Ensuring uniqueness is outside the scope of this specification, however. The actual uniqueness achievable depends on such factors as the conventions of the identifier scheme used and the degree of control over assignment of identifiers.
If the canonical identifier is a URL, it
can be used as the target of a "canonical" link [rfc6596] (e.g., an [html] link
element whose rel attribute has the value canonical or a Link HTTP header field [rfc5988] similarly
identified).
The question is whether a canonical identifier is necessary to call out explicitly in the infoset, or whether it is/can be handled by other metadata.
Creators are the individuals or entities responsible for the creation of the Web Publication.
The role the creator played in the creation of the Web Publication SHOULD also be specified (e.g., 'author', 'illustrator', 'translator').
The language specified in the Web Publication's infoset identifies the natural language of its properties.
When specified, the language MUST be a tag that conforms to [bcp47].
This language is not used in the processing or rendering of the Web Publication, and is not a replacement for identifying the language of each resource as defined by its format.
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 last modification date is the date when the Web Publication was last updated.
The last modification date SHOULD be updated whenever changes are made to the resources of the Web Publication, including the manifest. It does not necessarily reflect all changes to the Web Publication, however, as, for example, it might not reflect changes to third-party content.
The publication date is the date on which the Web Publication was originally published. It represents a static event in the lifecycle of a Web Publication and allows subsequent revisions to be identified and compared.
The exact moment of publication is intentionally left open to interpretation: it could be when the Web Publication is first made available online or could be a point in time before publication when the Web Publication is considered final.
Users often have the legal right to know and control what information is collected about them, how such information is stored and for how long, whether it is personally identifiable, and how it can be expunged. Including a statement that addresses all such privacy concerns is consequently an important part of publishing Web Publications. Even if no information is collected, such a declaration increases the trust users have in the content.
To address this concern, the infoset allows a link to be provided to a privacy policy. The privacy policy does not have to be a resource of the Web Publication, although including it as a resource is RECOMMENDED.
Refer to 10. Privacy for more information about privacy considerations in Web Publications.
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 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.
The default reading order is a specific progression through a set of Web Publication 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 resource to the next.
The default reading order MUST include at least one resource.
The default reading order is either specified directly in the manifest or in an [html]
nav element. In the latter case, the manifest MUST provide a link to the Web
Publication resource that contains the nav element, with a fragment identifier that
specifically identifies it.
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 default reading order of a Web Publication to be the files referenced in the table of contents.
There is consensus that a Web Publication must have a reading order and must/should have a table of contents (the main navigation entry point).
The resource list enumerates all resources that are used in the processing and rendering of a Web Publication (i.e., that are within its bounds). This list is the definitive source that user agents have in determining which referenced resources belong to the Web Publication and which are external to it.
The completeness of the resource list will affect the usability of the Web Publication in certain reading scenarios (e.g., the ability to read the Web Publication offline). For this reason, it is strongly RECOMMENDED to always provide a comprehensive list of all of the Web Publication's constituent resources. At a minimum, the resource list MUST include a list of all resources in the default reading order.
In some cases, a comprehensive list of these resources might not be easily achieved (e.g., third-party scripts that reference resources from deep within their source), but a Web Publication SHOULD remain consumable even if some of these resources are not identified as belonging to the Web Publication (e.g., when it is taken offline without them).
If a user agent encounters a resource that it cannot locate in the resource list, it MUST treat the resource as external to the Web Publication (e.g., it might alert the user before loading, open the resource in a new window, or unload the current Web Publication and resume normal Web browsing).
The discussion led to the question whether the manifest/infoset "must" list all resources or not. In this sense, this became a duplicate of issue #23 ended up at the same question.
The table of contents is a hierarchical list of links that reflects the structural outline of the 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 resource.
The table of contents is either specified directly in the manifest or in an [html] nav
element. In the latter case, the manifest MUST provide a link to the Web Publication resource that
contains the nav element, with a fragment identifier that specifically identifies
it.
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:
nav element that
has the role attribute value doc-toc);Does the manifest/infoset need to provide navigation, or do such mechanisms belong in the content?
This question arises only if the table of contents is accepted: can a table of contents navigation element refer, via links, to any resource that is not listed in the default reading order?
The issue of using the HTML
nav element as a possible encoding of the table of contents is mentioned or
explicitly addressed in the following issues:
The infoset is designed to provide a basic set of properties for use by user agents in presenting and rendering a Web Publication. It MAY be extended in the following ways:
User Agents MAY support additional properties but MUST NOT include unrecognized properties in the infoset. The use of linked records is RECOMMENDED whenever possible, as the use of native formats standardizes and simplifies processing by user agents.
This section is non-normative.
A manifest is a specific serialization of a Web Publication's infoset.
The requirements for a conforming Web Publication manifest are as follows:
The manifest is serialized as a JSON document [ecma-404].
Should the manifest be in an external file, embedded in a specified manner, or should either option be allowed?
In case the (concrete) manifest is expressed in JSON (see issue #7), should it be defined “on top” (i.e., as some form of an extension) of the Web Application Manifest specification, or should it be a fully separate specification?
A Web Publication MUST include at least one [html] document that links to the manifest.
There are no restrictions on a Web Publication beyond this requirement. It MAY reference resources of any media type, both in the default reading order and as dependencies of other resources.
When adding resources to a Web Publication, consider support in user agents. The use of progressive enhancement techniques and the provision of fallback content, as appropriate, will ensure a more consistent reading experience for users regardless of their preferred user agent.
Providing a link from a resource to the manifest of the Web Publication it belongs to allows a user agent to discover that a Web Publication is available. Links MUST take one or both of the following forms:
An HTTP Link header field [rfc5988] with its rel parameter set to the value
"publication".
Link: <https://example.com/webpub/manifest>; rel=publicationAn [html] link element with its rel attribute set to the value
"publication".
<link href="https://example.com/webpub/manifest" rel="publication"/>How linking to a manifest is done (relationship, media type) may change depending on future integration with Web App Manifest. For a list of differences in linking approaches, refer to the wiki analysis. See for discussion.
A resource SHOULD link to the Web Publication(s) to which it belongs.
The following details might be moved to the lifecycle section in a future draft.
When a resource links to multiple manifests, a user agent MAY choose to present one or more alternatives to the end user, or choose a single alternative on its own. The user agent MAY choose to present any manifest based upon information that it possesses, even one that is not explicitly listed as a parent (e.g., based upon information it calculates or acquires out of band). In the absence of a preference by user agent implementers, selection of the first manifest listed is suggested as a default.
If there is a collection of information about a Web Publication as a whole ("manifest") that exists separately from most of the publication's resources, there needs to be a way to associate the manifest with the other publication resources.
The publishing working group is currently evaluating the best approach for implementing Web Publications in user agents. This note is intended to provide an overview of where current thinking is at and what issues are under consideration.
The development of Web Publications is not viewed as a separate forking of the Web, but an enhancement layer that can be supported by user agents. To that end, the primary constraints on any solution for Web Publications are that:
While this specification will provide implementation flexibility for user agents, there are still a number of areas that have been identified as potentially needing to be detailed. These include:
initialization expectations for a Web Publication:
the creation of a "publication state":
tracking the extent of a Web Publication:
establishing the bounds of a Web Publication:
The working group intends to flesh out the lifecycle in later revisions once it is clearer what models are viable and what solutions can be standardized. Input on the feasibility and challenges of these approaches is welcome at any time.
This section contains placeholders for possible reading enhancements/affordances the user agent may/should/must provide. The list is subject to addition, modification and removal as the enhancements get discussed in more detail.
The layout and rendering of Web Publications is governed by the same rules that apply to all Web content: [html] documents are styled and laid out according to the rules of CSS, [svg] documents are rendered as expected of that format, etc. This specification requires no particular profile or subset of CSS, HTML, or SVG to be supported, other than the expectations set for these technologies by their respective specifications.
This specification intentionally avoids introducing any new layout features. Any shortcoming of the Web platform in terms of layout needs to be addressed for the whole Web platform, which means via CSS.
This working group will work with other relevant groups of the W3C to address platform-wide limitations that negatively impact Web Publications.
For the purposes of layout, each resource of a Web Publication is treated as a separate document. User agents MUST NOT mix content from multiple resources in the same rendering (e.g., CSS floats or absolutely positioned elements from one resource cannot intrude or overlap with content from an other resource).
Despite this general requirement that each resource should be treated as a separate document for the purpose of layout, there are some places where CSS specifications should be amended to be able to deal more intelligently with collections of resources like Web Publications.
One instance is the definition of cross-references, which are currently restricted to work only within a single document. This restriction should be relaxed to allow for cross-references between separate resources of a single Web Publication.
Another related would be to allow counters to accumulate across multiple resources of a single Web Publication (e.g., so that figures in multiple sections may be numbered in a single sequence).
This section is non-normative.
Publications have historically been presented via paged media, whereas Web pages almost always scroll. As the preferences of individual readers vary, and as different types of publications are better suited for one or the other, this specification encourages user agents to support both, and to offer a choice to their users.
It may be useful for authors to be able to specify a preference between scrolling and pagination,
even if a strict requirement is not possible. This should most likely be addressed through an
extension of @viewport or of the viewport meta tag(see
[css-device-adapt]), or possibly through an extension of @page (See
[css-page-3]). This should be discussed with the relevant working groups (CSSWG, WebPlatformWG, WHATWG).
When a user agent renders a Web Publication in a paginated layout, it MUST lay out each document in the default reading order sequentially, with the last page of a resource being followed by the first page of the subsequent one.
To avoid blank pages, if a resource ends on a left page (resp. right page), the subsequent one should start on a right page (resp. left page) even if the page progression (see [css-page-3]) would otherwise lead to it starting on the opposite page. It should also be possible to use the break-before property (see [css-break-3]) to force the content to resume on the opposite side if that was desired by the author.
[css-page-3] needs to be amended to describe this exception to the general behavior when dealing with collections of documents instead of individual documents.
How is pagination supposed to work when subsequent resources have opposite page progression directions (see [css-page-3]). For example, due to different a different writing mode? This is not necessarily a problem from a layout point of view, as each page is independent, but from an UI point of view. If swiping left means next page until the end of one chapter, and starts meaning previous page in the next chapter because the language is switched from English to Hebrew, this is going to be confusing.
Should any of the above be normative, or should this be up to user agents to explore, and only standardize if and when a clear winning approach emerges?
[css-page-3] needs to be amended so that page counters are not automatically reset to at the beginning of each new resource belonging to the same Web Publication.
Detail on offline caching and reading will be included in a future draft.
Detail on inter-publication search across multiple resources will be included in a future draft.
This section is non-normative.
The document referred from this section, i.e., Web Annotation Extensions for Web Publications [wpub-ann], has been recently renamed. Its previous was "Locators for Web Publication". The terminology used in this section has to be realigned with the name change.
Locators are used to identify, locate, retrieve, and/or reference locations and content fragments within
Web Publications (e.g., for address(es), bookmarks, and annotations). Locators traditionally take
the form of fragment identifiers [rfc3986], where the portion of a URL preceded by a number sign character (#) identifies a specific position within
the referenced resource.
For some use cases, it is essential to identify and reference a Web Publication resource—or a location in or a segment of a resource—in the scope or context of the Web Publication to which it belongs. A traditional fragment identifier cannot satisfy this requirement, since only the URL of the constituent resource containing the location or content fragment of interest is expressed. The Web Annotation Extensions for Web Publications [wpub-ann] document, based on the Web Annotation Model [annotation-model], addresses this issue by providing the means to express both the URL of the resource and the URL of the Web Publication.
Web Publication Locators also address the problem of referencing into a resource that was not authored with such a need in mind. A fragment identifier can only reference elements with explicit identifiers and locations with explicit anchor points. Web Publication Locators include a variety of selectors that work with the general structures and content of a resource (e.g., text selectors, CSS selectors).
As Web Publication Locators currently rely on a JSON-based expression syntax, it is not yet clear how much of this syntax can be translated to a fragment identifier. This may limit the usefulness beyond expressions that are also JSON-based (e.g., outside of annotations or bookmarks).
Illustrate with example of an easy to understand Web Publication Locator, such as might be used in annotating a simple Web Publication.
The semantics of Web Publication Locators are a mapping and extension of the Web Annotation Data Model [annotation-model] and Vocabulary [annotation-vocab] for describing and referencing a segment of a Web resource. As a result, Web Publication Locators provide the expressiveness needed for a broad range of annotation and bookmarking use cases. Additionally, Web Publication Locators provide a way to identify and reference a location within a Web Publication (i.e., as distinct from identifying and referencing a content fragment consisting of a span of characters or bytes). A Web Publication Locator can be used to identify, retrieve and/or reference a fragment of a Web Publication that spans multiple resources.
In composing a Web Publication Locator, use the canonical identifier of the Web Publication in preference to any alternative addresses. Such use facilitates the collation of Web Publication Locators associated with a particular Web Publication. URLs of Web Publication resources appearing in a Web Publication Locator should match the URL of the resource provided in the infoset.
This section is non-normative.
The following people contributed to the development of this specification:
The Working Group would also like to thank the members of the Digital Publishing Interest Group for all the hard work they did paving the road for this specification.