EPUB Publications 3.0

› 3.4.1 The package Element

The package element is the root container of the Package Document, encapsulating metadata and resource information for the EPUB Publication.

› 3.4.2 The metadata Element

The metadata element encapsulates information about the Publication as a whole.

Core Publication metadata is expressed by a combination of three required elements from the Dublin Core Metadata Element Set [DCMES] — title, identifier and language — together with optional properties from DCMI Metadata Terms [DCTERMS] and a set of package and ancillary properties defined in this specification. (Refer to the example at the end of this section for an instance of a complete minimal metadata set.)

Properties from vocabularies not defined in this specification may be added to the metadata section to enhance package and content metadata, and to supplement required and optional properties, but their use is optional.

This specification subsets the RDFa 1.1 [RDFa11 Core] profile and prefix definition mechanisms to enable the inclusion and extension of metadata vocabularies for defining publications. These features allow core metadata properties to be added unprefixed, and additionally work to standardize the inclusion of metadata across the publishing spectrum by predefining prefixes for the most commonly-used vocabularies.

All publications must reference the metadata profile on the root package element using the profile attribute. Unlike its RDFa equivalent, the profile attribute must only contain the single canonical URI of the EPUB default profile.

The addition of the metadata profile allows all properties from the EPUB 3 Package Metadata Vocabulary to be referenced without using prefixes. The profile also defines a set of prefixes for adding other vocabulary properties to EPUB Publications. (Refer to the profile for more information.)

If the metadata profile does not define a prefix for a needed vocabulary, it does not imply that the vocabulary cannot be used. The prefix attribute can also be attached to the package element to define additional prefixes. New prefixes are defined by including whitespace-separated prefix/URI pairings.

<package … prefix="foaf: http://xmlns.com/foaf/spec/">
    <metadata>
        <meta property="dcterms:creator" id="auth">Samuel Johnson</meta>
        <meta property="foaf:title" about="#auth">Dr.</meta>
        …
    </metadata>
</package>

The prefix attribute must not redeclare a prefix that has already been defined through the metadata profile. Similarly, the XML Namespaces [XMLNS] method of defining namespace prefixes using the xmlns pseudo-attribute must not be used to define vocabulary prefixes.

Example

<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 id="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>

Reading Systems must not fail catastrophically if they encounter two distinct EPUB Publications with the same purportedly Unique Identifier.

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.

The [DCTERMS] identifier property will supersede the DCMES identifier element in a future version of the specification, but its inclusion is currently optional. Authors should include both versions for forwards compatibility, using the prefer attribute on the identifier element to indicate to Reading Systems that the property should be used in preference. Refer to Dublin Core Metadata Vocabulary Transition for more information.

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

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, however, that all identifiers be fully qualified URIs.

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 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 a scheme property to the identifier to assist Reading System identification. When included, the scheme 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 about="#pub-id" property="scheme" datatype="xsd:string">doi</meta>
    …
</metadata>

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

› 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 optional display-seq property should be attached to each to indicate their primacy for display and other rendering purposes.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:title prefer="t1" id="ot1" xml:lang="fr">Mon premier guide de cuisson, un Mémoire</dc:title>
    <meta about="#t1" property="display-seq">2</meta> 
    
    <dc:title prefer="t2" id="ot2">The Great Cookbooks of the World</dc:title>
    <meta about="#t2" property="display-seq">1</meta>
    …
</metadata>

The title=type property may also be attached to indicate the type of title (e.g., the primary title for a work, a subtitle, etc.).

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:title id="title">Norwegian Wood</dc:title>
    <meta about="#title" property="title-type" id="title-type">01</meta>
    <meta about="#title-type" property="scheme"
        datatype="xsd:anyURI">http://www.editeur.org/files/ONIX%20for%20books%20-%20code%20lists/ONIX_BookProduct_Codelists_Current.html#codelist15</meta>
    …
</metadata>

If no means of establishing the primary title of the publication is included, Reading Systems must treat the first title element in document order as the primary title.

The [DCTERMS] title property will supersede the DCMES title element in a future version of the specification, but its inclusion is currently optional. Authors should include both versions for forwards compatibility, using the prefer attribute on the title element to indicate to Reading Systems that the property should be used in preference. Refer to Dublin Core Metadata Vocabulary Transition for more information.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:title id="title" prefer="dcterms-title">Norwegian Wood</dc:title>
    <meta property="dcterms:title" id="dcterms-title">Norwegian Wood</meta>
    …
</metadata>

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

› 3.4.5 The DCMES language Element

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

Every metadata section must include a single 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>

A single optional [DCTERMS] language property may also be included. The value of this property must also conform to RFC 5646. When both the DCMES element and DCTERMS property are included, they must both specify the same language code.

The DCTERMS language property will supersede the DCMES language element in a future version of the specification, but its inclusion is currently optional. Authors should include both versions for forwards compatibility, using the prefer attribute on the language element to indicate to Reading Systems that the property should be used in preference. Refer to Dublin Core Metadata Vocabulary Transition for more information.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:language prefer="pub-lang">en-US</dc:language>
    <meta property="dcterms:language" id="pub-lang">en-US</meta>
    …
</metadata>

› 3.4.6 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 consisting of a subject, predicate and object. The subject can be the EPUB Publication (e.g., to express its title(s), identifier(s), etc.), a resource belonging to the Publication (e.g., to express the duration of a media clip) or a metadata expression defined in another meta element (e.g., to identify a scheme an identifier conforms to).

The subject of the metadata expression is defined by the about attribute. When attached to a meta element, the attribute must reference the specific metadata element or resource that constitutes the subject. In its absence, the metadata expression defines metadata about the Publication.

The predicate of the metadata expression — the relationship between the subject and object — is defined by the required property attribute. The value of the property must be a CURIE [RDFa11 Core] that resolves to a property from a metadata vocabulary (it is not required that Reading System be able to resolve the CURIEs, however).

<metadata>
    <meta property="dcterms:identifier" id="pub-id">urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</meta>
    <meta about="#pub-id" property="scheme" datatype="xsd:string">uuid</meta>
    …
</metadata>

The value of the meta element represents the object of the metadata expression. Every meta element must express a value that is at least one character in length after whitespace normalization.

Note that unless an individual property explicitly specifies 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.

In order to ensure that a Package Identifier can be constructed, exactly one [DCTERMS] modified property must be included in the metadata section for the Publication using the meta element, as defined in Package Identifier. Additional modified properties may be included, but they must have a different subject (i.e., they must include an about attribute pointing to an element or resource).

Examples

<metadata>
    …
    <meta property="dcterms:identifier" id="dcterms-id">urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</meta>
    
    <meta property="dcterms:identifier" id="isbn-id">urn:isbn:9780101010101</meta>
    
    <meta property="source-identifier" id="src-id">urn:isbn:9780375704024</meta>
    
    <meta property="dcterms:title" id="title">Norwegian Wood</meta>
    <meta about="#title" property="alternate-script" xml:lang="ja">ノルウェイの森</meta>
    <meta about="#title" property="title-type" id="title-type">01</meta>
    <meta about="#title-type" property="scheme" datatype="xsd:anyURI">http://www.editeur.org/files/ONIX%20for%20books%20-%20code%20lists/ONIX_BookProduct_Codelists_Current.html#codelist15</meta>
    
    <meta property="dcterms:modified">2011-01-01T12:00:00Z</meta>
    <meta property="dcterms:language">en</meta>
    
    <meta property="dcterms:creator" id="creator">Haruki Murakami</meta>
    <meta about="#creator" property="alternate-script" xml:lang="ja">村上 春樹</meta>
    <meta about="#creator" property="file-as">Murakami, Haruki</meta>
    <meta about="#creator" property="role" id="role">aut</meta>
    <meta about="#role" property="scheme" datatype="xsd:anyURI">http://id.loc.gov/vocabulary/relators</meta>

</metadata>

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:title prefer="t1" id="ot1" xml:lang="fr">Mon premier guide de cuisson, un Mémoire</dc:title>
    <meta property="dcterms:title" id="t1" xml:lang="fr">Mon premier guide de cuisson, un Mémoire</meta>
    <meta about="#ot1" property="title-type">primary</meta>
    <meta about="#ot1" property="display-seq">2</meta> 
    
    <dc:title prefer="t2" id="ot2">The Great Cookbooks of the World</dc:title>
    <meta property="dcterms:title" id="t2">The Great Cookbooks of the World</meta>
    <meta about="#ot2" property="title-type">collection</meta>
    <meta about="#ot2" property="display-seq">1</meta>
    <meta about="#ot2" property="file-as">Great Cookbooks of the World, The</meta>
    
    <dc:title prefer="t3" id="ot3">The New French Cuisine Masters, Volume Two</dc:title>
    <meta property="dcterms:title" id="t3">The New French Cuisine Masters, Volume Two</meta>
    <meta about="#ot3" property="title-type">series</meta>
    <meta about="#ot3" property="file-as">New French Cuisine Masters, The</meta>
    <meta about="#ot3" property="group-position">2</meta>
    <meta about="#ot3" property="display-seq">3</meta>
    
    <dc:title prefer="t4" id="ot4">Special Anniversary Edition</dc:title>
    <meta property="dcterms:title" id="t4">Special Anniversary Edition</meta>
    <meta about="#ot4" property="title-type">edition</meta>
    <meta about="#ot4" property="display-seq">4</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>
        <meta property="dcterms:identifier" id="isbn-id">urn:isbn:9780101010101</meta>
        
        <meta about="#isbn-id" property="meta-auth" id="meta-authority-01">Metadata Authority Inc.</meta>
        <link about="#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.7 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 (resources may or may not be included 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 about 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 about 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.

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.8 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.9 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 their physical location (i.e., regardless of whether they are available in the EPUB Container or 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 item element 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 must be declared as the EPUB Navigation Document using the nav property.

The manifest is not self-referencing: it must not include item elements referring to the resource(s) that make up the Package Document itself.

Examples

<manifest>
    <item id="intro" 
          href="intro.xhtml" 
          properties="nav"
          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.10 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.

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. EPUB 3 Reading Systems must ignore the NCX in favor of the EPUB Navigation Document.

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

An EPUB Content Document referenced from the spine is referred to in this specification and its sibling specifications as a Top-level Content Document.

Each itemref element must reference, via its idref attribute, an item in the manifest. The spine consequently represents an ordered subset of the Publication Resources listed in the manifest, with content items not being referenced being ancillary to those that do appear there.

Each manifest item referenced from the spine must either be: 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 a spine item is considered primary (yes) or auxiliary (no). 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.

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

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.12 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.13 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 object element's intrinsic fallback mechanisms. When present, Reading Systems that support scripting must utilize the bindings element to handle [HTML5] 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 Reading System the User opens this Publication in, they will see one of the following renditions of the slideshow:

› 3.4.14 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 section 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 @ character 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

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.3.1 Overview

This section is informative

The following sections enumerate key properties — both defined as part of this specification and by external agencies — that Reading Systems must minimally recognize. It is not intended to be a comprehensive list of vocabularies or properties that can be used to add or annotate package metadata.

Properties defined by this specification are made available for use in the EPUB 3 Package Metadata Vocabulary, which is the default vocabulary defined in the Package Document's metadata profile.

› 4.3.2 Metadata meta 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 an item or any content it includes matches their respective definitions. For example, the scripted property must be specified on an item element representing a non-scripted XHTML Content Document if it embeds a scripted Content Document.

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