EPUB Publications 3.0

› 3.4.1 The package Element

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

› 3.4.2 The metadata Element

The metadata element encapsulates Publication meta information.

The minimal required metadata that Publications 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 EPUB Publication, such as a UUID, DOI, ISBN or ISSN.

Every metadata section must include at least one identifier element containing an unambiguous identifier for the 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 EPUB Publications containing different versions of the same Manifestation). Two copies of an EPUB that are bit-for-bit identical are the same version and must retain the same last modified date. If they are not bit-for-bit identical, they represent different versions, and must have different last modified dates.

To identify a specific version of a packaged Publication, a Package Identifier can be constructed by combining the Unique Identifier with the last modified date of the Publication. Changes between versions may include minor typographic or markup corrections, without affecting the Unique Identifier. Significant revisions to the content that result in a new edition require a change of the Unique Identifier. For more information on the semantics and requirements of the Package Identifier, refer to Package Identifier.

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 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 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, a subtitle, etc.).

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

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>
    <meta refines="#t2" property="group-position">1</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">extended</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="group-position">2</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">extended</meta>
    …
</metadata>

› 3.4.5 The DCMES language Element

The [DCMES] language element specifies the language of the Publication content.

Every 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].

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.

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 a 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 a 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 a 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 is included, Reading Systems must use the order of creator elements.

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

For compliance with EPUB 2 Reading Systems, the date string should conform to Date and Time Formats.

<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 a Publication or may change from instance to instance (if the Publication gets generated on demand, for example).

Only one date element is allowed.

The DCMES source Element

The source element must only be used to specify the identifier of the source publication from which this EPUB Publication is derived.

<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>
    …
</metadata>

The source element allows the print source of the pagination of a Publication to be determined.

Only one source element is allowed.

The DCMES type Element

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

This specification does not define values for this element, however. The development of specialized Publication types, and the assignment of formal identifiers to represent them, will occur independently of this specification.

Only one type element is allowed.

› 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 Package Identifier can be constructed, the metadata element must contain exactly one meta element defining a [DCTERMS] modified property for the Publication. Additional modified properties may be included, but they must have a different subject (i.e., they must include a refines attribute pointing to 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 a 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 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 represented as items 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 Publication as a whole 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 EPUB Publication, 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 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, with content items not being referenced being ancillary to those that do.

Reading Systems must provide a means of rendering a Publication in the order defined by the spine, which includes: 1) recognizing the first primary (linear='yes') item in the spine as the beginning of the main reading order of the Publication; and, 2) rendering successive primary items in the order given in the spine.

NCX Superseded

The NCX feature defined in [OPF2] is superseded by the EPUB Navigation Document [ContentDocs30]. 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 in favor of the EPUB Navigation Document.

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

Each itemref element must reference an 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. This 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 rendition.

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 [ContentDocs30] 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 Publication'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'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" media-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 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 renditions 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's properties attribute.

› 4.1.1 Unique Identifier

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

Although not static, changes to the Unique Identifier for a 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 Publication.

› 4.1.2 Package 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 a 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 Package Identifier, or means of distinguishing and sequentially ordering Publications with the same Unique Identifier. The Package 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 Publication.

When the taken together, the combined value represents a unique identity that can be used to distinguish any particular version of an EPUB Manifestation from another. To ensure that a Package Identifier can be constructed, the Publication must include exactly one [DCTERMS] modified property containing the 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 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 this specification requires that all string representations of the identifier 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 Package Identifier consequently must be split on the last instance of the at sign when decomposing it into its component parts.

The Package Identifier does not supersede the Unique Identifier, but represents the means by which different versions of the same 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 Publications in order without requiring knowledge of the exact identifier that came before.

The Package Identifier consequently allows a set of Publications to be inspected to determine if they represent the same version of the same Publication, different versions of a single Publication, or any combination of differing and similar 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 [RDFa10], 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 in package metadata, and whose terms must always be unprefixed.

To facilitate the inclusion of package metadata, this specification defines the Package Metadata Vocabulary as the default vocabulary for Package Documents.

If a property value does not include a prefix, the IRI [RFC3987] stem http://idpf.org/epub/vocab/package/# must be used to generate the resulting IRI.

The IRI associated with the Package Metadata Vocabulary must not be assigned a prefix using the prefix attribute.

› 4.2.3 Reserved Vocabularies

This specification exclusively defines the following set of prefixes for use in package metadata.

The prefixes listed in the previous table must not be redeclared using the prefix attribute declaration mechanism. Similarly, the IRIs associated with each prefix must not be assigned to another prefix.

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

The prefix attribute must not be used to redefine the default vocabulary or the predefined prefixes.

The prefix '_' is reserved for future compatibility with RDFa [RDFa10] 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 Publication 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.

› 4.3.3 Metadata link Properties

The following tables define properties for use in the metadata link element rel attribute.

› 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, svg 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>

› 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 Resource may be used, and the requirement and rules for Core Media Type fallback provision in such cases, are detailed below.

› 5.2.2 Manifest Fallbacks

Fallbacks must be provided for each Publication Resource referenced in a spine itemref element that is not an EPUB Content Document.

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.

A fallback chain must contain at least one EPUB Content Document and must not contain any circular- or self-references to items 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 [ContentDocs30].