EPUB Publications 3.0.1

› 3.4.1 The package Element

The package element is the root container of the Package Document and encapsulates metadata and resource information for a Rendition.

› 3.4.2 The metadata Element

The metadata element encapsulates meta information for the given Rendition.

The minimal required metadata that each Rendition of an EPUB Publication must include consists of three elements from the Dublin Core Metadata Element Set [DCMES] — title , identifier and language — together with the modified property from DCMI Metadata Terms [DCTERMS]. Refer to the example at the end of this section for an instance of a complete minimal metadata set.

Additional optional metadata is expressed using the DCMES optional elements and the meta element.

› Examples

<package … unique-identifier="pub-id">
    …
    <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
        <dc:identifier id="pub-id">urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</dc:identifier>
        <dc:title>Norwegian Wood</dc:title>
        <dc:language>en</dc:language>
        <meta property="dcterms:modified">2011-01-01T12:00:00Z</meta>
    </metadata>
    …
</package>

› 3.4.3 The DCMES identifier Element

The [DCMES] identifier element contains a single identifier associated with the given Rendition of the EPUB Publication, such as a UUID, DOI, ISBN or ISSN.

Every Rendition's metadata section must include at least one identifier element containing an unambiguous identifier for the EPUB Publication. Multiple identifier elements are permitted, but only one can be marked as the Unique Identifier via the package element unique-identifier attribute.

<package … unique-identifier="pub-id">
    <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
        <dc:identifier id="pub-id">urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</dc:identifier>
        …
    </metadata>
</package>

This specification makes a distinction between the Unique Identifier for an EPUB Publication and the identifier that uniquely identifies a specific version of it (i.e., to be able to differentiate different versions of the same EPUB Publication). Whenever a Rendition is modified, it must include a new last modified date.

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.

Identifiers may differ from Rendition to Rendition.

This specification imposes no additional restrictions or requirements on identifiers except that they must be at least one character in length. It is strongly recommended that all identifiers be fully qualified URIs, however.

Reading Systems must trim all leading and trailing whitespace from the element value, as defined by the XML specification [XML], before processing the value.

To determine whether an identifier conforms to an established system or has been granted by an issuing authority, Reading Systems should parse the value of the property. For additional precision (e.g., if the scheme cannot be determined from the value or could lead to an ambiguous result), Authors may attach an identifier-type property to assist in Reading System identification. When included, the identifier-type property should take precedence over value parsing the identifier.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:identifier id="pub-id">urn:doi:10.1016/j.iheduc.2008.03.001</dc:identifier>
    <meta refines="#pub-id" property="identifier-type" scheme="onix:codelist5">06</meta>
    …
</metadata>

This specification does not require or endorse the use of any specific scheme for identifiers, and imposes no restrictions or requirements on identifier-type identifiers beyond those specified in the property definition.

When an EPUB Publication is derived from another publication, the identifier for that source publication may be included in the EPUB Publication metadata, and must be represented using the DCMES source element.

› 3.4.4 The DCMES title Element

The [DCMES] title element represents an instance of a name given to the EPUB Publication.

Every metadata section must include at least one title element containing the title for the EPUB Publication. Multiple title elements are permitted, but the title-type property should be attached to indicate the type of title (e.g., the main title of a work or a subtitle).

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:title id="t1">A Dictionary of Modern English Usage</dc:title>
    <meta refines="#t1" property="title-type">main</meta>
    
    <dc:title id="t2">First Edition</dc:title>
    <meta refines="#t2" property="title-type">edition</meta>
    
    <dc:title id="t3">Fowler's</dc:title>
    <meta refines="#t3" property="title-type">short</meta>
    …
</metadata>

When adding the title-type property, Authors should designate only one title element as containing the main title for the Publication. If no means of determining title types is provided, or understood, Reading Systems must treat the first title element in document order as the main title. This specification does not define how additional title elements should be processed in such situations.

The optional display-seq property may also be attached to each title to indicate their primacy for display and other rendering purposes.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:title id="t1">The Red and the Black</dc:title>
    <meta refines="#t1" property="title-type">main</meta>
    <meta refines="#t1" property="display-seq">1</meta>
    
    <dc:title id="t2">A Chronicle of the Nineteenth Century</dc:title>
    <meta refines="#t2" property="title-type">subtitle</meta>
    <meta refines="#t2" property="display-seq">2</meta>
    
    <dc:title id="t3">A Chronicle of 1830</dc:title>
    <meta refines="#t3" property="title-type">subtitle</meta>
    <meta refines="#t3" property="display-seq">3</meta>
    …
</metadata>

Titles may differ from Rendition to Rendition.

This specification imposes no additional restrictions or requirements on titles except that they must be at least one character in length.

Reading Systems must trim all leading and trailing whitespace from the element value, as defined by the XML specification [XML], before processing the value.

› Examples

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:title id="t1">The Fellowship of the Ring</dc:title>
    <meta refines="#t1" property="title-type">main</meta>
    
    <dc:title id="t2">The Lord of the Rings</dc:title>
    <meta refines="#t2" property="title-type">collection</meta>
    
    <dc:title id="t3">THE LORD OF THE RINGS, Part One: The Fellowship of the Ring</dc:title>
    <meta refines="#t3" property="title-type">expanded</meta> 
    …
</metadata>

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:title id="t1" xml:lang="fr">Mon premier guide de cuisson, un Mémoire</dc:title>
    <meta refines="#t1" property="title-type">main</meta>
    <meta refines="#t1" property="display-seq">2</meta>
    
    <dc:title id="t2">The Great Cookbooks of the World</dc:title>
    <meta refines="#t2" property="title-type">collection</meta>
    <meta refines="#t2" property="display-seq">1</meta>
    
    <dc:title id="t3">The New French Cuisine Masters</dc:title>
    <meta refines="#t3" property="title-type">collection</meta>
    <meta refines="#t3" property="display-seq">3</meta>
    
    <dc:title id="t4">Special Anniversary Edition</dc:title>
    <meta refines="#t4" property="title-type">edition</meta>
    <meta refines="#t4" property="display-seq">4</meta>
    
    <dc:title id="t5">The Great Cookbooks of the World: 
        Mon premier guide de cuisson, un Mémoire. 
        The New French Cuisine Masters, Volume Two. 
        Special Anniversary Edition</dc:title>
    <meta refines="#t5" property="title-type">expanded</meta>
    …
</metadata>

› 3.4.5 The DCMES language Element

The [DCMES] language element specifies the language of the content of the given Rendition.

Each Rendition's metadata section must include at least one language element with a value conforming to [RFC5646].

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:language>en-US</dc:language>
    …
</metadata>

Additional language elements may be included for multilingual Publications, but each element's value must conform to [RFC5646].

Languages may differ from Rendition to Rendition.

Reading Systems must trim all leading and trailing whitespace from the element value, as defined by the XML specification [XML], before processing the value.

› 3.4.6 The DCMES Optional Elements

All elements from the [DCMES] element set — except for identifier , language and title , as defined above — are designated as optional. These elements all conform to the following generalized definition:

* The xml:lang and dir attributes are permitted only on the following elements: contributor, coverage, creator, description, publisher, relation, rights and subject.

Optional metadata may differ from Rendition to Rendition.

The value of all optional [DCMES] elements must be at least one character in length.

Reading Systems must trim all leading and trailing whitespace from the element value, as defined by the XML specification [XML], before processing the value.

Except as detailed below, this specification does not modify the [DCMES] definitions for these elements.

› The DCMES contributor Element

The 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 use of the contributor element is identical to the use of the creator element in all other respects, as detailed in the next section.

› The DCMES creator Element

The creator element represents the name of a person, organization, etc. responsible for the creation of the content of an EPUB Publication. The role property can be attached to the element to indicate the function the creator played in the creation of the content.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:creator id="creator">Haruki Murakami</dc:creator>
    <meta refines="#creator" property="role" scheme="marc:relators" id="role">aut</meta>
    …
</metadata>

The creator element should contain the name of the creator as a Reading System will present it to a User. The file-as property may be attached to include a normalized form of the name, and the alternate-script property can be used to represent a creator's name in another language or script.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:creator id="creator">Haruki Murakami</dc:creator>
    <meta refines="#creator" property="role" scheme="marc:relators" id="role">aut</meta>
    <meta refines="#creator" property="alternate-script" xml:lang="ja">村上 春樹</meta>
    <meta refines="#creator" property="file-as">Murakami, Haruki</meta>
    …
</metadata>

If an EPUB Publication has more than one creator, each should be included in a separate creator element. The order in which to render the creator names should be specified using the display-seq property.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:creator id="creator01">Lewis Carroll</dc:creator>
    <meta refines="#creator01" property="role" scheme="marc:relators">aut</meta>
    <meta refines="#creator01" property="display-seq">1</meta>
    
    <dc:creator id="creator02">John Tenniel</dc:creator>
    <meta refines="#creator02" property="role" scheme="marc:relators">ill</meta>
    <meta refines="#creator02" property="display-seq">2</meta>
    …
</metadata>

If no means of establishing the primacy of creators for rendering is identifiable, Reading Systems must use the document order of creator elements in the metadata section (i.e., where the first creator element encountered is the primary creator). If a Reading System exposes creator metadata for the User, it should include all the creators listed in the metadata section whenever possible (e.g., when not constrained by display considerations).

Secondary contributors should be represented using DCMES contributor elements.

› The DCMES date Element

The 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 the Rendition was changed), which must be included using the [DCTERMS] modified property.

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.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:date>2000-01-01T00:00:00Z</dc:date>
    …
</metadata>

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.

› The DCMES source Element

The source element identifies the related resource(s) from which this EPUB Publication is derived.

When a Rendition includes page identifiers, using the pagebreak property from the EPUB Structural Semantics Vocabulary [StructureVocab], a source-of refinement property should be attached to the source element that identifies the source of the pagination.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:identifier id="isbn-id">urn:isbn:9780101010101</dc:identifier>
    <meta refines="#isbn-id" property="identifier-type" scheme="onix:codelist5">15</meta>
    
    <dc:source id="src-id">urn:isbn:9780375704024</dc:source>
    <meta refines="#src-id" property="identifier-type" scheme="onix:codelist5">15</meta>
    <meta refines="#src-id" property="source-of">pagination</meta>
    …
</metadata>

› The DCMES type Element

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

The IDPF maintains an informative registry of specialized EPUB Publication types for use with this element at http://www.idpf.org/epub/vocab/package/types .

› 3.4.7 The meta Element

The meta element provides a generic means of including package metadata, allowing the expression of primary metadata about the package or content and refinement of that metadata.

Each meta element defines a metadata expression, where the property attribute defines the statement being made in the expression and the text content of the element represents the assertion.

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

This specification reserves a set of vocabularies for use in the property attribute, but terms from any vocabulary may be used so long as a prefix is declared for the vocabulary.

The scheme attribute can be used to identify the system or scheme that a meta element's value is drawn from. The value of the scheme attribute is a property data type that resolves to the resource that defines the scheme.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:creator id="creator">Haruki Murakami</dc:creator>
    <meta refines="#creator" property="role" scheme="marc:relators" id="role">aut</meta>
    …
</metadata>

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.

In order to ensure that a Release Identifier can be constructed, the metadata element must contain exactly one meta element defining a [DCTERMS] modified property for the given Rendition. Additional modified properties may be included, but they must have a different subject (i.e., they must include a refines attribute that references an element or resource).

Every meta element must express a value that is at least one character in length after whitespace normalization.

Unless an individual property explicitly defines a different whitespace normalization algorithm, Reading Systems must trim all leading and trailing whitespace from the meta element values, as defined by the XML specification [XML], before further processing them.

› Examples

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:identifier id="pub-id">urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</dc:identifier>
    <meta refines="#pub-id" property="identifier-type" scheme="xsd:string">uuid</meta>
    
    <dc:identifier id="isbn-id">urn:isbn:9780101010101</dc:identifier>
    <meta refines="#isbn-id" property="identifier-type" scheme="onix:codelist5">15</meta>
    
    <dc:source id="src-id">urn:isbn:9780375704024</dc:source>
    <meta refines="#src-id" property="identifier-type" scheme="onix:codelist5">15</meta>
    
    <dc:title id="title">Norwegian Wood</dc:title>
    <meta refines="#title" property="title-type">main</meta>
    
    <dc:language>en</dc:language>
    
    <dc:creator id="creator">Haruki Murakami</dc:creator>
    <meta refines="#creator" property="role" scheme="marc:relators" id="role">aut</meta>
    <meta refines="#creator" property="alternate-script" xml:lang="ja">村上 春樹</meta>
    <meta refines="#creator" property="file-as">Murakami, Haruki</meta>
    
    <meta property="dcterms:modified">2011-01-01T12:00:00Z</meta>
    
</metadata>

<package version="3.0" 
         unique-identifier="pub-id"
         xmlns="http://www.idpf.org/2007/opf">
    <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
        <dc:identifier id="pub-id">urn:uuid:1234-5678</dc:identifier>
        <dc:identifier id="isbn-id">urn:isbn:9780101010101</dc:identifier>
        
        <meta refines="#isbn-id" property="meta-auth" id="meta-authority-01">Metadata Authority Inc.</meta>
        <link refines="#meta-authority-01" rel="xml-signature" href="../META-INF/Signatures.xml#MAI-Signature"/>
        …
    </metadata>
</package>

<!-- in Signatures.xml -->
<signatures>
    <Signature Id="MAI-Signature" xmlns="http://www.w3.org/2000/09/xmldsig#">
        …
    </Signature>
</signatures>

› 3.4.8 The meta Element (OPF2) [OBSOLETE]

The meta element defined in [OPF2] has been obsoleted and replaced by the new meta element, but may be included as an optional repeatable child of the metadata element for forwards compatibility purposes.

EPUB 3 Reading Systems must ignore this element.

› 3.4.9 The link Element

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

The metadata element may contain zero or more link elements.

The href attribute of the link element identifies the location of the resource — inclusion of which is optional in the container file — and the rel attribute defines the nature of the resource (i.e., its relation to the given Rensition of the EPUB Publication or property specified in the refines attribute). Reading Systems are not required to dereference these resources. Refer to Metadata link Properties for the list of resource types that are recognized by this specification.

Resources identified by the link element href attribute must not be listed in the manifest.

When the link element references a metadata record, precedence must be given to metadata defined inline in the Package Document metadata element in the case of conflicts.

The optional refines attribute can be attached when the referenced resource applies to another metadata item (e.g., to tie an XML Signature [XML DSIG Core] to a metadata authority). The resource applies to the Rendition when the attribute is not present.

If a Reading System does not recognize the relationship of the resource as defined in the rel attribute, it should ignore the link element.

› Examples

<package … prefix="foaf: http://xmlns.com/foaf/spec/">
    <metadata>
        … 
        <link rel="onix-record" href="http://example.org/onix/12389347"/>
        <link rel="xmp-record" href="http://example.org/xmp/12389347"/>
        <link rel="foaf:homepage" href="http://example.org/book-info/12389347" />
        …
    </metadata> 
    …
</package>

› 3.4.10 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.

› 3.4.11 The item Element

The item element represents a Publication Resource.

Each item element in the manifest identifies a Publication Resource by the IRI 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 the manifest, regardless of whether they are included in the EPUB Container or made available remotely. Refer to Publication Resource Locations for media type-specific requirements regarding resource locations.

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 EPUB Core Media Types.

All Foreign Resources must provide a fallback as defined in Restrictions and Fallbacks.

All Publication Resources must declare any applicable descriptive metadata properties as defined in Manifest item Properties via the item element properties attribute. Exactly one item must be declared as the EPUB Navigation Document using the nav property.

Reading Systems must ignore all descriptive metadata properties that they do not recognize.

The manifest is not self-referencing: it must not include an item element that refers to the Package Document itself.

› Examples

<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>

<manifest>
    <item id="item1" 
          href="chap1_docbook.xml" 
          media-type="application/docbook+xml" 
          fallback="fall1"/>
    <item id="fall1" 
          href="chap1.xml" 
          media-type="application/z3986-auth+xml" 
          fallback="fall2" />
    <item id="fall2" 
          href="chap1.xhtml" 
          media-type="application/xhtml+xml"/> 
    … 
</manifest>

› 3.4.12 The spine Element

The spine element defines the default reading order of the given Rendition of the EPUB Publication content by defining an ordered list of manifest item references.

The spine represents an ordered subset of the Publication Resources listed in the manifest, providing the default reading order for the given Rendition.

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

All EPUB Content Documents that are linked to from EPUB Content Documents in the spine must themselves be listed in the spine. Linked documents include documents referenced from the href attribute of a and area elements and scripted links (e.g., using DOM Events and/or form elements). All EPUB Content Documents linked to from the EPUB Navigation Document must be listed in the spine, as well, regardless of whether the Navigation Document has been included in the spine. The requirement to list linked documents applies recursively (i.e., all Content Documents linked to from linked Content Documents also have to be listed, and so on.).

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. The page-progression-direction attribute defines the flow direction from one fixed-layout page to the next.

› NCX Superseded

The NCX feature defined in [OPF2] is superseded by the EPUB Navigation Document [ContentDocs301] . EPUB 3 Publications may include an NCX (as defined in OPF 2.0.1) for EPUB 2 Reading System forwards compatibility purposes, but EPUB 3 Reading Systems must ignore the NCX.

› 3.4.13 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 of the EPUB Publication.

Each itemref element must reference a unique item in the manifest via its idref attribute.

Each referenced manifest item must be either a) an EPUB 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 itemref element linear attribute indicates whether referenced item is considered primary (yes) or auxiliary (no) in the spine. Each Rendition must include at least one primary itemref.

The linear attribute may be used to enable Reading Systems to distinguish presentation of body content from supplementary content which might be, for example, presented in a popup window or omitted from an aural rendering. Reading Systems should provide Users the ability to control whether non-linear content is rendered in the default reading order.

Any applicable descriptive metadata properties, such as those defined in the Spine itemref Properties, should be declared via the properties attribute.

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

› Examples

<spine page-progression-direction="ltr">
    <itemref idref="intro"/>
    <itemref idref="c1"/>
    <itemref idref="c1-answerkey" linear="no"/>
    <itemref idref="c2"/>
    <itemref idref="c2-answerkey" linear="no"/>
    <itemref idref="c3"/>
    <itemref idref="c3-answerkey" linear="no"/>
    <itemref idref="notes" linear="no"/>
</spine>

› 3.4.14 The guide Element [DEPRECATED]

The guide element [OPF2] is deprecated in favor of the landmarks feature in the EPUB Navigation Document. Refer to The landmarks nav Element [ContentDocs301] for more information.

Authors may include the guide element in the Package Document for EPUB 2 Reading System forwards compatibility purposes. EPUB 3 Reading Systems must ignore the guide element when provided in EPUB 3 Publications whose EPUB Navigation Document includes the landmarks feature.

› 3.4.15 The bindings Element

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

The package element may contain at most one bindings element.

The bindings element provides a means for Authors to include more sophisticated fallbacks than would otherwise be possible with the [HTML5] object element's intrinsic fallback mechanisms. When present, Reading Systems that support scripting must utilize the bindings element to handle object elements that reference unsupported media types.

Each of the bindings element's child mediaType elements defines a unique handler for one of the foreign media types referenced in the Rendition's XHTML Content Documents.

When an unsupported media type is encountered during processing of a document, the Reading System must look up the handler in the bindings element by checking the media-type attribute of each mediaType element for a match (and before attempting any other type of fallback processing). If a match is found, the XHTML Content Document referenced in the element's handler attribute must be instantiated instead of the referenced resource. If no match is found, the Reading System should continue with normal fallback processing (i.e., check for an intrinsic fallback for the object).

The Reading System must instantiate the designated handler as if it had been referenced from the object element's data attribute with the following parameters:

Any additional param children of the object element must be similarly added as parameters using the param element's name attribute as the new parameter name and its value attribute as the new value.

For example, the following object element containing a foreign media type:

<object data="horse.ogg" type="audio/ogg">
    <param name="autoplay" value="false"/>
</object>
        

would result in the following query string being sent to the handler XHTML Content Document after processing:

src=horse.ogg&type=audio/ogg&autoplay=false

All IRI reserved characters, plus the characters <, >, ", space, {, }, |, \, ^ and `, in the generated query string must be encoded and decoded as per [RFC3987].

object elements that reference media types handled by the bindings element are only processed in spine-referenced XHTML Content Documents (i.e., they are ignored in container-constrained scripting contexts ).

› Example

The following partial example illustrates how bindings can be used to provide a slideshow.

Consider a Rendition of an EPUB Publication with the following Package Document:

<package …>
    …
    <manifest>
        <item id="pict1" 
            href="images/Pict1.jpg" 
            media-type="image/jpeg"/>
        …
        <item id="content" 
            href="content.xhtml" 
            media-type="application/xhtml+xml"/>
        <item id="impl" 
            href="impl.xhtml" 
            media-type="application/xhtml+xml" 
            properties="scripted"/>
        <item id="slideshow" 
            href="slideshow.xml" 
            media-type="application/x-demo-slideshow"/>
    </manifest>
    
    <bindings>
        <mediaType handler="impl"
            media-type="application/x-demo-slideshow"/>
    </bindings>
    …
</package>

and the following content in the file content.xhtml:

<html …>
    …
    <body>
        …
        <object data="slideshow.xml" 
            type="application/x-demo-slideshow">
            <img src="images/Pict1.jpg"/>
            <img src="images/Pict2.jpg"/>
            <img src="images/Pict3.jpg"/>
            <img src="images/Pict4.jpg"/>
        </object>
        …
    </body>
</html>

and the following content in the file slideshow.xml:

<slides>
    <slide src="images/Pict1.jpg" dur="3"/>
    <slide src="images/Pict2.jpg" dur="3"/>
    <slide src="images/Pict3.jpg" dur="3"/>
    <slide src="images/Pict4.jpg" dur="3"/>
</slides>

Depending on the capabilities of the User's Reading System, they will see one of the following renderings of the slideshow:

› 3.4.16 The mediaType Element

The mediaType element associates a Foreign Resource media type with a handler XHTML Content Document.

Each child mediaType of a bindings element must define a unique content type in its media-type attribute, and the media type specified must not be a Core Media Type.

The required handler attribute must reference the ID [XML] of an item in the manifest of the default implementation for this media type. The referenced item must be an XHTML Content Document.

All XHTML Content Documents designated as handlers must have the scripted property set in their manifest item element's properties attribute.

› 3.4.17 The collection Element

The collection element defines a related group of resources.

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 specific implementations are intended to be derived (e.g., through IDPF sub-specifications). Such implementations must define the purpose of the collection 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 implementation must define a role value that uniquely identifies all conformant collection elements. The role of each collection element in the Package Document must be identified in its role attribute, whose value must be one or more NMTOKENs [XSD-DATATYPES] and/or full IRIs [RFC3987]. The use of NMTOKEN values is reserved for IDPF-defined roles, a registry of which is maintained at http://www.idpf.org/epub/vocab/package/roles . 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 full IRIs. Custom roles must not incorporate the string idpf.org in the host component of their identifying IRI.

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

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:

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

Specific implementations 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., specific implementations cannot introduce new elements or attributes, or re-introduce those expressly forbidden above). Specific implementations 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 of collection elements. The content must remain consumable by a User without any information loss or other significant deterioration.

› Examples

<package …>
    …
    <collection role="http://example.org/roles/unit">
        <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
            <dc:title>Foo Bar</dc:title>
        </metadata>
        <link href="EPUB/xhtml/foo-1.xhtml"/>
        <link href="EPUB/xhtml/foo-2.xhtml"/>
    </collection>
    …
</package>

› 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. This Unique Identifier, whether chosen or assigned, must be stored in a 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.

› 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 required 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, each Rendition must include exactly one [DCTERMS] modified property containing its last modification date (see meta). The value of this property must be an XML Schema [XSD-DATATYPES] 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 time zone indicator.

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.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:identifier id="pub-id">urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</dc:identifier>
    <meta property="dcterms:modified">2011-01-01T12:00:00Z</meta>
    …
</metadata>

results in the Package ID:

urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809@2011-01-01T12:00:00Z

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 required 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.

› 4.2.1 Overview

This section is informative

The property, properties, rel and scheme attributes use the property data type to represent terms from metadata vocabularies. Similar to a CURIE [RDFa11], 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, the means of establishing the IRI a prefix maps to is required, and this specification defines three such mechanisms:

› 4.2.2 Default Vocabulary

The 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. Instead, different default vocabularies are defined for use in attributes that accept a property data type as follows:

The IRIs associated with the Package Metadata Vocabulary and Link Relationships Vocabulary must not be assigned a prefix using the prefix attribute.

› 4.2.3 Reserved Prefixes

This specification reserves a set of prefixes that Authors may use in package metadata. These prefixes are defined in the normative document EPUB Package Document Reserved Prefixes.

The prefixes defined in this document are maintained and updated separately of this specification and are subject to change at any time.

Reading Systems must resolve all reserved prefixes used in Package Documents using their pre-defined URIs. 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 the specification.

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

<package … 
	prefix="foaf: http://xmlns.com/foaf/spec/
		 dbp: http://dbpedia.org/ontology/">
	…
</package>

To avoid conflicts, the prefix attribute must not be used to define a prefix that maps to the default vocabulary. If the prefix attribute includes a declaration for a pre-defined 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 pre-defined prefix.

The prefix '_' is reserved for future compatibility with RDFa [RDFa11] processing, so must not be defined.

› 4.2.5 The property Data Type

<meta property="dcterms:modified">2011-01-01T12:00:00Z</meta>

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

<meta … property="role">aut</meta>

http://idpf.org/epub/vocab/package/#role

› 4.3.1 Overview

This section is informative

The following sections both define a set of properties for use in package metadata and constitute a referenceable vocabulary. This vocabulary is the default vocabulary reserved by this specification for the use of unprefixed terms in package metadata.

The properties defined in this vocabulary are referenceable using the base IRI http://idpf.org/epub/vocab/package/#.

› 4.3.2 Metadata meta Properties

The meta element properties enhance Rendition metadata by providing additional level(s) of detail.

These properties must reference the expression or resource they augment in the refines attribute on their parent meta element.

The following tables detail the available properties.

<meta property="belongs-to-collection" id="c01">The New French Cuisine Masters</meta>
<meta refines="#c01" property="collection-type">series</meta>
<meta refines="#c01" property="dcterms:identifier">urn:uuid:11111111-2222-3333-4444-555555555555</meta>

<meta property="belongs-to-collection" id="c02">Harry Potter</meta>
<meta refines="#c02" property="collection-type">set</meta>
<meta refines="#c02" property="group-position">2</meta>
<meta refines="#c02" property="dcterms:identifier">urn:uuid:99999999-8888-7777-6666-555555555555</meta>

<meta property="belongs-to-collection" id="c02">Harry Potter</meta>
<meta refines="#c02" property="collection-type">set</meta>

› 4.3.3 Metadata link Properties

Properties for use in the metadata link element rel attribute are defined in the normative Link Relationships Vocabulary.

› 4.3.4 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.

The mathml, remote-resources, scripted and switch 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 HTML5 iframe 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.

› Examples

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

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

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

› 4.3.5 Spine itemref Properties

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

The Cardinality field indicates the number of times the property must appear within the Package Document scope, and the Usage field indicates usage conditions.

› Examples

<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>

› 4.4.1 General Properties

<metadata>
    <meta property="rendition:flow">paginated</meta>
</metadata>

<spine>
    <itemref idref="toc" properties="rendition:flow-scrolled-doc"/>
    <itemref idref="c01"/>
</spine>

› 4.4.2 Fixed-Layout Properties

<meta property="rendition:layout">pre-paginated</meta>

<head>
    <meta name="viewport" content="width=1200, height=900"/>
	
    <link rel="stylesheet" href="eink-style.css" media="(max-monochrome: 3)"/>
    <link rel="stylesheet" href="skinnytablet-style.css" media="((color) and
        (max-height:600px) and (orientation:landscape), (color) and (max-width:600px)
        and (orientation:portrait))"/>
    <link rel="stylesheet" href="fattablet-style.css" media="((color) and
        (min-height:601px) and (orientation:landscape), (color) and (min-width:601px)
        and (orientation:portrait)"/>	
</head>

<metadata>
    <meta property="rendition:layout">pre-paginated</meta>
    <meta property="rendition:spread">none</meta>
    
    <meta property="rendition:orientation">landscape</meta>
</metadata>

<metadata>
    <meta property="rendition:layout">pre-paginated</meta>
    <meta property="rendition:spread">landscape</meta>
</metadata>

<metadata>
    <meta property="rendition:layout">reflowable</meta>
    <meta property="rendition:spread">auto</meta>
</metadata>

<spine>
    <itemref idref="titlepage" properties="page-spread-right rendition:layout-pre-paginated"/>
</spine>

<spine page-progression-direction="ltr">
    …
    <itemref idref="center-plate-left" properties="rendition:spread-both page-spread-left"/>
    <itemref idref="center-plate-right" properties="rendition:spread-both page-spread-right"/>
    …
</spine>

<metadata>
    <meta property="rendition:layout">pre-paginated</meta>
    <meta property="rendition:spread">auto</meta>
</metadata>
<spine>
    <itemref idref="center-plate" properties="rendition:page-spread-center"/>
</spine>

width=x, height=y

<metadata>
    <meta property="rendition:layout">pre-paginated</meta>
    <meta property="rendition:viewport">width=1200, height=900</meta>
    <meta property="rendition:viewport" refines="#cover-ref">width=600, height=1200</meta>
</metadata>

<spine>
    <itemref id="cover-ref" idref="cover"/>
    <itemref idref="c01"/>
</spine>

› 5.2.1 Foreign Resource Restrictions

All Publication Resources of an EPUB Publication must be Core Media Type Resources or must provide a Core Media Type fallback. The cases in which Foreign Resources may be used, and the requirements and rules for Core Media Type fallback provision in such cases, are detailed below.

› 5.2.2 Manifest Fallbacks

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 fallback item 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's fallback attribute represents the fallback chain for that item. The order of the resources in the fallback chain represents the Authors' 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 Authors' preferred fallback order.

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

Fallback chains must not contain any circular- or self-references to item elements in the chain.

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 [ContentDocs301] .