EPUB Publications 3.0

› 1.3.1 Conformance Statements

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

All sections of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendices applies to all child content and subsections they may contain.

All examples in this specification are informative.

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

NOTE The spec [RDFa11 Core] underlying the profile and prefix attributes is still evolving. The exact mechanism for vocabulary association in EPUB 3 is therefore subject to change.

› 4.4.2 The metadata Element

The metadata element encapsulates information about the publication as a whole, including metadata that applies to the publication package and to the abstract content contained within the package.

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

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

If the identifier ([DCMES] or [DCTERMS]) conforms to a established system or has been granted by an issuing authority, the scheme employed should be identified by attaching the optional scheme ancillary property to 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">doi</meta>
    …
</metadata>

This specification does not require or endorse the use of any scheme for identifiers, but authors are encouraged to use established identifiers for schemes such as provided by the ONIX and MARC standards. The scheme identifier used should conform to the requirements of the chosen system; this specification imposes no additional restrictions or requirements on scheme identifiers.

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

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

› 4.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 have the same language code as their value. Issue 77.

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>

› 4.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).

NOTE The spec [RDFa11 Core] underlying the profile and prefix attributes is still evolving. The exact mechanism for vocabulary association in EPUB 3 is therefore subject to change.

<metadata>
    <meta property="dcterms:identifier" id="pub-id">urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</meta>
    <meta about="#pub-id" property="scheme">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 about="#pub-id" property="scheme">uuid</meta>
    
    <meta property="dcterms:identifier" id="isbn-id">urn:isbn:9780101010101</meta>
    <meta about="#isbn-id" property="scheme">isbn</meta>
    
    <meta property="source-identifier" id="src-id">urn:isbn:9780375704024</meta>
    <meta about="#src-id" property="scheme">isbn</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">primary</meta>
    
    <meta property="dcterms:modified">2011-01-01T12:00:00Z</meta>
    <meta property="dcterms:language">en</meta>
    <meta property="page-progression-direction">ltr</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">aut</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="scheme">isbn</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>

› 4.4.7 The link Element

The link element is used to associate supplementary resources with the 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 and the rel attribute defines the nature of the resource (i.e., its relation to the Publication or property specified in the about attribute). 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 are considered Supplementary Resources, and therefore must not be represented as items in the manifest. Reading Systems are not required to dereference the resources identified through the link element.

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>

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

› 4.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 Type provided in the item element media-type attribute. Core Media Type Resources must use the MIME Type string designated in EPUB Core Media Types.

All Foreign Resources must provide a fallback as defined in Fallback Requirements and Processing Flow .

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.

This specification and its sibling specifications may explicitly define certain resource types to be supplementary. These resources are not Publication Resources and must not be referenced from the manifest. An example of a supplementary resource is a metadata record referenced from the link element.

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.pdf" 
          media-type="application/pdf" 
          fallback="fall2" />
    <item id="fall2" 
          href="chap1.xhtml" 
          media-type="application/xhtml+xml"/> 
    … 
</manifest>

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

› 4.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 references provided in the spine must resolve to either XHTML Content Documents or SVG Content Documents. References should resolve to XHTML Content Documents, but may resolve to SVG Content Documents when an alternative representation of the same content utilizing XHTML Content Documents is included, or the nature of the content being represented is inherently unsuitable to representation in XHTML.

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

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

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

When present, Reading Systems that support scripting must utilize the bindings element to handle object elements in XHTML Content Documents that reference MIME media types that are not natively supported. When encountering such references, a Reading System must instantiate the designated XHTML Content Document handler as if it had been referenced from the object element data attribute with the following URL parameters:

All param children of the object element must be similarly encoded as URL parameters using the param's name attribute as the new parameter name and its value attribute as the new value.

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

Resulting URI query string:
                    
src=horse.ogg&amp;type=audio/ogg&amp;autoplay=false

                    

<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"/>
    <item id="slideshow" href="slideshow.xml" media-type="application/x-demo-slideshow"/>
</manifest>

<bindings>
    <mediaType media-type="application/x-demo-slideshow" handler="impl"/>
</bindings>
                        
in content.xhtml:

…
<object data="slideshow.xml" type="application/x-demo-slideshow">
    <!-- if scripting is not available, just show them inline -->
    <img src="images/Pict1.jpg"/>
    <img src="images/Pict2.jpg"/>
    <img src="images/Pict3.jpg"/>
    <img src="images/Pict4.jpg"/>
</object>
…

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

                        

› 4.4.14 The mediaType Element

The mediaType element associates a non-native media type with a handler (the handler provides a default script-based implementation for items of the given media type when they are referenced from object elements in a XHTML Content Document).

Each child mediaType of a bindings element must define a unique content type in its media-type attribute. 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.

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

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

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

Property usage examples in the following sections have been drawn from the metadata examples whenever possible. Refer to those examples for fuller context.

› 5.3.2 Metadata meta properties

› 5.3.3 Metadata link properties

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

› 5.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 svg properties are recursive; they must be specified on applicable items regardless of whether the property holds true for the resource described by the current item element or to a resource embedded within it (e.g., 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" />

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

› 6.2.1 Introduction

EPUB Publications may reference Foreign Resources. In order to ensure that all EPUB Publications can be successfully rendered by Reading Systems, alternative fallback resources must be provided for each such resource.

Fallbacks are provided either via intrinsic mechanisms defined for certain Publication Resource types, or via a manifest-level fallback mechanism. These mechanisms are defined in this section.

› 6.2.2 Manifest fallback

Unless one of the exceptions defined in Intrinsic fallback apply, fallbacks must be provided for each Foreign Resource using the fallback attribute on the manifest item element that represents the Foreign 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. A fallback chain must contain at least one Core Media Type Resource and must not contain any circular- or self-references to items in the chain.

A Reading System that does not support the Media Type of a given Publication Resource must traverse the fallback chain until it encounters a supported Publication Resource. The resource identified by the fallback item is then used in place of the unsupported item.

Fallbacks may also be provided for Publication Resources that are Core Media Type Resources; a Reading System may choose to utilize such fallbacks in order to find the optimal version of a resource to render in a given context. An example of when this feature can be utilized is when providing fallbacks for scripted content [ContentDocs30] .

TODO Fallbacks for xhtml-nav, and possibly other core media types, are not legal. Determine which they are and add here.

› 6.2.3 Intrinsic fallback

This section defines a set of exceptions to the general requirements for manifest-level fallbacks for Foreign Resources. If none of these exceptions apply to a given Foreign Resource reference, then the manifest fallback mechanism must be used to supply a Core Media Type Resource fallback.

› 7.2.1 Introduction

An EPUB Canonical Fragment Identifier (CFI) is a component of a URI or IRI that identifies a location inside an EPUB Content Document.

An EPUB Canonical Fragment Identifier has the following functional properties:

As such, the CFI scheme is primarily intended to be used in contexts such as collaborative annotations and server-side bookmarks. Note that CFIs are only reliable in contexts where the content has a static structure.

› 7.2.2 Definition

Each CFI represents a single location in a Content Document. A single Identifier cannot represent a range of locations; multiple Identifiers are required to express ranges. Identifiers are also not intended to be human readable, but are optimized for machine processing.

The following syntax is provided for CFIs (using CSS conventions):

fragment : "#epubcfi=" [navstep]+ [termstep]? [side]?
navstep : "/" integer | "!" ["/"]? integer
termstep :  ":" integer | "@" number "," number | "~" number
side : "b" | "a"
number : ["-"]? digit+ ["." digit+]?
integer: digit+
                

Each CFI begins with a hash symbol (#) identifying it as a fragment identifier. The hash symbol is followed by the initial sequence epubcfi=, which identifies that the fragment conforms to this scheme.

After establishing the scheme, a CFI consists of a sequence of steps, each of which is either navigational (can be repeated) or terminating (must come last in the sequence). An optional side designator can also occur after the step sequence to identify a location that "sticks" to the content that comes before (b) or after (a) it. This designator is needed, for example, to determine which page a location falls on when it occurs at the page boundary.

                        
#epubcfi=/2/6/4!/2/4/10/3:10
                     

Leading zeros are not allowed for numbers and integers, except to represent zero. Trailing zeros are not allowed in number fractional part to ensure uniqueness.

› 7.2.3 Processing

An EPUB Canonical Fragment Identifier is processed by applying the following rules, in order, starting from the root (document) XML node of an EPUB Content Document:

Spatial and temporal positions can be combined together, but not other types. The Temporal step must always precede the spatial step syntactically.

When producing CFIs for text locations, unless the text is defined by the img element's alt attribute, processing should always start with the text node or text node collection (even if it is empty) that corresponds to the location, and then trace the ancestor and reference chain to the OPF file root.

› 7.2.4 Sorting

The following conditions apply when sorting CFIs:

› 7.2.5 Examples

The fragment identifier in the example above refers to the position right after the digit 9 in the following sample documents:

<?xml version="1.0"?>
<package … >
    <metadata>
        …
    </metadata>
    <manifest>        
        …
    </manifest>
    <spine>
        <itemref idref="titlepage"/>
        <itemref idref="chapter01"/>
        <itemref idref="chapter02"/>
        <itemref idref="chapter03"/>
        <itemref idref="chapter04"/>
    </spine>
</package>

<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>…</title>
    </head>
    <body>
        <p>…</p>
        <p>…</p>
        <p>…</p>
        <p>…</p>
        <p>aaa <em>bbb</em>0123456789</p>
        <p>…</p>
        <p>…</p>
        <img src="foo.svg"/>
        <p>…</p>
        <p>…</p>
    </body>
</html>

The following table shows additional examples of CFIs and what they select from the preceding example documents:

CFIs can also be used to cross-reference XML content inside the Publication. Such use is intended to be used primarily when the default URI/IRI fragment identification scheme for XML (providing a reference to an XML Name) cannot be employed. A relative reference to a particular resource in the spine should be given (as usual), followed by the CFI component which should be resolved starting from the referenced documents root. For instance, chapter02.xhtml might give a reference to the last location in the previous example like this:

                        
…
<a href="chapter01.xhtml#epubcfi(/2/4/10/2/1:3b)">location</a>
…