EPUB Packages 3.2 (original) (raw)

Abstract

This specification defines semantics and conformance requirements for an EPUB® Package. Each Package represents one Rendition of an EPUB Publication, and is defined by a Package Document that describes the content of the Rendition and sets the requirements for how Publication Resources are associated.

This specification also defines the EPUB Navigation Document, a machine- and human-readable specialization of an EPUB Content Document that provides navigation aids such as the table of contents.

This specification is one of a family of specifications that compose [EPUB32], an interchange and delivery format for digital publications based on XML and Web Standards. It is meant to be read and understood in concert with the other specifications that make up EPUB 3

Refer to [EPUB32Changes] for more information on the differences between this specification and its predecessor.

Status of This Document

This specification was published by theEPUB 3 Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under theW3C Community Final Specification Agreement (FSA) other conditions apply. Learn more aboutW3C Community and Business Groups.

If you wish to make comments regarding this document, please send them topublic-epub3@w3.org (subscribe,archives).

1. Introduction
2. Conformance
1. 2.1 Package Conformance
2. 2.2 Reading System Conformance
3. Package Document
4. Package Metadata
5. EPUB Navigation Document
A. Package Document Schema
B. The application/oebps-package+xml Media Type
C. Meta Properties Vocabulary
1. C.1 Overview
  1. C.1.1 About this Vocabulary
  2. C.1.2 Referencing
2. C.2 Metadata meta Properties
D. Metadata Link Vocabulary
E. Manifest Properties Vocabulary
E.1 Overview
1. E.1.1 About this Vocabulary
2. E.1.2 Referencing
E.2 Manifest item Properties
F. Spine Properties Vocabulary
F.1 Overview
1. F.1.1 About this Vocabulary
2. F.1.2 Referencing
F.2 Spine itemref Properties
G. Acknowledgements and Contributors
H. References
H.1 Normative references
H.2 Informative references

1. Introduction

1.1 Terminology

Terms with meanings specific to EPUB 3 are capitalized in this document (e.g., "Author", "Reading System"). A complete list of these terms and definitions is provided in [EPUB32].

Only the first instance of a term in a section is linked to its definition.

1.2 Conformance

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, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD, and SHOULD NOT are to be interpreted as described in [RFC2119].

1.3 Prefix Mappings

For convenience, the following reserved prefix mappings are used in this specification.

prefix	URI
dcterms	http://purl.org/dc/terms/
opf	http://www.idpf.org/2007/opf
rendition	http://www.idpf.org/vocab/rendition/#

2. Conformance

2.1 Package Conformance

A conformant EPUB Package MUST meet all of the following criteria:

Package Document

It MUST contain exactly one Package Document, which MUST conform to the content requirements defined in Package Document — Content Conformance.

Publication Resources

All Publication Resources associated with the Package_MUST_ be listed in the Package Document (as defined in manifest).

EPUB Navigation Document

It MUST contain exactly one EPUB Navigation Document, which_MUST_ conform to the content requirements defined in EPUB Navigation Documents — Content Conformance.

Content Documents

It MUST contain one or more EPUB Content Documents, each of which MUST conform to the content requirements defined in [ContentDocs32].

CSS Style Sheets

It MAY contain zero or more CSS Style Sheets, each of which MUST conform to the content requirements defined in CSS Style Sheets — Content Conformance [ContentDocs32].

Pronunciation Lexicons

It MAY contain zero or more PLS Documents, each of which MUST conform to the content requirements defined in PLS Documents — Content Conformance [ContentDocs32].

Media Overlay Documents

It MAY contain zero or more Media Overlay Documents, each of which_MUST_ conform to the content requirements defined in [MediaOverlays32].

Additional Resources

It MAY contain zero or more Publication Resources in addition to those listed above, each of which MUST adhere to the requirements in Publication Resources [EPUB32].

2.2 Reading System Conformance

An EPUB Reading System MUST meet all of the following criteria:

It MUST process the Package Document as defined inPackage Document — Reading System Conformance, and honor all presentation logic expressed through the Package Document (e.g., the reading order, fallback chains, page progression direction and fixed layouts).
It MUST process the EPUB Navigation Document as defined in EPUB Navigation Documents — Reading System Conformance.
It MUST NOT use any resources not listed in the Package Document in the processing of the Package (e.g., META-INF files ([OCF32]) or resources specific to other Renditions of the EPUB Publication).

3. Package Document

3.1 Introduction

This section is non-normative.

The Package Document is an XML document that consists of a set of elements that each encapsulate information about a particular aspect of the EPUB Package. These elements serve to centralize metadata, detail the individual resources that compose the Package and provide the reading order and other information necessary to render the Rendition.

The following list summarizes the information found in the Package Document:

Metadata — mechanisms to include and/or reference metadata applicable to the given Rendition of the EPUB Publication.
A manifest — identifies (via IRI [RFC3987]) and describes (via MIME media type [RFC4839]) the set of resources that collectively compose the given Rendition.
A spine — an ordered sequence of ID references to top-level resources in the manifest from which all other resources in the set can be reached or utilized. The spine defines the default reading order of the given Rendition.
Collections — a method of encapsulating and identifying subcomponents within the Package.
Manifest fallback chains — a mechanism that defines an ordered list of top-level resources as content equivalents. A Reading System can then choose between the resources based on which it is capable of rendering.

3.2 Content Conformance

A Package Document MUST meet all of the following criteria:

Document Properties

It MUST meet the conformance constraints for XML documents defined in XML Conformance [EPUB32].

It MUST conform to all content conformance constraints expressed in Package Document Definition.

Note

Some of the content conformance constraints can be checked by validating content documents against the schemas provided in Appendix A, Package Document Schema.

File Properties

The Package Document filename SHOULD use the file extension .opf.

Package Documents have the MIME media type application/oebps-package+xml [RFC4839].

3.3 Reading System Conformance

An EPUB Reading System MUST meet all of the following criteria:

Processing

It MUST process the Package Document in conformance with all Reading System conformance constraints expressed in Package Document Definition.

It SHOULD process rendering metadata, as expressed in Package Rendering Metadata.

It MUST process fixed layout metadata, as expressed in Fixed-Layout Properties.

It MUST ignore proprietary metadata properties that pertain to layout expressions if they conflict behaviorally with the property semantics defined in Fixed-Layout Properties.

3.4 Package Document Definition

All [XML] elements defined in this section are in the http://www.idpf.org/2007/opf namespace [XML-NAMES] unless otherwise specified.

When an element defined in this section has mandatory text content, that content is referred to as the value of the element in the explanatory descriptions.

3.4.1 The `package` Element

The package element is the root element of the Package Document and defines various aspects of the EPUB Package (see the introduction for a general overview).

Element Name

package

Usage

The package element is the root element of the Package Document.

Attributes

dir [optional]
id [optional]
prefix [optional]
xml:lang [optional]
unique-identifier [required]
version [required]

Content Model

In this order:

metadata [exactly 1]
manifest [exactly 1]
spine [exactly 1]
guide [0 or 1] (legacy)
bindings [0 or 1] (deprecated)
collection [0 or more]

The version attribute specifies the EPUB specification version to which the given EPUB Package conforms. The attribute MUST have the value "3.0" to indicate compliance with this version of the specification.

The unique-identifier attribute takes an IDREF [XML] that identifies the dc:identifier element that provides the preferred, or primary, identifier. Refer to Publication Identifiers for more information.

The prefix attribute provides a declaration mechanism for prefixes not reserved by this specification. Refer to The prefix Attribute for more information.

3.4.2 Shared Attributes

This section provides definitions for shared attributes (i.e., attributes that are allowed on two or more elements).

dir

Specifies the base text direction of the content and attribute values of the carrying element and its descendants.

Inherent directionality specified using [Unicode] takes precedence over this attribute.

Allowed values are ltr (left-to-right) and rtl (right-to-left).

Allowed on: collection, dc:contributor, dc:coverage, dc:creator, dc:description, dc:publisher, dc:relation, dc:rights, dc:subject, dc:title, meta andpackage.

href

An absolute or relative IRI reference [RFC3987] to a resource.

<link rel="record"
      href="meta/9780000000001.xml" 
      media-type="application/marc"/>

Allowed on: item and link.

id

The ID [XML] of the element, which MUST be unique within the document scope.

<dc:identifier id="pub-id">urn:isbn:97800000000001</dc:identifier>

Allowed on: collection, dc:contributor, dc:coverage, dc:creator, dc:date, dc:description, dc:format, dc:identifier, dc:language, dc:publisher, dc:relation, dc:rights, dc:source, dc:subject, dc:title, dc:type,item, itemref, link, manifest, meta, package andspine.

media-type

A media type [RFC2046] that specifies the type and format of the referenced resource.

<link rel="record"
      href="http://example.org/meta/12389347?format=xmp"
      media-type="application/xml"
      properties="xmp"/>

Allowed on: item and link.

properties

A space-separated list of property values.

Refer to each element's definition for the reserved vocabulary that can be used with the attribute.

<item id="nav" 
    href="nav.xhtml" 
    properties="nav"
    media-type="application/xhtml+xml"/>

Allowed on: item, itemref and link.

refines

Identifies the expression or resource augmented by the element. The value of the attribute must be a relative IRI [RFC3987] referencing the resource or element being described.

The refines attribute is OPTIONAL depending on the type of metadata being expressed. When omitted, the element defines a primary expression.

Allowed on: link and meta.

xml:lang

Specifies the language used in the contents and attribute values of the carrying element and its descendants, as defined in section 2.12 Language Identification of [XML].

<package … xml:lang="ja">
   …
</package>

Allowed on: collection, dc:contributor, dc:coverage, dc:creator, dc:description, dc:publisher, dc:relation, dc:rights, dc:subject, dc:title, meta andpackage.

3.4.3 Metadata

3.4.3.1 The `metadata` Element

The metadata element encapsulates meta information for the givenRendition.

Element Name

metadata

Usage

REQUIRED first child of package.

Attributes

None

Content Model

In any order:

dc:identifier [1 or more]
dc:title [1 or more]
dc:language [1 or more]
DCMES Optional Elements [0 or more]
meta [1 or more]
OPF2 meta [0 or more] (legacy)
link [0 or more]

The Package Document metadata element has two primary functions:

to provide a minimal set of meta information for Reading Systems to use to internally catalogue an EPUB Publication and make it available to a user (e.g., to present in a bookshelf).
to provide access to all rendering metadata needed to control the layout and display of the Rendition's content (e.g., fixed-layout properties).

The Package Document is not designed to provide complex metadata encoding capabilities. If more detailed information about an EPUB Publication is needed, metadata records (e.g., that conform to an international standard such as [ONIX] or are created for custom purposes) can be associated using the link element. This approach allows the metadata to be processed in its native form, avoiding the potential problems and information loss caused by translating to use the minimal Package Document structure.

In keeping with this philosophy, the Package Document only has the following minimal metadata requirements: it MUST include the [DC11] title, identifier and language elements together with the [DCTERMS] modified property. All other metadata is_OPTIONAL_.

The meta element provides a generic mechanism for including metadata properties from any vocabulary. It is typically used to include rendering metadata defined in EPUB specifications, but MAY be used for any metadata purposes.

Note

See [EPUBAccessibility] for accessibility metadata recommendations.

3.4.3.2 DCMES Required Elements

3.4.3.2.1 The `identifier` Element

The [DC11] identifier element contains an identifier associated with the given Rendition, such as a UUID, DOI or ISBN.

Element Name

dc:identifier

Namespace

http://purl.org/dc/elements/1.1/

Usage

REQUIRED child of metadata.

Attributes

id [optional]

Content Model

Text

The metadata section MUST include an identifier element that contains an unambiguous identifier for the Rendition. This identifier MUST be marked as the Unique Identifier via the package element unique-identifier attribute.

The Unique Identifier for each Rendition MAY differ, and a Rendition MAY include additional identifier elements.

To differentiate different versions of the same EPUB Publication, this specification makes a distinction between the Unique Identifier for an EPUB Publication and theRelease Identifier that uniquely identifies a specific version of it.

To identify a specific version of a packaged EPUB Publication, a Release Identifier can be constructed by combining the Unique Identifier with the last modified date of the Rendition. For more information on the semantics and requirements of the Release Identifier, refer to Release Identifier.

Whenever a Rendition is modified, it MUST include a new last modified date.

To determine whether an identifier conforms to an established system or has been granted by an issuing authority, Reading Systems SHOULD check for an identifier-type property.

Reading Systems MUST trim all leading and trailing white space [XML] from the element value before processing the value.

This specification imposes no additional restrictions or the requirements of the identifier except that it MUST be at least one character in length after white space has been trimmed. It is strongly encouraged that the identifier be a fully qualified URI, however.

3.4.3.2.2 The `title` Element

The [DC11] title element represents an instance of a name given to theEPUB Publication.

Element Name

dc:title

Namespace

http://purl.org/dc/elements/1.1/

Usage

REQUIRED child of metadata.

Attributes

dir [optional]
id [optional]
xml:lang [optional]

Content Model

Text

The metadata section MUST include at least one title element containing the title for the EPUB Publication.

Reading Systems MUST recognize the first title element in document order as the main title of the EPUB Publication (i.e., the primary one to present to users). This specification does not define how to process additionaltitle elements.

The title for each Rendition MAY differ.

Reading Systems MUST trim all leading and trailing white space [XML] before processing the value.

This specification imposes no additional restrictions or requirements on the title except that it MUST be at least one character in length after white space has been trimmed.

3.4.3.2.3 The `language` Element

The [DC11] language element specifies the language of the content of the given Rendition. This value is not inherited by the individual resources of the Rendition.

Element Name

dc:language

Namespace

http://purl.org/dc/elements/1.1/

Usage

REQUIRED child of metadata. Repeatable.

Attributes

id [optional]

Content Model

Text

The metadata section MUST include at least one language element with a value conforming to [BCP47].

Additional language elements MAY be included for multilingual Publications, but each element's value MUST conform to [BCP47]. The first language element in document order is considered the primary language of the rendition.

Languages for each Rendition MAY differ.

Reading Systems MUST trim all leading and trailing white space [XML] before processing the value.

3.4.3.3 DCMES Optional Elements

3.4.3.3.1 General Definition

With the exception of identifier, language and title, all other [DC11] elements are designated as_OPTIONAL_. These elements conform to the following generalized definition:

Element Name

Namespace

http://purl.org/dc/elements/1.1/

Usage

OPTIONAL child of metadata. Repeatable.

Attributes

dir [optional] – only allowed on contributor,coverage, creator,description, publisher,relation, rights andsubject.
id [optional] – allowed on any element.
xml:lang [optional] – only allowed on contributor,coverage, creator,description, publisher,relation, rights andsubject.

Content Model

Text

The OPTIONAL [DC11] metadata for each Rendition MAY differ.

Reading Systems MUST trim all leading and trailing white space [XML] before processing the value.

The value of all OPTIONAL [DC11] elements MUST be at least one character in length after white space has been trimmed.

This specification does not modify the [DC11] element definitions except as noted in the following sections.

3.4.3.3.2 The `contributor` Element

The [DC11] contributor element is used to represent the name of a person, organization, etc. that played a secondary role in the creation of the content of an EPUB Publication.

The requirements for the contributor element are identical to those for thecreator element in all other respects.

3.4.3.3.3 The `creator` Element

The [DC11] creator element represents the name of a person, organization, etc. responsible for the creation of the content of the Rendition. The role property can be attached to the element to indicate the function the creator played in the creation of the content.

The creator element SHOULD contain the name of the creator as the Author intends it to be displayed to a user. The file-as property MAY be attached to include a normalized form of the name, and the alternate-script property to represent a creator's name in another language or script.

If an EPUB Publication has more than one creator, each SHOULD be included in a separatecreator element.

When determining display priority, Reading Systems MUST use the document order ofcreator elements in the metadata section, where the firstcreator element encountered is the primary creator. If a Reading System exposes creator metadata to the user, it SHOULD include all the creators listed in themetadata section whenever possible (e.g., when not constrained by display considerations).

Secondary contributors SHOULD be represented using the contributor element.

3.4.3.3.4 The `date` Element

The [DC11] date element MUST only be used to define the publication date of the EPUB Publication. The publication date is not the same as the last modified date (the last time theRendition was changed).

It is RECOMMENDED that the date string conform to [ISO8601], particularly the subset expressed in W3C Date and Time Formats [DateTime], as such strings are both human and machine readable.

Additional dates SHOULD be expressed using the specialized date properties available in the [DCTERMS] vocabulary, or similar.

The publication date MAY be common to all instances of an EPUB Publication or MAY change from instance to instance (e.g., if the EPUB Publication gets generated on demand).

Only one date element is allowed.

3.4.3.3.5 The `subject` Element

The [DC11] subject element identifies the subject of the EPUB Publication. The value of the element SHOULD be the human-readable heading or label, but_MAY_ be the code value if the subject taxonomy does not provide a separate descriptive label.

Authors MAY identify the system or scheme the element's value is drawn from using the authority property.

When a scheme is identified, a subject code MUST be attached using the term property.

The term property MUST NOT be attached to a subject element that does not specify a scheme.

The values of the subject element and term property are case sensitive only when the designated scheme requires.

3.4.3.3.6 The `type` Element

The [DC11] type element is used to indicate that the given EPUB Publication is of a specialized type (e.g., annotations or a dictionary packaged in EPUB format).

An informative registry of specialized EPUB Publication types for use with this element is maintained in the [TypesRegistry], but Authors MAY use any text string as a value.

3.4.3.4 The `meta` Element

The meta element provides a generic means of including package metadata.

Element Name

meta

Usage

As child of the metadata element. Repeatable.

Attributes

dir [optional]
id [optional]
property [required]
refines [optional]
scheme [optional]
xml:lang [optional]

Content Model

Text

Each meta element defines a metadata expression. Theproperty attribute takes a property data type value that defines the statement being made in the expression, and the text content of the element represents the assertion. (Refer to Vocabulary Association Mechanisms for more information.)

This specification defines two types of metadata expressions that can be defined using themeta element:

A primary expression is one in which the expression defined in the meta element establishes some aspect of the EPUB Publication. A meta element that omits a refines attribute defines a primary expression.
A subexpression is one in which the expression defined in the meta element enhances the meaning of the expression or resource referenced in its refines attribute. A subexpression might refine a media clip, for example, by expressing its duration, or refine a creator or contributor expression by defining the role of the person.

Subexpressions are not limited to refining only primary expressions and resources; they may be used to refine the meaning of other subexpressions, thereby creating chains of information.

Note

All of the DCMES [DC11] elements represent primary expressions, and permit refinement by meta element subexpressions.

This specification reserves the Meta Properties Vocabulary for use with theproperty attribute. Terms from other vocabularies MAY be used provided they have a prefix (refer to Reserved Prefixes for a list of prefixes that do not have to be declared).

The scheme attribute identifies the system or scheme that the element's value is drawn from. The value of the attribute MUST be a property data type that resolves to the resource that defines the scheme. If a Reading System does not recognize the scheme attribute value, it SHOULD treat the value of the element as a string.

Reading Systems SHOULD ignore all meta elements whose property attributes define expressions they do not recognize. A Reading System MUST NOT fail when encountering unknown expressions.

Unless an individual property explicitly defines a different white space normalization algorithm, Reading Systems MUST trim all leading and trailing white space [XML] from themeta element values before further processing them.

Every meta element MUST express a value that is at least one character in length after white space normalization.

3.4.3.5 The `link` Element

The link element is used to associate resources with the given Rendition, such as metadata records.

Element Name

link

Usage

As a child of metadata. Repeatable.

Attributes

href [required]
id [optional]
media-type [conditionally required]
properties [optional]
refines [optional]
rel [required]

Content Model

Empty

The metadata element MAY contain zero or morelink elements, each of which identifies the location of a linked resource in its REQUIRED href attribute

Linked resources are not Publication Resources and MUST NOT be listed in the manifest. A linked resource MAY be embedded in a Publication Resource that is listed in the manifest, however, in which case it_MUST_ be a Core Media Type Resource [EPUB32] (e.g., an EPUB Content Document could contain a metadata record serialized as [RDFA-CORE] or [JSON-LD]).

Linked resources MAY be located locally or remotely, but Authors need to be aware that retrieval of Remote Resources by Reading Systems is OPTIONAL (i.e., the resource might not be available).

The media-type attribute is OPTIONAL when a linked resource is located outside the EPUB Container, as more than one media type could be served from the same IRI. The attribute is REQUIRED for allLocal Resources.

The REQUIRED rel attribute takes a space-separated list ofproperty values that establish the relationship the resource has with the Rendition.

Reading System do not have to use or present linked resources, even if they recognize the relationship defined in the rel attribute.

The value of the media-type attribute is not always sufficient to identify the type of linked resource (e.g., many XML-based record formats use the media type "application/xml"). To aid Reading Systems in the identification of such generic resources, the properties attribute can be attached with a semantic identifier.

The list of reserved relationships and properties recognized by this specification is defined in the EPUB Metadata Link Vocabulary.

Authors MAY add relationships and properties from other vocabularies via the metadata extensibility mechanism defined in this specification. Authors also MAY create new values by defining their own prefixes. Refer to Vocabulary Association Mechanisms for more information.

In the case of a linked metadata record, Reading Systems MUST NOT skip processing the metadata expressed in the Package Document and only use the information expressed in the record. Linked records are intended to enhance the information available to Reading Systems, and the package metadata typically contains important rendering information. Reading Systems MAY compile metadata from multiple linked records; they do not have to select only one record.

When it comes to resolving discrepancies and conflicts between metadata expressed in the Package Document and in linked metadata records, Reading Systems MUST use the document order of link elements in the Package Document to establish precedence (i.e., metadata in the first linked record encountered has the highest precedence and metadata in the Package Document the lowest, regardless of whether the link elements occur before, within or after the package metadata elements).

Reading Systems MUST ignore any instructions contained in linked resources related to the layout and rendering of the EPUB Publication.

Note

Due to the variety of metadata record formats and serializations that can be linked to an EPUB Publication, and the complexity of comparing metadata properties between them, this specification does not require Reading Systems to process linked records.

3.4.4 Manifest

3.4.4.1 The `manifest` Element

The manifest element provides an exhaustive list of the Publication Resources that constitute the given Rendition, each represented by an item element.

Element name

manifest

Usage

REQUIRED second child of package, following metadata.

Attributes

id [optional]

Content Model

item [1 or more]

Note

This specification supports internationalized resource naming, so elements and attributes that reference Publication Resources accept IRIs as their value. For compatibility with older Reading Systems that only accept URIs, resource names need to be restricted to the ASCII character set.

3.4.4.2 The `item` Element

The item element represents a Publication Resource.

Element Name

item

Usage

As a child of manifest. Repeatable.

Attributes

fallback [conditionally required]
href [required]
id [required]
media-overlay [optional]
media-type [required]
properties [optional]

Content Model

Empty

Each item element in the manifest identifies a Publication Resource by the IRI [RFC3987] provided in its href attribute. The IRI MAY be absolute or relative. In the case of relative IRIs, Reading Systems MUST use the IRI of the Package Document as the base when resolving these to absolute IRIs. The resulting absolute IRI MUST be unique within the manifest scope.

All Publication Resources MUST be referenced from themanifest, regardless of whether they are Local or Remote Resources. Refer to Publication Resource Locations [EPUB32] for media type-specific requirements regarding resource locations.

Note that the manifest is not self-referencing: it MUST NOT include anitem element that refers to the Package Document itself.

The Publication Resource identified by an item element MUST conform to the applicable specification(s) as inferred from the MIME media type provided in the media-type attribute. Core Media Type Resources MUST use the media type designated in Supported Media Types [EPUB32].

The fallback attribute takes an IDREF [XML] that identifies a fallback for the Publication Resource referenced from the item element. Fallbacks MAY be provided for Core Media Type Resources (e.g., to provide a static alternative to a Scripted Content Document). Fallback requirements for Foreign Resources are defined in Manifest Fallbacks.

This specification reserves the EPUB Manifest Properties Vocabulary for use with the properties attribute. Terms from other vocabularies MAY be used provided they have a prefix (refer to Reserved Prefixes for a list of prefixes that do not have to be declared).

Authors MUST declare all applicable descriptive metadata properties for each Publication Resource in this attribute, as Reading Systems MAY optimize the rendering depending on the properties that have been set (e.g., disable a rendering process or use a fallback). Reading Systems MUST ignore all descriptive metadata properties that they do not recognize.

Exactly one item MUST be declared as the EPUB Navigation Document using the nav property.

The media-overlay attribute takes an IDREF [XML] that identifies the Media Overlay Document for the resource described by this item. Refer to Packaging [MediaOverlays32] for more information.

Note

The order of item elements in the manifest is not significant. The presentation sequence of content documents is provided in the spine.

Examples

The following example shows a manifest that contains only Core Media Type Resources.

<manifest>
    <item id="nav" 
          href="nav.xhtml" 
          properties="nav"
          media-type="application/xhtml+xml"/>
    <item id="intro" 
          href="intro.xhtml" 
          media-type="application/xhtml+xml"/>
    <item id="c1" 
          href="chap1.xhtml" 
          media-type="application/xhtml+xml"/>
    <item id="c1-answerkey" 
          href="chap1-answerkey.xhtml" 
          media-type="application/xhtml+xml"/>
    <item id="c2" 
          href="chap2.xhtml" 
          media-type="application/xhtml+xml"/>
    <item id="c2-answerkey" 
          href="chap2-answerkey.xhtml" 
          media-type="application/xhtml+xml"/>
    <item id="c3" 
          href="chap3.xhtml" 
          media-type="application/xhtml+xml"/>
    <item id="c3-answerkey" 
          href="chap3-answerkey.xhtml" 
          media-type="application/xhtml+xml"/>    
    <item id="notes" 
          href="notes.xhtml" 
          media-type="application/xhtml+xml"/>
    <item id="cover" 
          href="./images/cover.svg" 
          properties="cover-image"
          media-type="image/svg+xml"/>
    <item id="f1" 
          href="./images/fig1.jpg" 
          media-type="image/jpeg"/>
    <item id="f2" 
          href="./images/fig2.jpg" 
          media-type="image/jpeg"/>
    <item id="css" 
          href="./style/book.css" 
          media-type="text/css"/>   
    <item id="pls" 
          href="./speech/dict.pls" 
          media-type="application/pls+xml"/>
</manifest>

3.4.4.3 Manifest Fallbacks

Foreign Resources MAY be referenced in contexts in which an intrinsic fallback cannot be provided (e.g., directly from spine itemref elements; from [HTML]img, iframe and link elements in XHTML Content Documents; and from @import rules in CSS Style Sheets). Manifest fallbacks MUST be provided in such cases.

Manifest fallbacks are provided using the fallback attribute on the manifest item element that represents the Publication Resource. The fallback attribute's IDREF [XML] value MUST resolve to another item in the manifest. This fallbackitem MAY itself specify another fallback item, and so on.

The ordered list of all the ID references that can be reached starting from a given item'sfallback attribute represents the fallback chain for that item. The order of the resources in the fallback chain represents the Author's preferred fallback order.

A Reading System that does not support the Media Type of a given Publication Resource MUST traverse the fallback chain until it has identified at least one supported Publication Resource to be used in place of the unsupported resource. If the Reading System supports multiple Publication Resources in the fallback chain, it MAY select the resource to use based on specific properties of that resource, otherwise it SHOULD honor the Author's preferred fallback order. If a Reading System does not support any resource in the fallback chain, it MUST alert the reader that content could not be displayed.

Fallback chains MUST conform to one of the following requirements, as appropriate:

For Foreign Resources referenced directly from spine itemref elements, the chain MUST contain at least oneEPUB Content Document.
For Foreign Resources for which an intrinsic fallback cannot be provided, the chain_MUST_ contain at least one Core Media Type Resource.

Fallback chains MUST NOT contain any circular- or self-references to item elements in the chain. User agents MUST terminate the fallback chain at the first reference to a manifest item that has already been encountered.

Fallbacks MAY also be provided for Top-Level Content Documents that are EPUB Content Documents; a Reading System MAY choose to utilize such fallbacks in order to find the optimal version of a Content Document to render in a given context. An example of when this feature can be utilized is when providing fallbacks for scripted content [ContentDocs32].

3.4.4.4 The `bindings` Element (Deprecated)

The bindings element defines a set of custom handlers for media types not supported by this specification. Its use is deprecated.

Refer to [Publications301] for more information about this element.

3.4.5 Spine

3.4.5.1 The `spine` Element

The spine element defines an ordered list of manifest item references that represent the default reading order of the given Rendition.

Element name

spine

Usage

REQUIRED third child of package, following manifest.

Attributes

id [optional]
page-progression-direction [optional]
toc [optional] (legacy)

Content Model

itemref [1 or more]

Reading Systems MUST provide a means of rendering the Rendition in the order defined in thespine, which includes: 1) recognizing the first primaryitemref as the beginning of the default reading order; and, 2) rendering successive primary items in the order given in the spine.

All Publication Resources that are hyperlinked to from Publication Resources in the spine MUST themselves be listed in thespine, where hyperlinking is defined to be any linking mechanism that requires the user to navigate away from the current resource. Common hyperlinking mechanisms include the href attribute of the [HTML] a and area elements and scripted links (e.g., using DOM Events and/or form elements). The requirement to list hyperlinked resources applies recursively (i.e., all Publication Resources hyperlinked from hyperlinked Publication Resources also have to be listed, and so on.).

All Publication Resources hyperlinked to from the EPUB Navigation Document also MUST be listed in the spine, regardless of whether the Navigation Document is itself listed in the spine.

Note

As Remote Resources referenced from hyperlinks are not Publication Resources, they are not subject to the requirement to include in the spine (e.g., Web pages and resources).

Embedded Publication Resources (e.g., via the [HTML] iframe element) do not have to be listed in thespine.

The page-progression-direction attribute sets the global direction in which the content flows. Allowed values areltr (left-to-right), rtl (right-to-left) anddefault. When the default value is specified, the Author is expressing no preference and the Reading System can choose the rendering direction. Thedefault value MUST be assumed when the attribute is not specified. In this case, the reading system SHOULD choose a default page-progression-direction value based on the first language element.

Although the page-progression-direction attribute sets the global flow direction, individual Content Documents and parts of Content Documents MAY override this setting (e.g., via the writing-mode CSS property). Reading Systems MAY also provide mechanisms to override the default direction (e.g., buttons or settings that allow the application of alternate style sheets).

Reading Systems MUST ignore the page progression direction defined in pre-paginated XHTML Content Documents. Thepage-progression-direction attribute defines the flow direction from one fixed-layout page to the next.

The legacy toc attribute takes an IDREF [XML] that identifies the manifest item that represents the NCX.

3.4.5.2 The `itemref` Element

The child itemref elements of the spine represent a sequential list of Publication Resources (typically EPUB Content Documents). The order of the itemref elements defines the default reading order of the given Rendition.

Element Name

itemref

Usage

As a child of spine. Repeatable.

Attributes

id [optional]
idref [required]
linear [optional]
properties [optional]

Content Model

Empty

Each itemref element MUST reference the ID [XML] of a unique item in the manifest via the IDREF [XML] in its idref attribute (i.e., two or moreitemref elements cannot reference the same item).

Each referenced manifest item MUST be either a) anEPUB Content Document or b) another type of Publication Resource which,regardless of whether it is a Core Media Type Resource or a Foreign Resource, MUST include an EPUB Content Document in its fallback chain.

The linear attribute indicates whether the referenced item contains content that contributes to the primary reading order and has to be read sequentially ("yes") or auxiliary content that enhances or augments the primary content and can be accessed out of sequence ("no"). Examples of auxiliary content include: notes, descriptions and answer keys.

The linear attribute allows Reading Systems to distinguish content that a user needs to access as part of the default reading order from supplementary content which might, for example, be presented in a popup window or omitted from an aural rendering.

When rendering an EPUB Publication, a Reading System MAY either suppress non-linear content so that it does not appear in the default reading order, or ignore the linear attribute in order to provide users access to the entire content of the EPUB Publication. This specification does not mandate which model Reading Systems have to use. A Reading System MAY also provide the option for users to toggle between the two models.

Each Rendition MUST include at least one itemref whose linear attribute value is either explicitly or implicitly set to "yes". Anitemref that omits the linear attribute is assumed to have the value "yes".

Authors MUST provide a means of accessing all non-linear content (e.g., hyperlinks in the content or from the EPUB Navigation Document).

This specification reserves the EPUB Spine Properties Vocabulary for use with the properties attribute. Terms from any other vocabulary MAY be used provided they have a prefix (refer toReserved Prefixes for a list of prefixes that do not have to be declared).

All applicable descriptive metadata properties defined in the Spine Properties Vocabulary SHOULD be declared.

Reading Systems MUST ignore all metadata properties expressed in the properties attribute that they do not recognize.

Examples

3.4.6 Collections

3.4.6.1 The `collection` Element

The collection element defines a related group of resources.

Element Name

collection

Usage

OPTIONAL sixth element of package. Repeatable.

Attributes

dir [optional]
id [optional]
role [required]
xml:lang [optional]

Content Model

In this order: metadata [0 or 1], ( collection [1 or more] or ( collection [0 or more], link [1 or more] ))

The collection element allows resources to be assembled into logical groups for a variety of potential uses: enabling content that has been split across multiple EPUB Content Documents to be reassembled back into a meaningful unit (e.g., an index split across multiple documents), identifying resources for specialized purposes (e.g., preview content), or collecting together resources that present additional information about the given Rendition.

The collection element, as defined in this section, represents a generic framework from which specializations are intended to be derived (e.g., through EPUB sub-specifications). Such specializations MUST define the purpose of thecollection element within a Rendition, as well as all requirements for its valid production and use (specifically any requirements that differ from the general framework presented below).

Each specialization MUST define a role value that uniquely identifies all conformant collection elements. The role of eachcollection element in the Package Document MUST be identified in itsrole attribute, whose value MUST be one or more NMTOKENs [XMLSCHEMA-2] and/or absolute IRIs [RFC3987]. The use of NMTOKEN values is reserved for roles not defined in EPUB, which are maintained in the [RoleRegistry]. NMTOKEN values not defined in the registry are not valid. No roles are defined in this section.

Third parties MAY define custom roles for the collection element, but such roles_MUST_ be identified using absolute IRIs. Custom roles MUST NOT incorporate the string "idpf.org" in the host component of their identifying IRI.

Note

To facilitate interoperability of custom roles across Reading Systems, implementers are strongly encouraged to document their use of the collection element in [RoleExtensions].

The OPTIONAL metadata element child ofcollection is an adaptation of the package metadata element, with the following differences in syntax and semantics:

No metadata is mandatory by default.
Package-level restrictions on the use of metadata elements MAY be overridden.
All primary metadata expressions apply to thecollection.
The refines attribute MUST NOT reference elements outside the containing collection.
The OPF2 meta element MUST NOT be included.

A collection MAY define sub-collections through the inclusion of one or more child collection elements.

The link element child of collection is an adaptation of the metadata link element, with the following differences in syntax and semantics:

The rel attribute is OPTIONAL.
The properties attribute also accepts manifest item properties without a prefix (e.g., so that a collection can declare its own Navigation Document or cover image).
The refines attribute MUST NOT be attached.

Each link element MUST reference a resource that is a member of the group. The order of link elements is not significant.

Specializations of the collection element MAY tailor the requirements defined above to better reflect their needs (e.g., requiring metadata, imposing further restrictions on the use of elements and attributes, or making the order of link elements significant). However, the resulting content model MUST represent a valid subset of the one defined in this section (e.g., specializations cannot introduce new elements or attributes, or re-introduce those expressly forbidden above). Specializations MUST NOT define collections in a way that overrides the requirements of the manifest and spine.

In the context of this specification, support for collections in Reading Systems is OPTIONAL. Reading Systems MUST ignore collection elements that define unrecognized roles.

The rendering of a Rendition MUST NOT be dependent on the recognition ofcollection elements. The content MUST remain consumable by a user without any information loss or other significant deterioration.

Examples

3.4.7 Legacy

3.4.7.1 The `meta` Element

The meta element [OPF2] is a legacy feature that previously provided a means of including generic metadata. It is replaced in EPUB 3 by the updated meta element, which uses different attributes and requires text content.

For more information about the meta element, refer to its definition in [OPF2].

3.4.7.2 The `guide` Element

The guide element [OPF2] is a legacy feature that previously provided machine-processable navigation to key structures in an EPUB Publication. It is replaced in EPUB 3 by landmarks in the EPUB Navigation Document.

For more information about the guide element, refer to its definition in [OPF2].

3.4.7.3 NCX

The NCX [OPF2] is a legacy feature that previously provided the table of contents for EPUB Publications. It is replaced in EPUB 3 by the EPUB Navigation Document.

For more information about the NCX, refer to its definition in [OPF2].

4.1 Publication Identifiers

4.1.1 Unique Identifier

The Author is responsible for including a primary identifier in the Package Document metadata that is unique to one and only one EPUB Publication. ThisUnique Identifier, whether chosen or assigned, MUST be stored in the dc:identifier element and be referenced as the Unique Identifier in the package element unique-identifier attribute.

Although not static, changes to the Unique Identifier for an EPUB Publication SHOULD be made as infrequently as possible. New identifiers SHOULD NOT be issued when updating metadata, fixing errata or making other minor changes to the EPUB Publication.

Reading Systems MUST NOT depend on the Unique Identifier being unique to one and only one EPUB Publication. Determining whether two EPUB Publications with the same Unique Identifier represent different versions of the same publication (see Release Identifier), or different publications, might require inspecting other metadata, such as the titles or authors.

4.1.2 Release Identifier

The Unique Identifier of an EPUB Publication typically SHOULD NOT change with each minor revision to the package or its contents, as Unique Identifiers are intended to have maximal persistence both for referencing and distribution purposes. Each release of an EPUB Publication normally requires that the new version be uniquely identifiable, however, which results in the contradictory need for reliable Unique Identifiers that are changeable.

To redress this problem of identifying minor modifications and releases without changing the Unique Identifier, this specification defines the semantics for a Release Identifier, or means of distinguishing and sequentially ordering EPUB Publications with the same Unique Identifier.

The Release Identifier is not an actual property in the package metadata section, but is a value that can be obtained from two other mandatory pieces of metadata: the Unique Identifier and the last modification date of the Rendition. When the taken together, the combined value represents a unique identity that can be used to distinguish any particular version of an EPUB Publication from another.

To ensure that a Release Identifier can be constructed, eachRendition MUST include exactly one [DCTERMS] modified property containing its last modification date. The value of this property MUST be an [XMLSCHEMA-2] dateTime conformant date of the form:

CCYY-MM-DDThh:mm:ssZ

The last modification date MUST be expressed in Coordinated Universal Time (UTC) and MUST be terminated by the "Z" (Zulu) time zone indicator.

Additional modified properties MAY be included in the package metadata, but they MUST have a different subject (i.e., they require a refines attribute that references an element or resource).

Although not a part of the package metadata, for referencing and other purposes all string representations of the identifier MUST be constructed using the at sign (@) as the separator (i.e., of the form "id@date"). Whitespace MUST NOT be included when concatenating the strings.

Note that it is possible that the separator character MAY occur in the Unique Identifier, as these identifiers MAY be any string value. The Release Identifier consequently MUST be split on the last instance of the at sign when decomposing it into its component parts.

The Release Identifier does not supersede the Unique Identifier, but represents the means by which different versions of the same EPUB Publication can be distinguished and identified in distribution channels and by Reading Systems. The sequential, chronological order inherent in the format of the timestamp also places EPUB Publications in order without requiring knowledge of the exact identifier that came before.

The Release Identifier consequently allows a set of EPUB Publications to be inspected to determine if they represent the same version of the same Publication, different versions of a single EPUB Publication, or any combination of differing and similar EPUB Publications.

Note

When an EPUB Container includes more than one Rendition of an EPUB Publication, updating the last modified date of the default rendition for each release — even if it has not been updated — will help ensure that the EPUB Publication does not appear to be the same version as an earlier release, as Reading Systems only have to process the default rendition.

4.2 Vocabulary Association Mechanisms

4.2.1 Introduction

This section is non-normative.

The property, properties, rel and scheme attributes use the property data type to represent terms from metadata vocabularies. Similar to a CURIE [RDFA-CORE], the property data type represents an IRI [RFC3987] in compact form and simplifies the authoring of metadata from standardized vocabularies.

A property value is an expression that consists of a prefix and a reference, where the prefix — whether literal or implied — is a shorthand mapping of an IRI that typically resolves to a term vocabulary. When the prefix is converted to its IRI representation and combined with the reference, the resulting IRI normally resolves to a fragment within that vocabulary that contains human- and/or machine-readable information about the term.

To assist Reading Systems in processing property values, this specification defines three mechanisms to establish the IRI a prefix maps to:

default vocabularies — define the mapping when a property value does not include a prefix;
reserved prefixes — these mappings are predefined (i.e., all Reading Systems recognize them) and can be used without having to be declared; and
the prefix attribute — a declarative means of creating new prefix mappings on the root package element.

4.2.2 Default Vocabularies

A default vocabulary is a vocabulary that does not require a prefix to be declared in order to use its terms, and whose terms MUST always be unprefixed.

As the Package Document has multiple unrelated uses for metadata terms, a single default vocabulary is not defined for all attributes. Instead, different default vocabularies are defined for use in attributes that accept a property data type as follows:

The Meta Properties Vocabulary is defined to be the default vocabulary for the meta property attribute.
If the attribute's value does not include a prefix, the following IRI [RFC3987] stem_MUST_ be used to generate the resulting IRI:http://idpf.org/epub/vocab/package/meta/#
The Metadata Link Vocabulary is defined to be the default vocabulary for the link rel and properties attributes.
If any of these attributes' values do not include a prefix, the following IRI [RFC3987] stem MUST be used to generate the resulting IRI for them:http://idpf.org/epub/vocab/package/link/#
The Manifest Properties Vocabulary is defined to be the default vocabulary for the item properties attribute.
If any of the attribute's values do not include a prefix, the following IRI [RFC3987] stem MUST be used to generate the resulting IRI for them:http://idpf.org/epub/vocab/package/item/#
The Spine Properties Vocabulary is defined to be the default vocabulary for the itemref properties attribute.
If any of the attribute's values do not include a prefix, the following IRI [RFC3987] stem MUST be used to generate the resulting IRI for them:http://idpf.org/epub/vocab/package/itemref/#

The IRIs associated with these vocabularies MUST NOT be assigned a prefix using the prefix attribute.

4.2.3 Reserved Prefixes

This specification reserves the following set of prefixes that Authors MAY use in package metadata without having to declare.

Warning

Although reserved prefixes are an authoring convenience, reliance on them can lead to interoperability issues. Validation tools will often reject new prefixes until the tools are updated, for example. Authors are strongly encouraged to declare all prefixes they use to avoid such issues.

Prefix	IRI
a11y	http://www.idpf.org/epub/vocab/package/a11y/#
dcterms	http://purl.org/dc/terms/
marc	http://id.loc.gov/vocabulary/
media	http://www.idpf.org/epub/vocab/overlays/#
onix	http://www.editeur.org/ONIX/book/codelists/current.html#
rendition	http://www.idpf.org/vocab/rendition/#
schema	http://schema.org/
xsd	http://www.w3.org/2001/XMLSchema#

Reading Systems MUST resolve all reserved prefixes used in Package Documents using their predefined URIs unless a local prefix is declared. Reserved prefixes SHOULD NOT be overridden in the prefix attribute, but Reading Systems MUST use such local overrides when encountered.

As changes to the reserved prefixes and updates to Reading Systems are not always going happen in synchrony, Reading Systems MUST NOT fail when encountering unrecognized prefixes (i.e., not reserved and not declared using the prefix attribute).

4.2.4 The `prefix` Attribute

The prefix attribute defines additional prefix mappings not reserved by this specification.

The value of the prefix attribute is a white space-separated list of one or more prefix-to-IRI mappings of the form:

(EBNF productions ISO/IEC 14977)All terminal symbols are in the Unicode Block 'Basic Latin' (U+0000 to U+007F). | prefixes | = | mapping , { whitespace, { whitespace } , mapping } ; | | | | | ------------------------------------- | -- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | --- | ------ | | | mapping | = | prefix , ":" , space , { space } , ? xsd:anyURI ? ; | | | | | prefix | = | ? xsd:NCName ? ; | | | | | space | = | #x20 ; | | | | | whitespace | = | (#x20 | #x9 | #xD | #xA) ; | |

To avoid conflicts, the prefix attribute MUST NOT be used to declare a prefix that maps to the default vocabulary. If theprefix attribute includes a declaration for a predefined prefix, Reading Systems MUST use the URI mapping defined in the prefix attribute, regardless of whether of it maps to the same URI as the predefined prefix.

The prefix '_' MUST NOT be declared as it is reserved for future compatibility with RDFa [RDFA-CORE] processing.

For future compatibility with alternative serializations of the Package Document, a prefix for the Dublin Core /elements/1.1/ namespace [DCTERMS] MUST NOT be declared in theprefix attribute. Authors MUST use only the [DC11] elements allowed in the Package Document metadata.

4.2.5 The `property` Data Type

4.2.5.1 Syntax

The property data type is a compact means of expressing an IRI [RFC3987] and consists of an OPTIONAL prefix separated from a reference by a colon.

(EBNF productions ISO/IEC 14977)All terminal symbols are in the Unicode Block 'Basic Latin' (U+0000 to U+007F).

property	=	[ prefix , ":" ] , reference;
prefix	=	? xsd:NCName ? ;
reference	=	? irelative-ref ? ;	/* as defined in [RFC3987] */

The property data type is derived from the CURIE data type defined in [RDFA-CORE], and represents a subset of CURIEs.

After processing, this property would expand to the following IRI:

http://purl.org/dc/terms/modified

as the dcterms: prefix is a reserved prefix that maps to the IRI "http://purl.org/dc/terms/".

When a prefix is omitted from a property value, the expressed reference represents a term from the default vocabulary for that attribute.

An empty string does not represent a valid property value, even though it is valid to the definition above.

4.2.5.2 Processing

A Reading System MUST use the following rules to create an IRI [RFC3987] from a property:

If the property consists only of a reference, the IRI is obtained by concatenating the IRI stem associated with the default vocabulary to the reference.
If the property consists of a prefix and reference, the IRI is obtained by concatenating the IRI stem associated with the prefix to the reference. If no matching prefix has been defined, the property is invalid and MUST be ignored.

The resulting IRI MUST be valid to [RFC3987]. Reading Systems do not have to resolve this IRI, however.

4.3 Package Rendering Metadata

4.3.1 Introduction

This section is non-normative.

Not all rendering information can be expressed through the underlying technologies that EPUB is built upon. For example, although HTML with CSS provides powerful layout capabilities, those capabilities are limited to the scope of the document being rendered.

This section defines general-purpose properties that allow Authors to express package-level rendering intentions (i.e., functionality that can only be implemented by the EPUB Reading System). If a Reading System supports the desired rendering, these properties enable the user to be presented the content as the Author optimally designed it.

4.3.2 Referencing

The base IRI for referencing these properties ishttp://www.idpf.org/vocab/rendition/#.

The "rendition:" prefix is reserved for use with the package rendering properties and does not have to be declared in the Package Document.

4.3.3 General Properties

4.3.3.1 The `rendition:flow` Property

The rendition:flow property specifies the Author preference for how Reading Systems should handle content overflow.

4.3.3.1.1 Usage

When the rendition:flow property is specified on a meta element, it indicates the Author's global preference for overflow content handling (i.e., for all spine items). Authors MAY indicate a preference for dynamic pagination or scrolling. For scrolled content, it is also possible to specify whether consecutive EPUB Content Documents are to be rendered as a continuous scrolling view or whether each is to be rendered separately (i.e., with a dynamic page break between each).

If a Reading System supports the specified rendering, it SHOULD use that method to handle overflow content, but MAY provide the option for users to override the requested rendering.

The default value auto MUST be assumed by Reading Systems as the global value if no meta element carrying this property occurs in the metadata section. Reading Systems MAY support only this default value.

If a Reading Systems supports the rendition:layout property, it MUST ignore the rendition:flow property when it has been set on a spine item that also specifies the rendition:layout value pre-paginated.

Note that when two reflowable EPUB Content Documents occur sequentially in the spine, the default rendering for their [HTML] body elements is consistent with the page-break-before property [CSSSnapshot] having been set toalways. In addition to using the rendition:flow property, Authors MAY override this behavior through an appropriate style sheet declaration, if the Reading System supports such overrides.

The rendition:flow property MUST NOT be declared more than once.

4.3.3.1.2 Allowed Values

The following values are defined for use with the rendition:flow property:

paginated

The Reading System SHOULD dynamically paginate all overflow content.

scrolled-continuous

The Reading System SHOULD render all Content Documents such that overflow content is scrollable, and the EPUB Publication represented by the givenRendition SHOULD be presented as one continuous scroll from spine item to spine item (except where locally overridden).

Note that Authors SHOULD NOT create publications in which different resources have different block flow directions, as continuous scrolled rendition in EPUB Reading Systems would be problematic.

scrolled-doc

The Reading System SHOULD render all Content Documents such that overflow content is scrollable, and each spine item SHOULD be presented as a separate scrollable document.

auto

The Author does not have a preference for overflow handling. The Reading System_MAY_ render overflow content using its default method or a user preference, whichever is applicable.

4.3.3.1.3 Spine Overrides

Authors MAY specify the following properties locally on spine itemref elements to override theglobal value for the given spine item:

flow-auto

Indicates no preference for overflow content handling by the Author.

flow-paginated

Indicates the Author preference is to dynamically paginate content overflow.

flow-scrolled-continuous

Indicates the Author preference is to provide a scrolled view for overflow content, and that consecutive spine items with this property are to be rendered as a continuous scroll.

flow-scrolled-doc

Indicates the Author preference is to provide a scrolled view for overflow content, and each spine item with this property is to be rendered as a separate scrollable document.

Only one of these overrides is allowed on any given spine item.

For the rendition:flow-scrolled-continuous property, the scroll direction is defined relative to the block flow direction of the root element of the XHTML Content Document referenced by the itemref element. The scroll direction is vertical if the block flow direction is downward (top-to-bottom). It is horizontal if the block flow direction of the root element is rightward (left-to-right) or leftward (right-to-left).

4.3.3.1.4 Examples

4.3.3.2 The `rendition:align-x-center` Property

The rendition:align-x-center property specifies that the given spine item should be centered horizontally in the viewport or spread.

When the rendition:align-x-center property is set on a spine item, it indicates that the rendered content SHOULD be centered horizontally within the Viewport or spread, as applicable. This property does not affect the rendering of the spine item, only the placement of the resulting content box.

For reflowable content, Reading Systems that support this property MUST center each virtual page.

This version of this specification does not define a default rendering behavior when this property is not supported or specified. Reading Systems MAY render spine items by their own design.

Note

This property was developed primarily to handle "Naka-Tobira (中扉)" (sectional title pages), in the absence of reliable centering control within the content rendering. As support for paged media evolves in CSS, however, this property is expected to be deprecated. Authors are encouraged to use CSS solutions when effective.

4.3.4 Fixed-Layout Properties

4.3.4.1 Introduction

This section is non-normative.

EPUB documents, unlike print books or PDF files, are designed to change. The content flows, or reflows, to fit the screen and to fit the needs of the user. As noted in Rendering and CSS "content presentation adapts to the user, rather than the user having to adapt to a particular presentation of content." [EPUB3Overview]

But this principle doesn’t work for all types of documents. Sometimes content and design are so intertwined they cannot be separated. Any change in appearance risks changing the meaning, or losing all meaning. Fixed-Layout Documents give Authors greater control over presentation when a reflowable EPUB is not suitable for the content.

This section defines a set of metadata properties to allow declarative expression of intended rendering behaviors of Fixed-Layout Documents in the context of EPUB 3.

Note

EPUB 3 affords multiple mechanisms for representing fixed-layout content. When fixed-layout content is necessary, the Author's choice of mechanism will depend on many factors including desired degree of precision, file size, accessibility, etc. This section does not attempt to dictate the Author's choice of mechanism.

4.3.4.2 The `rendition:layout` Property

The rendition:layout property specifies whether the given Rendition is reflowable or pre-paginated.

4.3.4.2.1 Usage

When the rendition:layout property is specified on a meta element, it indicates that the paginated or reflowable layout style applies globally for the Rendition (i.e., for all spine items).

The default value reflowable MUST be assumed by EPUB Reading Systems as the global value if no meta element carrying this property occurs in themetadata section.

When the rendition:layout property is set to pre-paginated, Reading Systems MUST NOT include space between the adjacent content slots when renderingSynthetic Spreads.

When the property is set to pre-paginated for a spine item, its content dimensions MUST be set as defined in Fixed Layouts [ContentDocs32].

The rendition:layout property MUST NOT be declared more than once.

4.3.4.2.2 Allowed Values

The following values are defined for use with the rendition:layout property:

reflowable

The given Rendition is not pre-paginated. Reading Systems MAY apply dynamic pagination when rendering.

pre-paginated

The given Rendition is pre-paginated. Reading Systems MUST produce exactly one page per spine itemref when rendering.

Note

Reading Systems typically restrict or deny the application of user or user agent style sheets to pre-paginated documents, since, as a result of intrinsic properties of such documents, dynamic style changes are highly likely to have unintended consequences. Authors need to take into account the negative impact on usability and accessibility that these restrictions have when choosing to use pre-paginated instead of reflowable content. Refer to Guideline 1.4 - Provide text configuration [UAAG20] for related information.

4.3.4.2.3 Spine Overrides

Authors MAY specify the following properties locally on spineitemref elements to override theglobal value for the given spine item:

layout-pre-paginated

Specifies that the given spine item is pre-paginated.

layout-reflowable

Specifies that the given spine item is reflowable.

Only one of these overrides is allowed on any given spine item.

4.3.4.2.4 Examples

4.3.4.3 The `rendition:orientation` Property

The rendition:orientation property specifies which orientation the Author intends the given Rendition to be rendered in.

4.3.4.3.1 Usage

When the rendition:orientation property is specified on ameta element, it indicates that the intended orientation applies globally for the given Rendition (i.e., for all spine items).

The default value auto MUST be assumed by Reading Systems as the global value if no meta element carrying this property occurs in themetadata section.

The rendition:orientation property MUST NOT be declared more than once.

4.3.4.3.2 Allowed Values

The following values are defined for use with the rendition:orientation property:

landscape

The given Rendition is intended for landscape rendering.

portrait

The given Rendition is intended for portrait rendering.

auto

The given Rendition is not orientation constrained.

Reading Systems that support multiple orientations SHOULD convey the intended orientation to the user, unless the given value is auto. The means by which the intent is conveyed is implementation-specific.

4.3.4.3.3 Spine Overrides

Authors MAY specify the following properties locally on spine itemref elements to override theglobal value for the given spine item:

orientation-auto

Specifies that the Reading System determines the orientation to render the spine item in.

orientation-landscape

Specifies that the given spine item is to be rendered in landscape orientation.

orientation-portrait

Specifies that the given spine item is to be rendered in portrait orientation.

Only one of these overrides is allowed on any given spine item.

4.3.4.3.4 Examples

4.3.4.4 The `rendition:spread` Property

The rendition:spread property specifies the intended Reading System synthetic spread behavior for the given Rendition.

4.3.4.4.1 Usage

When the rendition:spread property is specified on a meta element, it indicates that the intended Synthetic Spread behavior applies globally for the given Rendition (i.e., for all spine items).

The default value auto MUST be assumed by Reading Systems as the global value if no meta element carrying this property occurs in themetadata section.

The rendition:spread property MUST NOT be declared more than once.

4.3.4.4.2 Allowed Values

The following values are defined for use with the rendition:spread property:

none

Reading Systems MUST NOT incorporate spine items in a Synthetic Spread.

landscape

Reading Systems SHOULD render a Synthetic Spread for spine items only when the device is in landscape orientation.

portrait (deprecated)

The use of spreads only in portrait orientation is deprecated.

Authors are advised to use the value "both" instead, as spreads that are readable in portrait orientation are also readable in landscape. Reading Systems SHOULD treat the value "portrait" as a synonym of "both" and create spreads regardless of orientation.

both

Reading Systems SHOULD render a Synthetic Spread regardless of device orientation.

auto

No explicit Synthetic Spread behavior is defined. Reading Systems MAY use Synthetic Spreads in specific or all device orientations as part of a Content Display Area utilization optimization process.

Note

When Synthetic Spreads are used in the context of HTML and SVG Content Documents, the dimensions given via the viewport meta element [ContentDocs32] and viewBox attribute [ContentDocs32] represents the size of one page in the spread, respectively.

Note

Refer to spine for information about declaration of global flow directionality using the page-progression-direction attribute and that of local page-progression-direction within content documents.

4.3.4.4.3 Spine Overrides

Authors MAY specify the following properties locally on spineitemref elements to override theglobal value for the given spine item:

spread-auto

Specifies the Reading System determines when to render a synthetic spread for the spine item.

spread-both

Specifies the Reading System should render a synthetic spread for the spine item in both portrait and landscape orientations.

spread-landscape

Specifies the Reading System should render a synthetic spread for the spine item only when in landscape orientation.

spread-none

Specifies the Reading System should not render a synthetic spread for the spine item.

spread-portrait

The spread-portrait property is deprecated. Refer to its definition in [Publications301] for more information.

Only one of these overrides is allowed on any given spine item.

4.3.4.4.4 Examples

4.3.4.5 The `rendition:page-spread-*` Properties

4.3.4.5.1 Usage

When a Reading System renders a Synthetic Spread, the default behavior is to populate the spread by rendering the next EPUB Content Document in the next available unpopulated viewport, where the next available viewport is determined by the given page progression direction or by local declarations within Content Documents. An Author MAY override this automatic population behavior and forcing a document to be placed in a particular viewport by specifying one of the following properties on its spine itemref element:

rendition:page-spread-center

The rendition:page-spread-center property specifies the forced placement of a Content Document in a Synthetic Spread.

rendition:page-spread-left

The rendition:page-spread-left property is an alias for the [page-spread-left](#page-spread-left) property.

rendition:page-spread-right

The rendition:page-spread-right property is an alias for the [page-spread-right](#page-spread-right) property.

The rendition:page-spread-left property indicates that the given spine item_SHOULD_ be rendered in the left-hand slot in the spread, andrendition:page-spread-right that it SHOULD be rendered in the right-hand slot. The rendition:page-spread-center property indicates that the synthetic spread mode SHOULD be overridden and a single viewport rendered and positioned at the center of the screen.

The rendition:page-spread-left, rendition:page-spread-right andrendition:page-spread-center properties apply to both pre-paginated and reflowable content, and they only apply when the Reading System is creating Synthetic Spreads.

The rendition:page-spread-* properties take precedence over whatever value of the page-break-before property [CSSSnapshot] has been set for an XHTML Content Document.

Note

The presence of rendition:page-spread-center does not change the viewport dimensions. In particular, it does not indicate that a viewport with the size of the whole spread has to be created. This is important so that the scale factor stays consistent between regular and center-spread pages.

When a reflowable spine item follows a pre-paginated one, the reflowable one SHOULD start on the next page (as defined by the page-progression-direction) when it lacks arendition:page-spread-* property value. If the reflowable spine item has a rendition:page-spread-* specification, it MUST be honored (e.g., by inserting a blank page).

Similarly, when a pre-paginated spine item follows a reflowable one, the pre-paginated one SHOULD start on the next page (as defined by thepage-progression-direction) when it lacks arendition:page-spread-* property value. If the pre-paginated spine item has a rendition:page-spread-* specification, it MUST be honored (e.g., by inserting a blank page).

Although Authors often indicate to use a spread in certain device orientations, the content itself does not represent true spreads (i.e., two consecutive pages that have to be rendered side-by-side for readability, such as a two-page map). To indicate that two consecutive pages represent a true spread, Authors SHOULD use therendition:page-spread-left and rendition:page-spread-right properties on the spine items for the two adjacent EPUB Content Documents, and omit the properties on spine items where one-up or two-up presentation is equally acceptable. When a Reading System encounters two spine items that represent a true spread, it SHOULD create the spread with no space between the adjacent pages.

Only one page-spread-* property can be declared on any given spine item.

Note

The rendition:page-spread-left andrendition:page-spread-right properties are aliases for the page-spread-left and spread-right properties. They allow the use of a single vocabulary for all fixed-layout properties. Authors can use either property set, but older Reading Systems might only recognize the unprefixed versions. The EPUB Spine Properties Vocabulary is no longer being extended for package rendering metadata, so an unprefixed page-spread-center is not available.

4.3.4.5.2 Examples

4.3.4.6 The `rendition:viewport` Property (Deprecated)

The rendition:viewport property allows Authors to express the CSS initial containing block (ICB) [CSS21] for XHTML and SVG Content Documents whoserendition:layout property has been set to pre-paginated.

Use of the property is deprecated. Refer to its definition in [Publications301] for more information.

5.1 Introduction

This section is non-normative.

The EPUB Navigation Document is a mandatory component of an EPUB Package. It allows Authors to include a human- and machine-readable global navigation layer, thereby ensuring increased usability and accessibility for the user.

The EPUB Navigation Document is an XHTML Content Document, but with additional restrictions on its structure to facilitate the machine-processing of its contents. [HTML] nav elements contain the specialized navigational information, which remains human-readable as well as allowing Reading Systems to generate navigational interfaces.

But the EPUB Navigation Document is not exclusively for machine processing. Because it is an XHTML Content Document, it can be part of the linear reading order, avoiding the need for duplicate tables of contents. Content which is only destined for machine processing, such as page lists, can be hidden from visual rendering with the hidden attribute.

Note that Reading Systems might strip scripting, styling, and HTML formatting as they generate navigational interfaces from information found in the EPUB Navigation Document. If such formatting and functionality is needed, then the EPUB Navigation Document also needs to be included in thespine. The use of progressive enhancement [ContentDocs32] techniques for scripting and styling of the navigation document will help ensure the content will retain its integrity when rendered in a non-browser context.

5.2 Content Conformance

A conformant EPUB Navigation Document MUST meet all of the following criteria:

Document Properties

It MUST conform to the content conformance constraints for XHTML Content Documents defined in XHTML Content Documents — Content Conformance [ContentDocs32].

It MUST conform to the content conformance constraints specific to EPUB Navigation Documents defined in EPUB Navigation Document Definition.

As a conforming XHTML Content Document, it MAY be included in the spine.

5.3 Reading System Conformance

A conformant EPUB Reading System MUST meet all of the following criteria for processingEPUB Navigation Documents:

When requested by a user, it MUST provide access to the links and link labels in the nav elements of the EPUB Navigation Document in a fashion that allows the user to activate the links.
When a link is activated, it MUST relocate the application's current reading position to the destination identified by that link.
It MUST honor the above requirements irrespective of whether the EPUB Navigation Document is part of the spine.

5.4.1 The `nav` Element: Restrictions

When a nav element carries the epub:type attribute [ContentDocs32] in an EPUB Navigation Document, this specification restricts the content model of the element and its descendants as follows:

Content Model

nav

In this order:

HTML Heading content [0 or 1]
ol [exactly 1]

In this order:

li [1 or more]

In this order:

(span or a) [exactly 1]
ol [conditionally required]

span and a

In any order:

HTML Phrasing content [1 or more]

Note that there are no restrictions on the attributes allowed on these elements.

Refer the definition below for additional requirements.

The content model of the nav element is interpreted as follows:

The ol child of the nav element represents the primary level of content navigation.
Each list item of the ordered list represents a heading, structure or other item of interest. A child a element describes the target that the link points to, while a span element serves as a heading for breaking down lists into distinct groups (for example, a large list of illustrations can be segmented into several lists, one for each chapter).
The child a or span element MUST provide a non zero-length text label after concatenation of all child content and application of white space normalization rules. Although non-textual descendant elements MAY be rendered directly to users, text content included in title oralt attributes MUST be used when determining compliance with this requirement.
If an a or span element contains instances of HTML embedded content that do not provide intrinsic text alternatives, the element_MUST_ also include a title attribute with an alternate text rendering of the link label.
The IRI reference provided in the href attribute of the a element MUST adhere to the following requirements:
- In the case of the toc nav, landmarks nav and page-list nav, it MUST resolve to an Top-level Content Document or fragment therein.
- For all other nav types, it MAY also reference Remote Resources.
An a element MAY be followed by an ol ordered list representing a subsidiary content level below that heading (e.g., all the subsection headings of a section).
A span element MUST be followed by anol ordered list; it cannot be used in "leaf" li elements.
Regardless of whether an a or span element precedes it, every sublist MUST adhere to the content requirements defined in this section for constructing the primary navigation list.

EPUB specifications MAY introduce further restrictions on the content model defined above fornav elements in the EPUB Navigation Document.

In the context of this specification, the default display style of list items within nav elements MUST be equivalent to the list-style: none property [CSSSnapshot]. Reading Systems MUST NOT show list item numbering on these lists when presenting the Navigation Document outside of the spine, regardless of their support for CSS. Authors MAY specify alternative list styling using CSS for rendering of the document in the spine.

5.4.2 The `nav` Element: Types

5.4.2.1 Introduction

This section is non-normative.

The nav elements defined in an EPUB Navigation Document are distinguished semantically by the value of their epub:type attribute [ContentDocs32].

This specification defines three types of navigation aid:

toc

Identifies the nav element that contains the table of contents. Thetoc nav is the only navigation aid that has to be included in the EPUB Navigation Document.

page-list

Identifies the nav element that contains a list of pages for a print or other statically-paginated source for the EPUB Publication.

landmarks

Identifies the nav element that contains a list of points of interest.

Additional navigation types can be included in the EPUB Navigation Document. See Other nav Elements for more information.

5.4.2.2 The `toc nav` Element

The toc nav element defines the primary navigational hierarchy of the givenRendition. It conceptually corresponds to a table of contents in a printed work (i.e., it provides navigation to the major structural sections of the publication).

The references in the toc nav element MUST be ordered such that they reflect both:

the order of the referenced EPUB Content Documents in the spine;
the order of the targeted elements within their respective EPUB Content Documents.

The toc nav element MUST occur exactly once in an EPUB Navigation Document.

5.4.2.3 The `page-list nav` Element

The page-list nav element provides navigation to positions in the content that correspond to the locations of page boundaries present in a print source being represented by the EPUB Publication.

The page-list nav element is OPTIONAL in EPUB Navigation Documents and MUST NOT occur more than once.

The page references within the page-list nav MUST be ordered so that they match both the order of the targeted EPUB Content Documents in the spine and the order of each page within its respective EPUB Content Document.

The page-list nav element SHOULD contain only a single ol descendant (i.e., no nested sublists).

The destinations of the page-list references MAY be identified in their respective EPUB Content Documents using the pagebreak term [EPUB-SSV].

5.4.2.4 The `landmarks nav` Element

The landmarks nav element identifies fundamental structural components in the givenRendition in order to enable Reading Systems to provide the user efficient access to them.

The epub:type attribute [ContentDocs32] is REQUIRED on a element descendants of the landmarks nav element. The structural semantics of each link target within thelandmarks nav element is determined by the value of this attribute.

The landmarks nav MUST NOT include multiple entries with the same epub:type value that reference the same resource, or fragment thereof.

The landmarks nav element is OPTIONAL in EPUB Navigation Documents and MUST NOT occur more than once.

5.4.2.5 Other `nav` Elements

EPUB Navigation Documents MAY include one or more nav elements in addition to the toc, page-list and landmarks nav elements defined in the preceding sections. These additionalnav elements SHOULD have an epub:type attribute to provide a machine-readable semantic, and MUST have a human-readable heading as their first child.

This specification imposes no restrictions on the semantics of any additionalnav elements: they MAY be used to represent navigational semantics for any information domain, and they MAY contain link targets with homogeneous or heterogeneous semantics.

5.4.3 The `hidden` attribute

In some cases, Authors might wish to hide parts of the navigation data within the content flow (i.e., the Reading System's principal rendering of the spine contents). A typical example is the list of page breaks, which usually is not rendered as part of the content flow but is instead exposed to the user separately in a dedicated navigation user interface.

While the display property [CSSSnapshot] can be used to control the visual rendering of EPUB Navigation Documents in Reading Systems with Viewports, not all Reading Systems provide such an interface. To control rendering across all Reading Systems, authors MUST use the [HTML] hidden attribute to indicate which (if any) portions of the navigation data are excluded from rendering in the content flow. The hidden attribute has no effect on how navigation data is rendered outside of the content flow (such as in dedicated navigation user interfaces provided by Reading Systems).

A. Package Document Schema

A non-normative schema for Package Documents is available at https://github.com/w3c/epubcheck/tree/master/src/main/resources/com/adobe/epubcheck/schema/30/package-30.nvdl.

Validation using this schema requires a processor that supports [NVDL], [RelaxNG-Schema], [ISOSchematron] and [XMLSCHEMA-2].

Note

The NVDL schema layer can be substituted by a multi-pass validation using the embedded RELAX NG and ISO Schematron schemas alone.

Note

These schemas may be updated and corrected outside of formal revisions of this specification. As a result, they are subject to change at any time.

This section is non-normative.

This appendix registers the media type application/oebps-package+xml for the EPUB Package Document. This registration supersedes [RFC4839].

The Package Document is an XML file that describes a Rendition of an EPUB Publication. It identifies the resources in the Rendition and provides metadata information. The Package Document and its related specifications are maintained and defined by the W3C’s EPUB 3 Community Group.

MIME media type name:

application

MIME subtype name:

oebps-package+xml

Required parameters:

None.

Optional parameters:

None.

Encoding considerations:

Package Documents are UTF-8 or UTF-16 encoded XML.

Security considerations:

Package Documents contain well-formed XML conforming to the XML 1.0 specification.

Clearly, it is possible to author malicious files which, for example, contain malformed data. Most XML parsers protect themselves from such attacks by rigorously enforcing conformance.

All processors that read Package Documents should rigorously check the size and validity of data retrieved.

There is no current provision in the EPUB Packages 3.2 specification for encryption, signing, or authentication within the Package Document format.

Interoperability considerations:

None.

Published specification:

This media type registration is for the EPUB Package Document, as described by the EPUB Packages 3.2 specification located at http://w3c.github.io/publ-epub-revision/epub32/spec/epub-packages.html.

The EPUB Packages 3.2 specification supersedes the Open Packaging Format 2.0.1 specification, which is located at http://www.idpf.org/epub/20/spec/OPF_2.0.1_draft.htm and which also uses the application/oepbs-package+xml media type.

Applications which use this media type:

This media type is in wide use for the distribution of ebooks in the EPUB format. The following list of applications is not exhaustive.

Adobe Digital Editions
Aldiko
Azardi
Apple iBooks
Barnes & Noble Nook
Bluefire Reader
Calibre
Google Play Books
Kobo
Microsoft Edge
Readium

Additional information:

Magic number(s):

none

File extension(s):

.opf

Macintosh File Type Code(s):

TEXT

Fragment Identifiers:

A registry of linking schemes is maintained at http://www.idpf.org/epub/linking/. Some of these schemes define custom fragment identifiers that resolve toapplication/oebps-package+xml documents.

Person & email address to contact for further information:

public-epub3@w3.org

Intended usage:

COMMON

Author/Change controller:

The published specification is a work product of the World Wide Web Consortium’s EPUB 3 Community Group. W3C has change control over this specification.

C.1 Overview

C.1.1 About this Vocabulary

This section is non-normative.

The properties in this vocabulary are usable in the meta element's property attribute.

C.1.2 Referencing

Properties without a prefix are referenceable using the base IRIhttp://idpf.org/epub/vocab/package/meta/#.

C.2 Metadata `meta` Properties

The following tables define properties for use in the meta element's property attribute.

Unless indicated otherwise in its “Extends” field, the properties defined in this section are used to definesubexpressions: in other words, a [meta](#elemdef-meta) element carrying a property defined in this section MUST have a [refines](#attrdef-refines) attribute referencing a resource or expression being augmented.

In each property definition, the Allowed values field indicates the expected type of value (using [XMLSCHEMA-2] datatypes), the Cardinality field indicates the number of times the property MAY be attached to another property, and the Extends field identifies the properties it MAY be attached to.

C.2.1 alternate-script

Name:	alternate-script
Description:	The alternate-script property provides an alternate expression of the associated property value in a language and script identified by thexml:lang attribute. This property is typically attached to creator and title properties for internationalization purposes.
Allowed value(s):	xsd:string
Cardinality:	zero or more
Extends:	All properties.

C.2.2 authority

Name:	authority
Description:	The authority property identifies the system or scheme the referenced element's value is drawn from.
Allowed value(s):	a reserved authority value [AuthorityRegistry] (case-insensitive); or an absolute IRI [RFC3987] that identifies the scheme. The IRI SHOULD refer to a resource that provides more information about the scheme.
Cardinality:	zero or one
Extends:	subject

C.2.3 belongs-to-collection

Name:	belongs-to-collection
Description:	The belongs-to-collection property identifies the name of a collection to which the EPUB Publication belongs. An EPUB Publication MAY belong to one or more collections. It is also possible chain these properties using the refines attribute to indicate that one collection is itself a member of another collection. To allow Reading System to organize collections and avoid naming collisions (e.g., unrelated collections might share a similar name, or different editions of a collection could be released), an identifier SHOULD be provided that uniquely identifies the instance of the collection. The dcterms:identifier property must carry this identifier. The collection MAY more precisely define its nature by attaching a collection-type property. The position of the EPUB Publication within the collection MAY be provided by attaching agroup-position property.
Allowed value(s):	xsd:string
Cardinality:	zero or more
Extends:	Applies to the EPUB Publication, and can refine other instances of itself.

C.2.4 collection-type

Name:	collection-type
Description:	The collection-type property indicates the form or nature of a collection. When the collection-type value is drawn from a code list or other formal enumeration, the scheme attribute SHOULD be attached to identify its source. When a scheme is not specified, Reading Systems SHOULD recognize the following collection type values: series A sequence of related works that are formally identified as a group; typically open-ended with works issued individually over time. set A finite collection of works that together constitute a single intellectual unit; typically issued together and able to be sold as a unit.
Allowed value(s):	xsd:string
Cardinality:	zero or one
Extends:	belongs-to-collection

C.2.5 display-seq

Name:	display-seq
Description:	The display-seq property indicates the numeric position in which to display the current property relative to identical metadata properties. This property only applies where precedence rules have not already been defined (e.g., precedence is given to creators based on their appearance in document order).
Allowed value(s):	xsd:unsignedInt
Cardinality:	zero or one
Extends:	All properties.

C.2.6 file-as

Name:	file-as
Description:	The file-as property provides the normalized form of the associated property for sorting.
Allowed value(s):	xsd:string
Cardinality:	zero or one
Extends:	All properties.

C.2.7 group-position

Name:	group-position
Description:	The group-position property indicates the numeric position in which the EPUB Publication is ordered relative to other works belonging to the same group (whether all EPUB Publications or not). The group-position property can be attached to any metadata property that establishes the group, but is typically associated with the belongs-to-collection property. An EPUB Publication can belong to more than one group.
Allowed value(s):	A single xsd:unsignedInt or series of decimal-separated numbers (e.g.,1 or 2.2.1).
Cardinality:	zero or one
Extends:	All properties.

C.2.8 identifier-type

Name:	identifier-type
Description:	The identifier-type property indicates the form or nature of anidentifier. When the identifier-type value is drawn from a code list or other formal enumeration, the scheme attribute SHOULD be attached to identify its source.
Allowed value(s):	xsd:string
Cardinality:	zero or one
Extends:	identifier, source

C.2.9 meta-auth (Deprecated)

Name:	meta-auth
Description:	The meta-auth property identifies the party or authority responsible for an instance of package metadata. Use of the meta-auth property is deprecated.
Allowed value(s):	xsd:string
Cardinality:	zero or one
Extends:	All properties.

C.2.10 role

Name:	role
Description:	The role property describes the nature of work performed by acreator or contributor (e.g., that the person is the author or editor of a work). When the role value is drawn from a code list or other formal enumeration, the scheme attribute SHOULD be attached to identify its source.
Allowed value(s):	xsd:string
Cardinality:	zero or one
Extends:	contributor, creator

C.2.11 source-of

Name:	source-of
Description:	The source-of property indicates a unique aspect of an adapted source resource that has been retained in the given Rendition of the EPUB Publication. This specification defines the pagination value to indicate that the referenced dc:source element is the source of the pagebreak properties defined in the content.
Allowed value(s):	pagination
Cardinality:	zero or one
Extends:	dc:source

Note

See [EPUBAccessibilityTechniques] for information on how to provide accessible page navigation.

C.2.12 term

Name:	term
Description:	The term property provides a subject code.
Allowed value(s):	xsd:string
Cardinality:	zero or one
Extends:	subject

C.2.13 title-type

Name:	title-type
Description:	The title-type property indicates the form or nature of atitle. When the title-type value is drawn from a code list or other formal enumeration, the scheme attribute SHOULD be attached to identify its source. When a scheme is not specified, Reading Systems should recognize the following title type values:main, subtitle, short,collection, edition andexpanded.
Allowed value(s):	xsd:string
Cardinality:	zero or one
Extends:	title

C.2.14 Examples

D.1 Overview

D.1.1 About this Vocabulary

This section is non-normative.

The properties in this vocabulary are usable in the metadata link element's rel and properties attributes.

D.1.2 Referencing

Link properties without a prefix are referenceable using the base IRIhttp://idpf.org/epub/vocab/package/link/#.

D.2 Link Relationships

The following values can be used in the link element rel attribute to establish the relationship of the resource referenced in the href attribute.

D.2.1 acquire

Name:	acquire
Description:	The acquire keyword is used with EPUB Previews to identify where the full version of the EPUB Publication can be acquired.
Cardinality:	Zero or more
Extends:	Only applies to the EPUB Publication or collection. MUST NOT be used when the refines attribute is present.
Example:

D.2.2 alternate

Name:	alternate
Description:	The alternate keyword is a subset of the HTMLalternate keyword for links. It differs as follows: It cannot be paired with other keywords. If an alternate link is included in the Package Document metadata, it identifies an alternate representation of the Package Document in the format specified in themedia-type attribute. If an alternate link is included in a collection element's metadata [Packages], it identifies an alternate representation of the collection in the format specified in the media-type attribute. Reading Systems do not have to generate hyperlinks for alternate links.
Cardinality:	Zero or more
Extends:	Only applies to the EPUB Publication or collection. MUST NOT be used when the refines attribute is present.
Example:

D.2.3 marc21xml-record (Deprecated)

Name:	marc21xml-record
Description:	Use of the marc21xml-record keyword is deprecated. It is replaced by the record keyword with the media-type attribute [Packages] value "application/marcxml+xml".
Cardinality:	Zero or one
Extends:	Only applies to the EPUB Publication or collection. MUST NOT be used when the refines attribute is present.
Example:

D.2.4 mods-record (Deprecated)

Name:	mods-record
Description:	Use of the mods-record keyword is deprecated. It is replaced by the record keyword with the media-type attribute [Packages] value "application/mods+xml".
Cardinality:	Zero or one
Extends:	Only applies to the EPUB Publication or collection. MUST NOT be used when the refines attribute is present.
Example:

D.2.5 onix-record (Deprecated)

Name:	onix-record
Description:	Use of the onix-record keyword is deprecated. It is replaced by the record keyword with the properties attribute [Packages] value onix.
Cardinality:	Zero or one
Extends:	Only applies to the EPUB Publication or collection. MUST NOT be used when the refines attribute is present.
Example:

D.2.6 record

Name:	record
Description:	Indicates that the referenced resource is a metadata record. The media type of the record is identified in the media-type attribute [Packages] when this keyword is specified. For a list of commonly-linked metadata record types, refer to the EPUB Linked Metadata Guide If the type of record cannot be identified from the media type, an identifier property can be assigned in the properties attribute [Packages].
Cardinality:	Zero or more
Extends:	Only applies to the EPUB Publication or collection. MUST NOT be used when the refines attribute is present.
Example:

D.2.7 voicing

Name:	voicing
Description:	Indicates that the referenced audio file provides an aural representation of the expression or resource (typically, the title or creator) specified by the refines attribute. The media type of the audio file is identified in the media-type attribute [Packages] when this keyword is specified.
Cardinality:	Zero or more
Extends:	All properties. The refines attribute MUST be present when this value is used.
Example:

D.2.8 xml-signature (Deprecated)

Name:	xml-signature
Description:	Use of the xml-signature keyword is deprecated. It is not replaced by another linking method. Identification of XML signatures will be addressed in a future version of EPUB.
Cardinality:	Zero or more
Extends:	All properties.
Example:

D.2.9 xmp-record (Deprecated)

Name:	xmp-record
Description:	Use of the xmp-record keyword is deprecated. It is replaced by the record keyword with the properties attribute value xmp.
Cardinality:	Zero or one
Extends:	Only applies to the EPUB Publication or collection. MUST NOT be used when the refines attribute is present.
Example:

D.3 Link Properties

The following values can be used in the link element's properties attribute to establish the type of record a referenced resource represents. These values are provided for record formats that cannot be uniquely identified by their media type.

D.3.1 onix

Name:	onix
Description:	The onix property indicates the referenced resource is an ONIX record [ONIX].
Example:

D.3.2 xmp

Name:	xmp
Description:	The xmp property indicates the referenced resource is an XMP record [XMP].
Example:

E. Manifest Properties Vocabulary

E.1 Overview

E.1.1 About this Vocabulary

This section is non-normative.

The properties in this vocabulary are usable in the manifest item element's properties attribute.

E.1.2 Referencing

Properties without a prefix are referenceable using the base IRIhttp://idpf.org/epub/vocab/package/item/#.

E.2 Manifest `item` Properties

The following tables define properties for use in the manifest item element properties attribute.

The Applies to field indicates which Publication Resource type(s) the given property MAY be specified on, the Cardinality field indicates the number of times the property MUST appear within the Package Document scope, and the Usage field indicates usage conditions.

E.2.1 cover-image

Name:	cover-image
Description:	The cover-image property identifies the described Publication Resource as the cover image for the Publication.
Applies to:	All raster and vector image types [EPUB32]
Cardinality:	Zero or one
Usage:	Optional.

E.2.2 mathml

Name:	mathml
Description:	The mathml property indicates that the described Publication Resource contains one or more instances of MathML markup.
Applies to:	EPUB Content Documents
Cardinality:	Zero or more
Usage:	MUST be set if and only if the criterion specified in the description is met.

E.2.3 nav

Name:	nav
Description:	The nav property indicates that the described Publication Resource constitutes the EPUB Navigation Document of the given Rendition.
Applies to:	The EPUB Navigation Document
Cardinality:	Exactly one
Usage:	Required.

E.2.4 remote-resources

Name:	remote-resources
Description:	The remote-resources property indicates that the described Publication Resource contains one or more internal references to other Publication Resources that are located outside of the EPUB Container. Refer to Publication Resource Locations [EPUB32] for more information.
Applies to:	All Publication Resources with the capability of internal referencing (e.g., XHTML Content Documents, SVG Content Documents, CSS Style Sheets and Media Overlay Documents).
Cardinality:	Zero or more
Usage:	MUST be set if and only if the criterion specified in the description is met.

E.2.5 scripted

Name:	scripted
Description:	The scripted property indicates that the described Publication Resource is a Scripted Content Document (i.e., contains scripted content and/or HTML form elements).
Applies to:	EPUB Content Documents
Cardinality:	Zero or more
Usage:	MUST be set if and only if the criterion specified in the description is met.

E.2.6 svg

Name:	svg
Description:	The svg property indicates that the described Publication Resource embeds one or more instances of SVG markup. This property MUST be set when SVG markup is included directly in the resource and MAY be set when the SVG is referenced from the resource (e.g., from an [HTML]img, object or iframe element).
Applies to:	XHTML Content Documents; the value is implied for SVG Content Documents.
Cardinality:	Zero or more
Usage:	MUST be set if and only if the criterion specified in the description is met.

E.2.7 Usage

The mathml, remote-resources and scripted properties MUST be specified whenever the resource referenced by an item matches their respective definitions. These properties do not apply recursively to content included into a resource (e.g., via the HTMLiframe element). For example, if a non-scripted XHTML Content Document embeds a scripted Content Document, only the embedded document's manifest item properties attribute will have the scripted value.

E.2.8 Examples

Figure 1 The following example shows a manifest item element that represents the EPUB Navigation Document.

<item properties="nav" id="c1" href="c1.xhtml" media-type="application/xhtml+xml" />

Figure 2 The following example shows a manifest item element that represents the cover image.

<item properties="cover-image" id="ci" href="cover.svg" media-type="image/svg+xml" />

Figure 3 The following example shows a manifest item element representing a Scripted Content Document that also contains embedded MathML.

<item properties="scripted mathml" id="c2" href="c2.xhtml" media-type="application/xhtml+xml" />

F. Spine Properties Vocabulary

F.1 Overview

F.1.1 About this Vocabulary

This section is non-normative.

The properties in this vocabulary are usable in the spine itemref element's properties attribute.

F.1.2 Referencing

Properties are referenceable using the base IRIhttp://idpf.org/epub/vocab/package/itemref/#.

F.2 Spine `itemref` Properties

The following tables define properties for use in the itemref element properties attribute [Packages].

F.2.1 page-spread-left

Name:	page-spread-left
Description:	The page-spread-left property indicates that the first page of the associateditem element's EPUB Content Document represents the left-hand side of a two-page spread.

F.2.2 page-spread-right

Name:	page-spread-right
Description:	The page-spread-right property indicates that the first page of the associateditem element's EPUB Content Document represents the right-hand side of a two-page spread.

F.2.3 Examples

Figure 4 The following example shows how a two-page spread of a map might be indicated in thespine.

<spine>
    <itemref idref="title"/>
    <itemref idref="ps-1-l" properties="page-spread-left"/>
    <itemref idref="ps-1-r" properties="page-spread-right"/>
    <itemref idref="toc"/>
    …
</spine>

G. Acknowledgements and Contributors

This section is non-normative.

EPUB 3 is developed by the W3C's EPUB 3 Community Group in coordination with the Publishing Business Group.

The EPUB 3.2 revision was led by:

Rachel Comerford (Macmillan Higher Education), Chair
Dave Cramer (Hachette Livre), Chair

In addition to the editors, this version of EPUB would not have been possible without significant contributions from:

Aaron Troia
Adam Sobieski
Alberto Pettarin
Andrew Gribben (Houghton Mifflin Harcourt)
Avneesh Singh (DAISY Consortium)
Ben Walters (Microsoft)
Benjamin Young (Wiley)
Bill Kasdorf (BISG)
Brady Duga (Google)
Carlos Araya
Charles LaPierre (Benetech)
Daniel Glazman (Disruptive Innovations)
Daniel Weck (DAISY Consortium)
David Herron
Deborah Kaplan
Evan Owens (Cenveo Publisher Services)
Franco Alvarado
Garth Conboy (Google)
Georg Stadler
George Kersher (DAISY Consortium)
Greg Alchin
Hadrien Gardeur (Feedbooks)
Iris Febres
Ivan Herman (W3C)
James Briano
Jeff Buehler
Johan van der Knijff
John Costa (Repub Interactive Technologies LLC)
Julian Calderazi (DigitalBe)
Ken Jones (Circular Software)
Krzysztof Zemczak
Laura Brady
Laurent Le Meur (EDRLab)
Léonie Watson (Paciello Group)
Lloyd Rasmussen (Library of Congress)
Luc Audrain (Hachette Livre)
Makoto Murata (Keio Advanced Publishing Laboratory)
Martin Kraetke (le-tex publishing services GmbH)
Mateus Manço Teixeira (W. W. Norton)
Matt Curtis
Matt Garrish (DAISY Consortium)
Mike Baker (Houghton Mifflin Harcourt)
Mustapha Lazrek (Microsoft)
N. Erhan Uzumcu
Naomi Kennedy (Penguin Random House)
Nick Ruffilo (VitalSource)
Olaf Hoffmann
Peter Krautzberger (krautzource UG)
Rachel Comerford (Macmillan Higher Education)
Ric Wright
Rick Johnson (VitalSource)
Romain Deltour (DAISY Consortium)
Ruth Tait
Theresa O’Connor (Apple)
Tobias Fischer
Toshiaki Koike (Voyager Japan Inc.)
Tzviya Siegman (Wiley)
Wolfgang Schindler (PONS GmbH)
Zheng (Jeff) Xu (Rakuten Inc.)

Special thanks go to the former members of the International Digital Publishing Forum, particularly Markus Gylling and Bill McCoy, without whom EPUB would not have become a reality.

H. References

H.1 Normative references

[AuthorityRegistry]

EPUB Subject Authorities Registry. URL: https://www.idpf.org/epub/registries/authorities/

[BCP47]

Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47

[ContentDocs32]

EPUB Content Documents 3.2. URL: <epub-contentdocs.html>

[CSS21]

Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. Bert Bos; Tantek Çelik; Ian Hickson; Håkon Wium Lie et al. W3C. 7 June 2011. W3C Recommendation. URL: https://www.w3.org/TR/CSS2/

[CSSSnapshot]

CSS Snapshot. URL: https://www.w3.org/TR/CSS/

[DateTime]

Date and Time Formats. W3C. 27 August 1998. W3C Note. URL: https://www.w3.org/TR/NOTE-datetime

[DC11]

Dublin Core Metadata Element Set, Version 1.1. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dces/

[DCTERMS]

DCMI Metadata Terms. DCMI Usage Board. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dcmi-terms/

[EPUB-SSV]

EPUB Structural Semantics Vocabulary. IDPF. URL: http://www.idpf.org/epub/vocab/structure/

[EPUB32]

EPUB 3.2. URL: <epub-spec.html>

[HTML]

HTML. W3C. W3C Recommendation. URL: https://www.w3.org/TR/html/

[ISO8601]

Representation of dates and times. ISO 8601:2004.. International Organization for Standardization (ISO). 2004. ISO 8601:2004. URL: http://www.iso.org/iso/catalogue_detail?csnumber=40874

[ISOSchematron]

ISO/IEC 19757-3: Rule-based validation — Schematron. 2006-06-01. URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip

[JSON-LD]

JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/

[MediaOverlays32]

EPUB Media Overlays 3.2. URL: <epub-mediaoverlays.html>

[NVDL]

ISO/IEC 19757-4: NVDL (Namespace-based Validation Dispatching Language). 2006-06-01. URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c038615_ISO_IEC_19757-4_2006(E).zip

[OCF32]

Open Container Format (OCF) 3.2. URL: <epub-ocf.html>

[ONIX]

ONIX for Books. URL: http://www.editeur.org/

[OPF2]

Open Packaging Format 2.0.1. URL: http://www.idpf.org/epub/20/spec/OPF_2.0.1_draft.htm

[Packages]

EPUB Packages 3. URL: http://www.idpf.org/epub3/latest/packages

[Publications301]

EPUB Publications 3.0.1. URL: http://www.idpf.org/epub/301/spec/epub-publications.html

[RDFA-CORE]

RDFa Core 1.1 - Third Edition. Ben Adida; Mark Birbeck; Shane McCarron; Ivan Herman et al. W3C. 17 March 2015. W3C Recommendation. URL: https://www.w3.org/TR/rdfa-core/

[RelaxNG-Schema]

Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG. ISO/IEC. 2008. URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip

[RFC2046]

Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed; N. Borenstein. IETF. November 1996. Draft Standard. URL: https://tools.ietf.org/html/rfc2046

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

[RFC3987]

Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987

[RFC4839]

Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF). G. Conboy; J. Rivlin; J. Ferraiolo. IETF. April 2007. Informational. URL: https://tools.ietf.org/html/rfc4839

[RoleRegistry]

EPUB Collection Roles Registry. URL: http://www.idpf.org/epub/registries/roles

[TypesRegistry]

EPUB Publication Types Registry. URL: http://www.idpf.org/epub/vocab/package/types

[Unicode]

The Unicode Standard. Unicode Consortium. URL: https://www.unicode.org/versions/latest/

[XML]

Extensible Markup Language (XML) 1.0 (Fifth Edition). Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau et al. W3C. 26 November 2008. W3C Recommendation. URL: https://www.w3.org/TR/xml/

[XML-NAMES]

Namespaces in XML 1.0 (Third Edition). Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson et al. W3C. 8 December 2009. W3C Recommendation. URL: https://www.w3.org/TR/xml-names/

[XMLSCHEMA-2]

XML Schema Part 2: Datatypes Second Edition. Paul V. Biron; Ashok Malhotra. W3C. 28 October 2004. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema-2/

[XMP]

Extensible metadata platform (XMP) specification -- Part 1. Adobe Systems Incorporated. ISO/IEC. 15 February 2012. URL: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=57421

H.2 Informative references

[CSS3-MediaQueries]

Media Queries. Florian Rivoal et al. W3C. 19 June 2012. W3C Recommendation. URL: https://www.w3.org/TR/css3-mediaqueries/

[EPUB32Changes]

EPUB 3.2 Changes. URL: <epub-changes.html>

[EPUB3Overview]

EPUB 3 Overview. URL: <epub-overview.html>

[EPUBAccessibility]

EPUB Accessibility. URL: http://www.idpf.org/epub/latest/accessibility

[EPUBAccessibilityTechniques]

EPUB Accessibility Techniques. URL: http://www.idpf.org/epub/latest/accessibility/techniques

[RoleExtensions]

EPUB Collection Element Role Extensions. URL: http://www.idpf.org/epub/extensions/roles

[UAAG20]

User Agent Accessibility Guidelines (UAAG) 2.0. James Allan; Greg Lowney; Kimberly Patch; Jeanne F Spellman. W3C. 15 December 2015. W3C Note. URL: https://www.w3.org/TR/UAAG20/

EPUB Packages 3.2 (original) (raw)

Abstract

Status of This Document

Table of Contents

1. Introduction

1.1 Terminology

1.2 Conformance

1.3 Prefix Mappings

2. Conformance

2.1 Package Conformance

2.2 Reading System Conformance

3. Package Document

3.1 Introduction

3.2 Content Conformance

3.3 Reading System Conformance

3.4 Package Document Definition

3.4.1 The package Element

3.4.2 Shared Attributes

3.4.3 Metadata

3.4.3.1 The metadata Element

3.4.3.2 DCMES Required Elements

3.4.3.2.1 The identifier Element

3.4.3.2.2 The title Element

3.4.3.2.3 The language Element

3.4.3.3 DCMES Optional Elements

3.4.3.3.1 General Definition

3.4.3.3.2 The contributor Element

3.4.3.3.3 The creator Element

3.4.3.3.4 The date Element

3.4.3.3.5 The subject Element

3.4.3.3.6 The type Element

3.4.3.4 The meta Element

3.4.3.5 The link Element

3.4.4 Manifest

3.4.4.1 The manifest Element

3.4.4.2 The item Element

Examples

3.4.4.3 Manifest Fallbacks

3.4.4.4 The bindings Element (Deprecated)

3.4.5 Spine

3.4.5.1 The spine Element

3.4.5.2 The itemref Element

Examples

3.4.6 Collections

3.4.6.1 The collection Element

Examples

3.4.7 Legacy

3.4.7.1 The meta Element

3.4.7.2 The guide Element

3.4.7.3 NCX

4.1 Publication Identifiers

4.1.1 Unique Identifier

4.1.2 Release Identifier

4.2 Vocabulary Association Mechanisms

4.2.1 Introduction

4.2.2 Default Vocabularies

4.2.3 Reserved Prefixes

4.2.4 The prefix Attribute

4.2.5 The property Data Type

4.2.5.1 Syntax

4.2.5.2 Processing

4.3 Package Rendering Metadata

4.3.1 Introduction

4.3.2 Referencing

4.3.3 General Properties

4.3.3.1 The rendition:flow Property

4.3.3.1.1 Usage

4.3.3.1.2 Allowed Values

4.3.3.1.3 Spine Overrides

4.3.3.1.4 Examples

4.3.3.2 The rendition:align-x-center Property

4.3.4 Fixed-Layout Properties

4.3.4.1 Introduction

4.3.4.2 The rendition:layout Property

4.3.4.2.1 Usage

4.3.4.2.2 Allowed Values

4.3.4.2.3 Spine Overrides

4.3.4.2.4 Examples

4.3.4.3 The rendition:orientation Property

4.3.4.3.1 Usage

3.4.1 The `package` Element

3.4.3.1 The `metadata` Element

3.4.3.2.1 The `identifier` Element

3.4.3.2.2 The `title` Element

3.4.3.2.3 The `language` Element

3.4.3.3.2 The `contributor` Element

3.4.3.3.3 The `creator` Element

3.4.3.3.4 The `date` Element

3.4.3.3.5 The `subject` Element

3.4.3.3.6 The `type` Element

3.4.3.4 The `meta` Element

3.4.3.5 The `link` Element

3.4.4.1 The `manifest` Element

3.4.4.2 The `item` Element

3.4.4.4 The `bindings` Element (Deprecated)

3.4.5.1 The `spine` Element

3.4.5.2 The `itemref` Element

3.4.6.1 The `collection` Element

3.4.7.1 The `meta` Element

3.4.7.2 The `guide` Element

4.2.4 The `prefix` Attribute

4.2.5 The `property` Data Type

4.3.3.1 The `rendition:flow` Property

4.3.3.2 The `rendition:align-x-center` Property

4.3.4.2 The `rendition:layout` Property

4.3.4.3 The `rendition:orientation` Property

4.3.4.4 The `rendition:spread` Property

4.3.4.5 The `rendition:page-spread-*` Properties

4.3.4.6 The `rendition:viewport` Property (Deprecated)

5.4.1 The `nav` Element: Restrictions

5.4.2 The `nav` Element: Types

5.4.2.2 The `toc nav` Element

5.4.2.3 The `page-list nav` Element

5.4.2.4 The `landmarks nav` Element

5.4.2.5 Other `nav` Elements

5.4.3 The `hidden` attribute

C.2 Metadata `meta` Properties

E.2 Manifest `item` Properties