EPUB Publications 3.0

Working Group Draft 16 May 2011

This version
http://www.idpf.org/epub/30/spec/epub30-publications-20110516.html
Latest version
http://www.idpf.org/epub/30/spec/epub30-publications.html
Previous version
http://www.idpf.org/epub/30/spec/epub30-publications-20110506.html

A diff of changes from the previous Working Draft is available at this link.

Editors

Markus Gylling, DAISY Consortium

William McCoy, International Digital Publishing Forum (IDPF)

Matt Garrish, Invited Expert

Table of Contents

1. Overview
1.1. Purpose and Scope
1.2. Terminology
1.3. Conformance Statements
2. EPUB Publications
2.1. Content Conformance
2.2. Reading System Conformance
3. Package Documents
3.1. Introduction
3.2. Content Conformance
3.3. Reading System Conformance
3.4. Package Document Definition
3.4.1. The package Element
3.4.2. The metadata Element
3.4.3. The DCMES identifier Element
3.4.4. The DCMES title Element
3.4.5. The DCMES language Element
3.4.6. The meta Element
3.4.7. The link Element
3.4.8. The manifest Element
3.4.9. The item Element
3.4.10. The spine Element
3.4.11. The itemref Element
3.4.12. The guide Element [DEPRECATED]
3.4.13. The bindings Element
3.4.14. The mediaType Element
4. Package Metadata
4.1. Publication Identifiers
4.1.1. Unique Identifier
4.1.2. Package Identifier
4.2. Dublin Core Metadata Vocabulary Transition
4.3. Metadata Properties
4.3.1. Overview
4.3.2. Metadata meta Properties
4.3.2.1. DCTERMS
4.3.2.2. Package
4.3.2.3. Ancillary
4.3.3. Metadata link Properties
4.3.4. Manifest item Properties
4.3.5. Spine itemref Properties
5. Publication Resources
5.1. Core Media Types
5.2. Restrictions and Fallbacks
5.2.1. Foreign Resource Restrictions
5.2.2. Manifest Fallbacks
5.3. Publication Resource Locations
5.4. XML Conformance
A. Package Document Schema
B. Acknowledgements and Contributors
References

 1 Overview

 1.1 Purpose and Scope

This section is informative

This specification, EPUB Publications 3.0, defines publication-level semantics and conformance requirements for EPUB® 3, including the format of the Package Document and rules for how this document and other Publication Resources are associated to create a conforming EPUB Publication.

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

  • The EPUB 3 Overview [EPUB3Overview], which should be read first, provides an informative overview of EPUB and a roadmap to the rest of the EPUB 3 documents.

  • EPUB Content Documents 3.0 [ContentDocs30], which defines profiles of XHTML, SVG and CSS for use in the context of EPUB Publications.

  • EPUB Open Container Format (OCF) 3.0 [OCF3], which defines a file format and processing model for encapsulating a set of related resources into a single-file (ZIP) EPUB Container.

  • EPUB Media Overlays 3.0 [MediaOverlays30], which defines a format and a processing model for synchronization of text and audio.

This specification supersedes Open Package Format 2.0.1 [OPF2]. Refer to [EPUB3Changes] for information on differences between this specification and its predecessor.

 1.2 Terminology

EPUB Publication (or Publication)

A logical document entity consisting of a set of interrelated resources and packaged in an EPUB Container, as defined by this specification and its sibling specifications.

Publication Resource

A resource that contains content or instructions that contribute to the logic and rendering of the EPUB Publication. In the absence of this resource, the Publication may not render as intended by the Author. Examples of Publication Resources include the Package Document, EPUB Content Documents, EPUB Style Sheets, audio, video, images, embedded fonts and scripts.

With the exception of the Package Document itself, Publication Resources must be listed in the manifest and must be bundled in the EPUB container file unless specified otherwise in Publication Resource Locations.

Examples of resources that are not Publication Resources include those identified by the Package Document link element and third-party resources identified by outbound hyperlinks (e.g., identified in [HTML5] a element href attributes).

Foreign Resource

A Publication Resource that is not a Core Media Type. A Foreign Resource requires at least one fallback, as defined in Restrictions and Fallbacks.

Core Media Type Resource

A Publication Resource that is a Core Media Type and may therefore be included in the EPUB Publication without the provision of fallbacks.

EPUB Content Document

A Publication Resource that conforms to one of the EPUB Content Document definitions (XHTML or SVG).

An EPUB Content Document is a Core Media Type, and may therefore be included in the EPUB Publication without the provision of fallbacks.

XHTML Content Document

An EPUB Content Document conforming to the profile of [HTML5] defined in XHTML Content Documents [ContentDocs30].

XHTML Content Documents use the XHTML syntax of [HTML5].

SVG Content Document

An EPUB Content Document conforming to the constraints expressed in SVG Content Documents [ContentDocs30].

EPUB Navigation Document

A specialization of the XHTML Content Document, containing human- and machine-readable global navigation information, conforming to the constraints expressed in EPUB Navigation Documents [ContentDocs30].

Scripted Content Document

An EPUB Content Document that includes scripting or an XHTML Content Document that contains HTML5 forms elements.

Refer to Scripted Content Documents [ContentDocs30] for more information.

Top-level Content Document

An EPUB Content Document referenced directly from the spine

Core Media Type

A set of Publication Resource types for which no fallback is required. Refer to Publication Resources for more information.

Package Document

A Publication Resource carrying bibliographical and structural metadata about the EPUB Publication, as defined in Package Documents.

Manifestation

The digital (or physical) embodiment of a work of intellectual content. Changes to the content such as significant revision, abridgement, translation, or the realization of the content in a different digital or physical form result in a new manifestation. There may be many individual but identical copies of a manifestation, termed 'instances' or 'items'. The ISBN is an example of a manifestation identifier, and is shared by all instances of that manifestation.

All instances of a manifestation need not be bit-for-bit identical, as minor corrections or revisions are not judged to create a new manifestation or work.

Unique Identifier

The Unique Identifier is the primary identifier for an EPUB Publication, as identified by the unique-identifier attribute. The Unique Identifier may be shared by one or many Manifestations of the same work that conform to the EPUB standard and embody the same content, where the differences between the Manifestations are limited to those changes that take account of differences between EPUB Reading Systems (and which themselves may require changes in the ISBN).

The Unique Identifier is less granular than the ISBN. However, significant revision, abridgement, etc. of the content requires a new Unique Identifier.

Package Identifier

The Package Identifier allows any instance of an EPUB Publication to be compared against another to determine if they are identical, different versions of the same Manifestation, or unrelated.

Refer to Package Identifier for more information.

Manifest

A list of all Publication Resources that constitute the EPUB Publication.

Refer to manifest for more information.

Spine

An ordered list of Publication Resources, typically EPUB Content Documents, representing the default reading order of the Publication.

Refer to spine for more information.

Media Overlay Document

An XML document that associates the XHTML Content Document with pre-recorded audio narration in order to provide a synchronized playback experience, as defined in [MediaOverlays30].

Text-to-Speech (TTS)

The rendering of the textual content of an EPUB Publication as artificial human speech using a synthesized voice.

EPUB Style Sheet (or Style Sheet)

A CSS Style Sheet conforming to the CSS profile defined in EPUB Style Sheets [ContentDocs30].

Viewport

The region of an EPUB Reading System in which the content of an EPUB Publication is rendered visually to a User.

CSS Viewport

A Viewport capable of displaying CSS-styled content.

EPUB Container (or Container)

The ZIP-based packaging and distribution format for EPUB Publications defined in [OCF3].

Author

The person(s) or organization responsible for the creation of an EPUB Publication, which may or may not be the creator of the content and resources it contains.

User

An individual that consumes an EPUB Publication using an EPUB Reading System.

EPUB Reading System (or Reading System)

A system that processes EPUB Publications for presentation to a User in a manner conformant with this specification and its sibling specifications.

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

 2 EPUB Publications

This section defines conformance requirements for EPUB Publications and EPUB Reading Systems at the Publication level. Conformance requirements particular to specific Publication Resources and processing contexts are located in the specifications referenced herein.

 2.1 Content Conformance

An EPUB Publication must meet all of the following criteria:

All Publication Resources

 All Publication Resources it contains must be represented in the Package Document (as defined in manifest), adhere to the constraints for Core Media Types and Fallback and be located as per Publication Resource Locations.

The Package Document

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

Content Documents

 It must contain at least one EPUB Content Document conformant to the content requirements defined in EPUB Content Documents [ContentDocs30].

The EPUB Navigation Document

 It must contain exactly one EPUB Navigation Document conformant to the content requirements defined in EPUB Navigation Documents — Content Conformance [ContentDocs30].

EPUB Style Sheets

 It may contain zero or more EPUB Style Sheets conformant to the content requirements defined in EPUB Style Sheets — Content Conformance [ContentDocs30].

EPUB Pronunciation Lexicons

 It may contain zero or more PLS Documents conformant to the content requirements defined in PLS Documents — Content Conformance [ContentDocs30].

Media Overlay Documents

 It may contain zero or more Media Overlay Documents conformant to the content requirements defined in [MediaOverlays30].

Additional Publication Resources

 It may contain zero or more Publication Resources in addition to those listed above, each of which must adhere to the requirements in All Publication Resources.

Container

 It must be packaged in a EPUB Container as defined in [OCF3].

 2.2 Reading System Conformance

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

EPUB 3 Processing

 It must process the EPUB Container as defined in [OCF3].

 It must process the Package Document as defined in Package Document — Reading System Conformance, and honor all presentation logic expressed through the Package Document (e.g., the reading order, fallback chains and bindings).

 It must not fail catastrophically if it encounters two distinct EPUB Publications with the same Unique Identifiers.

 Unless specified as conditional behavior in this section, it must support all Core Media Type Resources.

 It may support an arbitrary set of Foreign Resource types, and must process fallbacks for unsupported Foreign Resources as defined in Restrictions and Fallbacks if not.

 It must process XHTML Content Documents as defined in XHTML Content Documents — Reading System Conformance [ContentDocs30].

 It must process SVG Content Documents as defined in SVG Content Documents — Reading System Conformance [ContentDocs30].

 If it has a CSS Viewport, it must support visual rendering of XHTML Content Documents as defined in EPUB Style Sheets — Reading System Conformance [ContentDocs30].

 If it has the capability to render raster images, it must support the raster image Core Media Types.

 If it has the capability to render vector images, it must support the vector image Core Media Types.

 If it has the capability to render pre-recorded audio, it must support the MP3 audio Core Media Type, should support the MP4 audio Core Media Type and should support Media Overlays [MediaOverlays30].

 If it supports Text-to-Speech (TTS) rendering, it should support PLS Documents [ContentDocs30], the CSS3 Speech features of the EPUB CSS Profile [ContentDocs30] and SSML attributes [ContentDocs30] in XHTML Content Documents.

 It must support the EPUB Canonical Fragment Identifiers scheme [EPUBCFI] for linking.

note

It is recommended that Reading Systems support at least one of the [H.264] and [VP8] video codecs, but this is not a conformance requirement; a Reading System may support no video codecs at all. Content creators and Reading System developers should take into consideration factors such as breadth of adoption, video playback quality, and technology usage royalty requirements when making a choice to include or implement video in either (or potentially, both) formats.

Backward Compatibility

 It should process EPUB version 2 Publications as defined in [OPF2], [OPS2] and [OCF2].

 It must attempt to process any Publication whose Package Document version attribute designates a version lower than 3.0 or which omits the version attribute.

Forward Compatibility

 It should attempt to process any Publication whose Package Document version attribute designates a version higher than 3.0 or which omits the version attribute.

XML Processing

 It must be a conformant non-validating processor [XML].

  It must be a conformant processor as defined in [XMLNS].

 It must support xml-stylesheet processing instructions [ASSOCSS], and may support additional processing instructions.

 It must be a conformant application as defined by [XML Base].

note

A conforming Reading System is not necessarily a single dedicated program or device, but may exist as a distributed system.

 3 Package Documents

 3.1 Introduction

This section is informative

The Package Document carries bibliographic and structural metadata about an EPUB Publication, and is thus the primary source of information about how to process and display it.

The Package Document is an XML document consisting of a set of container elements, each dedicated to housing information about a particular aspect of the Publication. These containers effectively centralize metadata for the Publication, detail the individual resources that compose it and provide reading order and other information for rendering the Publication to a User.

The following list summarizes the information a Package Document contains:

  • Publication metadata — mechanisms for including and/or referencing metadata applicable to the entire Publication and particular resources within it.

  • A Publication manifest — identifies (via IRI) and describes (via MIME media type) the set of resources that collectively compose the Publication.

  • A spine — an ordered sequence of ID references to top-level resources in the manifest from which all other resources in the set can be reached or utilized. The spine defines the default reading order of the Publication.

  • Fallback chains — an optional means for Publications to define an ordered list of top-level resources that can be considered content equivalents that a Reading System can choose between for rendering.

  • Bindings — an optional means of associating script-based implementations with custom media types.

 3.2 Content Conformance

A Package Document must meet all of the following criteria:

Document Properties

  It must meet the conformance constraints for XML documents defined in XML Conformance.

 It must be valid to the Package Document schema, as defined in Appendix A, Package Document Schema, and conform to all content conformance constraints expressed in Package Document Definition.

File Properties

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

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

 3.3 Reading System Conformance

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

Processing

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

 3.4 Package Document Definition

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

 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.

Element Name

package

Usage

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

Attributes
version [required]

Specifies the EPUB specification version to which the Publication conforms.

The attribute must have the value 3.0 to indicate compliance with this version of the specification.

unique-identifier [required]

An IDREF [XML] that identifies the dc:identifier element that provides the package's preferred, or primary, identifier.

Refer to Publication Identifiers for more information.

profile [required]

Specifies the URI of the metadata profile [RDFa11 Core] for the Package Document.

The attribute must have the value http://www.idpf.org/epub/30/profile/package/ [PackageProfile] to comply with this version of the specification.

Refer to metadata for more information.

prefix [optional]

Declares additional metadata vocabulary prefixes not defined in the metadata profile [RDFa11 Core].

Refer to metadata for more information.

xml:lang [required]

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

dir [optional]

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

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

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

id [optional]

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

Content Model

In this order: metadata [required], manifest [required], spine [required], guide [optional/deprecated], bindings [optional]

 3.4.2 The metadata Element

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

Element Name

metadata

Usage

Required first child of package.

Attributes

The metadata element has no attributes defined in this specification.

Content Model

In any order: dc:identifier [1 or more], dc:title [1 or more], dc:language [exactly 1], meta [1 or more], link [0 or more]

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 [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 contain only 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 prefixes for other common vocabularies (refer to the profile for more information on which).

If the metadata profile does not define a prefix for a needed vocabulary, it does not mean 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.

The following example shows how to define a new prefix for a vocabulary.

<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

The following example represents the minimal set of metadata that all Publications must contain.

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

Element Name

dc:identifier

Namespace

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

Usage

Required child of metadata. Repeatable.

Attributes
id [required]

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

prefer [optional]

An IDREF [XML] that identifies the meta element containing the equivalent [DCTERMS] property. Reading Systems should use the referenced property in preference to the current element when processing the metadata for an EPUB Publication.

Content Model

Text

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.

The following example shows the unique identifier element for a Publication.

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

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.

The following example shows how an identifier element and property should co-exist within a Publication.

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

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 a scheme property to the identifier to assist in Reading System identification. When included, the scheme property should take precedence over value parsing the identifier.

The following example shows how an identifier can be additionally marked as a DOI using the scheme property.

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

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 source-identifier property if included.

 3.4.4 The DCMES title Element

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

Element Name

dc:title

Namespace

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

Usage

Required child of metadata. Repeatable.

Attributes
id [optional]

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

prefer [optional]

An IDREF [XML] that identifies the meta element containing the equivalent [DCTERMS] property. Reading Systems should use the referenced property in preference to the current element when processing the metadata for an EPUB Publication.

Content Model

Text

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.

The following example shows how to indicate the display order for multiple title elements.

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

The following example shows the primary title specified using an ONIX code list.

<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/ONIX/book/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.

The following example shows how a title element and property should co-exist within a Publication.

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

Element Name

dc:language

Namespace

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

Usage

Required child of metadata.

Attributes
prefer [optional]

An IDREF [XML] that identifies the meta element containing the equivalent [DCTERMS] property. Reading Systems should use the referenced property in preference to the current element when processing the metadata for an EPUB Publication.

Content Model

Text

Every metadata section must include a single language element with a value conforming to [RFC5646].

The following example shows a Publication in U.S. English.

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

The following example shows how a language element and property should co-exist within a Publication.

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

Element Name

meta

Usage

As child of the metadata element. Repeatable.

Attributes
property [required]

A CURIE [RDFa11 Core] that resolves to a term in one of the vocabularies defined in the metadata profile or package element prefix attribute.

Refer to Metadata meta Properties for a set of properties defined by this specification.

about [context dependent]

Identifies the subject of the property being expressed. The value of the attribute must be a relative IRI [RFC3987] pointing to the resource or element it describes.

The about attribute is optional depending on the type of metadata being expressed. When omitted, the property relates to the EPUB Publication as a whole.

id [optional]

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

datatype [context dependent]

A CURIE [RDFa11 Core] that resolves to a datatype definition, such as defined in [XSD-DATATYPES].

The datatype attribute is optional except when a scheme is being expressed, in which case it is required.

Content Model

Text

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. Reading Systems are not required to resolve these CURIEs.

The following example shows an identifier being declared for the Publication in the first meta element and a scheme being defined for the identifier in the second.

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

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 (refer to 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

The following example shows metadata expressed using meta elements (the DCMES elements have been omitted for clarity).

<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/ONIX/book/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>

The following example shows how the complex title "The Great Cookbooks of the World: Mon premier guide de cuisson, un Mémoire. The New French Cuisine Masters, Volume Two. Special Anniversary Edition" could be classified.

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

The following example shows an identifier that has been issued by a metadata authority.

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

Element name

manifest

Usage

Required second child of package, following metadata.

Attributes
id [optional]

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

Content Model

One or more item elements [required]

note

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

 3.4.9 The item Element

The item element represents a Publication Resource.

Element Name

item

Usage

As a child of manifest. Repeatable.

Attributes
id [required]

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

href [required]

An IRI [RFC3987] specifying the location of the Publication Resource described by this item.

media-type [required]

A media type [RFC2046] that specifies the type and format of the Publication Resource described by this item.

fallback [conditionally required]

An IDREF [XML] that identifies the fallback for a non-Core Media Type.

Refer to Manifest Fallbacks for more information.

properties [optional]

A space-separated list of CURIEs [RDFa11 Core] that each resolve to a term in one of the vocabularies defined in the metadata profile or package element prefix attribute.

Refer to Manifest item Properties for a set of properties defined by this specification.

media-overlay [optional]

An IDREF [XML] that identifies the Media Overlay Document for the resource described by this item.

Refer to Packaging [MediaOverlays30] for more information.

Content Model

Empty

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 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 an item element that refers to the Package Document itself.

note

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

Examples

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

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

The following example shows a manifest that references two Foreign Resources, and therefore uses the fallback chain mechanism to supply content alternatives. The fallback chain terminates with a Core Media Type.

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

note

Refer also to the Manifest item properties examples for use of the properties attribute.

 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.

Element name

spine

Usage

Required third child of package, following manifest.

Attributes
id [optional]

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

toc [optional]

An IDREF [XML] that identifies the manifest item that represents the superseded NCX.

Refer to NCX Superseded for more information.

page-progression-direction

The global direction in which the Publication content flows.

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

When the default value is specified, the Author is expressing no preference and the Reading System may chose the rendering direction. This value must be assumed when the attribute is not specified.

Content Model

Multiple itemref elements [required]

note

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

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.

note

As the EPUB 2 NCX and the EPUB 3 Navigation Document use different mechanisms for identification in the Package Document (the spine toc attribute and the nav property on the manifest item element, respectively) they can co-exist without conflict in an EPUB 3 Publication.

 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.

Element Name

itemref

Usage

As a child of spine. Repeatable.

Attributes
idref [required]

An IDREF [XML] that identifies a manifest item.

linear [optional]

Specifies whether the referenced content is primary.

The value of the attribute must be yes or no. The default value yes.

id [optional]

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

properties [optional]

A space-separated list of CURIEs [RDFa11 Core] that each resolve to a term in one of the vocabularies defined in the metadata profile or package element prefix attribute.

Refer to Spine itemref Properties for a set of properties defined by this specification.

Content Model

Empty

Each itemref element must reference an item in the manifest via its idref attribute. As a result, 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.

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.

note

Although the EPUB Navigation Document is required in EPUB Publications, it is optional to include it in the spine.

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

Examples

The following example shows a spine element corresponding to the manifest example above.

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

Element Name

bindings

Usage

Optional fourth or fifth child of package, following spine or guide.

Attributes

None.

Content Model

One or more mediaType elements [required]

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:

src

the value of which must be an IRI [RFC3987] to the resource (i.e., the value of the object element's data attribute).

type

the value of which must be the resource media type (i.e., the value of the object element's media-type attribute).

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:

  • If the Reading System supports the native slideshow format, it will render a rotating set of images as specified in slideshow.xml.

  • If the Reading System cannot support the slideshow media type but supports scripting, it can check the bindings element in the Package Document for a scripted fallback. There it will find a reference to the item element containing the handler document (impl.xhtml). The Reading System can now load this document to render a JavaScripted equivalent of the slideshow (source not shown).

  • If the Reading System does not support the slideshow media type and also does not support scripting, it will use the fallback images specified in the object element to show a static set of all the images.

 3.4.14 The mediaType Element

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

Element Name

mediaType

Usage

As a child of bindings. Repeatable.

Attributes
media-type [required]

A media type [RFC2046] that specifies the type and format of the resource to be handled.

handler [required]

An IDREF [XML] that identifies the manifest XHTML Content Document to be invoked to handle content of the type specified in this element

Content Model

Empty

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

 4.1 Publication Identifiers

 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.

The following example shows how a Unique Identifier and modification date are combined to form the Package Identifier.

<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 Dublin Core Metadata Vocabulary Transition

This specification represents a shift from using traditional XML-based grammars to express Publication metadata to an approach based on a standardized syntax that incorporates well-defined terms from external vocabularies. Unlike XML grammars, which intrude into host grammars, often require special extensions and require learning the new grammar to implement, the new approach represents a more fluid means of expressing metadata: a few container elements are now capable of expressing the full range of Publication metadata and provide a predictable way to add and extend using industry-standard vocabularies.

Although support for the expression of metadata allows properties from a wide variety of vocabularies to be easily incorporated to express and refine information about an EPUB Publication, it is not expected that all Reading Systems will be able to handle this transition initially. To ensure that older Reading Systems that require the presence of the required [DCMES] elements do not fail to open new EPUB Publications, this specification represents a transitionary stage, incorporating both methods of metadata expression.

While this specification requires the use of the DCMES title, identifier and language elements, their deprecation is expected in a future version. Content authors are consequently strongly encouraged to begin using the new properties from the DCTERMS vocabulary, including the properties that supersede the required DCMES elements. The prefer attribute has been added to each DCMES element to allow authors to designate the new property that replaces the element during this transitionary phase, which also ensures that EPUB Publications created to this specification will continue to function when element support is phased out.

 4.3 Metadata Properties

 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.

note

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

 4.3.2 Metadata meta Properties

 4.3.2.1 DCTERMS

The meta element property attribute may define any property from DCMI Metadata Terms [DCTERMS] for expressing metadata about the package and its contents.

For more information about these properties and their use, please refer to the vocabulary.

For specific restrictions and requirements imposed by this specification on the language and modified properties, refer to dc:language and Package Identifier, respectively.

 4.3.2.2 Package

Package properties define Publication-level metadata. They must not be attached to other metadata elements or properties (i.e., their parent meta element must not contain an about attribute).

The cardinality property in the following tables refers to the number of instances of the property that may be included in the metadata element.

The following tables detail the available properties.

publication-type
Description:

The publication-type property indicates 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 property; the development of specialized Publication types, and the assignment of formal identifiers to represent them, will occur independently of this specification.

Allowed value(s):xsd:string
Cardinality:zero or one
Example: <meta property="publication-type">dictionary</meta>
source-identifier
Description:

The source-identifier property specifies the identifier of the source publication this EPUB Publication represents.

Refer to dc:identifier for more information.

Allowed value(s): xsd:string
Cardinality:zero or one
Example: <meta property="source-identifier">urn:isbn:9780375704024</meta>
 4.3.2.3 Ancillary

Ancillary properties enhance Publication metadata by providing additional level(s) of detail.

Ancillary properties must reference the metadata element or property they augment through the about attribute on their parent meta element.

The following tables detail the available properties.

alternate-script
Description:

The alternate-script property provides an alternate expression of the associated property value in a language and script identified by the xml:lang attribute.

This property is typically attached to creator and title properties for internationalization purposes.

Allowed value(s): xsd:string
Cardinality:

In the metadata section: zero or more

Attached to other metadata: zero or one

Extends:All properties.
Example: <meta about="#creator" property="alternate-script" xml:lang="ja">村上 春樹</meta>
display-seq
Description:The display-seq property indicates the numeric position in which to display the current property relative to identical metadata properties (e.g., to indicate the order in which to render multiple titles).
Allowed value(s): xsd:unsignedInt
Cardinality:

In the metadata section: zero or more

Attached to other metadata: zero or one

Extends:All properties.
Example: <meta about="#t2" property="display-seq">1</meta>
file-as
Description:The file-as property provides the normalized form of the associated property for sorting.
Allowed value(s): xsd:string
Cardinality:

In the metadata section: zero or more

Attached to other metadata: zero or one

Extends:All properties.
Example: <meta about="#creator" property="file-as">Murakami, Haruki</meta>
group-position
Description:

The group-position property indicates the numeric position in which the Publication is ordered relative to other works belonging to the same group (whether all EPUBs or not).

The group-position property can be attached to any metadata property that establishes the group (such as a series title) or can be attached to an isPartOf property [DCTERMS] whose value defines the group.

A Publication can belong to more than one group.

Allowed value(s): A single xsd:unsignedInt or series of decimal-separated numbers (e.g., 1 or 2.2.1).
Cardinality:

In the metadata section: zero or more

Attached to other metadata: zero or one

Extends: All properties.
Example: <meta about="#t3" property="group-position">2</meta>
meta-auth
Description:The meta-auth property provides the name of a party or authority responsible for an instance of package metadata.
Allowed value(s): xsd:string
Cardinality:

In the metadata section: zero or more

Attached to other metadata: zero or one

Extends:All properties.
Example: <meta about="isbn-id" property="meta-auth" id="meta-authority-01">Metadata Authority Inc.</meta>
role
Description:

The role property describes the nature of work performed by a creator or contributor (e.g., that the person is the author or editor of a work).

When the role value is drawn from a code list or other formal enumeration, the scheme property should be attached to identify its source.

Allowed value(s):xsd:string
Cardinality:

In the metadata section: zero or more

Attached to other metadata: zero or one

Extends: contributor, creator
Example: <meta about="#creator" property="role" id="role">aut</meta> <meta about="#role" property="scheme" datatype="xsd:anyURI">http://id.loc.gov/vocabulary/relators</meta>
scheme
Description:

The scheme property identifies the formal system used to express the value of the associated property, or the code list or other identification system from which it is drawn.

The value of the scheme property must be a URI [RFC3986] or string value that identifies the system. URIs used to identify systems are not required to resolve to a resource.

Each meta element that defines a scheme must include a datatype attribute that identifies whether its value is a string or URI.

Allowed value(s):xsd:string | xsd:anyURI
Cardinality:

In the metadata section: zero or more

Attached to other metadata: zero or one

Extends: All properties.
Example: <meta about="#pub-id" property="scheme" datatype="xsd:string">uuid</meta>
title-type
Description:

The title-type property indicates the form or nature of a title.

When the title-type value is drawn from a code list or other formal enumeration, the scheme property should be attached to identify its source.

Allowed value(s):xsd:string
Extends:title
Cardinality:

In the metadata section: zero or more

Attached to other metadata: zero or one

Example: <meta about="#title" property="title-type" id="title-type">01</meta> <meta about="#title-type" property="scheme" datatype="xsd:anyURI">http://www.editeur.org/ONIX/book/codelists/current.html#codelist15</meta>

 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.

cover-image
Description:The cover-image property identifies the described Publication Resource as the cover image for the Publication.
Applies to:All raster and vector image types
Cardinality:Zero or one
Usage:Optional.
mathml
Description:The mathml property indicates that the described Publication Resource contains one or more instances of MathML markup.
Applies to:EPUB Content Documents
Cardinality:Zero or more
Usage:Must be set if and only if the criterion specified in Description above is met.
nav
Description:The nav property indicates that the described Publication Resource constitutes the EPUB Navigation Document of the Publication.
Applies to:The EPUB Navigation Document
Cardinality:Exactly one
Usage:Required.
remote-resources
Description:

The remote-resources property indicates that the described Publication Resource contains one or more internal references to other Publication Resources that are located outside of the EPUB Container.

(refer to Publication Resource Locations for more information).

Applies to:All Publication Resources with the capability of internal referencing (e.g., XHTML Content Documents, SVG Content Documents, EPUB Style Sheets and Media Overlay Documents).
Cardinality:Zero or more
Usage:Must be set if and only if the criterion specified in Description above is met.
scripted
Description:The scripted property indicates that the described Publication Resource is a Scripted Content Document (i.e., contains scripted content and/or elements from HTML5 forms).
Applies to:EPUB Content Documents
Cardinality:Zero or more
Usage:Must be set if and only if the criterion specified in Description above is met.
svg
Description:The svg property indicates that the described Publication Resource contains one or more instances of SVG markup.
Applies to:XHTML Content Documents; the value is implied for SVG Content Documents.
Cardinality:Zero or more
Usage:Must be set if and only if the criterion specified in Description above is met.
switch
Description:The switch property indicates that the described Publication Resource contains one or more instances of the epub:switch element.
Applies to:XHTML Content Documents.
Cardinality:Zero or more
Usage:Must be set if and only if the criterion specified in Description above is met.

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 also must be specified if any content included in the resource matches their definition (i.e., each layer of included content must be checked). 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, or if it includes a non-scripted Content Document that includes a scripted Content Document, and so on.

Examples

The following example shows a manifest item element that represents the EPUB Navigation Document of a Publication.

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

The following example shows a manifest item element that represents the cover image of a Publication.

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

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

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

 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.

page-spread-left
Description:The page-spread-left property indicates that the first page of the associated item's EPUB Content Document represents the left-hand side of a two-page spread.
Cardinality:Zero or more
Usage:Optional. This property must not be specified on an itemref that also specifies the page-spread-right property.
page-spread-right
Description:The page-spread-right property indicates that the first page of the associated item's EPUB Content Document represents the right-hand side of a two-page spread.
Cardinality:Zero or more
Usage:Optional. This property must not be specified on an itemref that also specifies the page-spread-left property.

Examples

The following example shows how a two-page spread of a map might be indicated in the spine.

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

 5.1 Core Media Types

The following table lists the EPUB 3 Core Media Types. When a Publication Resource conforms to a Core Media Type specification, it is a Core Media Type Resource and can be included in the Publication without the provision of fallbacks (refer to Restrictions and Fallbacks for more information).

The columns in the table represent the following information:

Media Type

The MIME media type [RFC2046] used to represent the given Publication Resource in the manifest.

Content Type Definition

The specification to which the given Core Media Type Resource must conform.

Applies to

The Publication Resource type(s) that the Media Type and Content Type Definition applies to.

EPUB Core Media Types
Media Type Content Type Definition Applies to
Image Types
image/gif [GIF] GIF Images
image/jpeg [JPEG] JPEG Images
image/png [PNG] PNG Images
image/svg+xml SVG Content Documents [ContentDocs30] SVG documents
Application Types
application/xhtml+xml XHTML Content Documents [ContentDocs30] XHTML Content Documents and the EPUB Navigation Document.
application/x-dtbncx+xml [OPF2] The superseded NCX
application/vnd.ms-opentype [OpenType] OpenType fonts
application/font-woff [WOFF] WOFF fonts
application/smil+xml [MediaOverlays30] EPUB Media Overlay documents
application/pls+xml [PLS] Text-to-Speech (TTS) Pronunciation lexicons
Audio Types
audio/mpeg [MP3] MP3 audio
audio/aac [MP4 AAC LC] MP4 AAC LC audio
Text Types
text/css EPUB Style Sheets [ContentDocs30] EPUB Style Sheets.
text/javascript [RFC4329] Scripts

note

This specification does not define any video codecs as Core Media Types. Refer to the note in EPUB Publications — Reading System Conformance above for informative recommendations on support for video codecs in EPUB Publications.

 5.2 Restrictions and Fallbacks

 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.

Intrinsic Fallback in EPUB Content Documents

 Foreign Resources may be referenced from EPUB Content Document elements that have explicit intrinsic fallback mechanisms (e.g., the [HTML5] object, canvas, audio and video elements). A Core Media Type resource must be provided via the given element's intrinsic fallback mechanism in such cases.

 For the [HTML5] video element, the image referenced by the poster attribute and text content embedded within the video element also are considered valid Core Media Type fallbacks in addition to the video element's intrinsic fallback capabilities. For the purpose of providing a last resort fallback for Reading Systems that do not support video or the given video format(s), at least one of these should be included with each occurrence of the video element.

 For the [HTML5] audio element, text content embedded within the element also is considered a valid Core Media Type fallback in addition to the audio element's intrinsic fallback capabilities. For the purpose of providing a last resort fallback for Reading Systems that do not support audio, embedded text content should be included with each occurrence of the audio element.

  In this version of this specification, the [HTML5] track element is exempt from the Core Media Type usage rule: Foreign Resources may be referenced from track without the provision of a Core Media Type fallback.

Intrinsic Fallback in EPUB Style Sheets

 Fonts embedded in Content Documents or EPUB Style Sheets using the @font-face mechanism may be Foreign Resources. Reading Systems must use the rules for matching font styles [CSS3Fonts] when identifying a fallback for an unsupported font type.

Spine Resources

 Foreign Resources may be referenced directly from spine itemref elements, and in this case Manifest fallbacks must be provided.

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

 5.3 Publication Resource Locations

All Publication Resources must be located in the EPUB Container, with the following exceptions:

  •  Audio resources may be located in the Container or remotely.

  •  Video resources may be located in the Container or remotely.

Authors should prefer locating audio and video resources in the Container to allow the user access to the entire presentation regardless of connectivity status.

note

The above rules for Publication Resource locations apply regardless of whether the given resource is a Core Media Type Resource or a Foreign Resource.

note

The inclusion of remote resources in an EPUB Publication is indicated via the remote-resources property on the manifest item element.

 5.4 XML Conformance

Any Publication Resource which is an XML-Based Media Type must meet the following constraints:

The above constraints apply regardless of whether the given Publication Resource is a Core Media Type Resource or a Foreign Resource.

 Appendix A. Package Document Schema

The schema for Package Documents is available at http://www.idpf.org/epub/30/schema/package-30.nvdl.

This schema is normative.

note

NOTE: In this release of this specification, the referenced schemas are not complete.

note

Validation using this schema will require a processor that supports [NVDL], [RelaxNG] and [ISOSchematron].

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

 Appendix B. Acknowledgements and Contributors

This appendix is informative

EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.

The EPUB 3 specifications were prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group, operating under a charter approved by the membership in May, 2010 under the leadership of:

Active members of the working group included:

IDPF Members

Invited Experts/Observers

For more detailed acknowledgements and information about contributors to each version of EPUB, refer to Acknowledgements and Contributors [EPUB3Overview].

 References

Normative References

[ASSOCSS] Associating Style Sheets with XML documents 1.0 (Second Edition) . James Clark, et al. 28 October 2010.

[CSS3Fonts] CSS Fonts Module Level 3 . John Daggett.

[ContentDocs30] EPUB Content Documents 3.0 .

[DCTERMS] DCMI Metadata Terms .

[MARC21XML] MARC 21 XML Schema .

[MediaOverlays30] EPUB Media Overlays 3.0 .

[ONIX] ONIX for Books .

[PLS] Pronunciation Lexicon Specification 1.0 (PLS) . Paolo Baggia. 14 October 2008.

[Publications30] EPUB Publications 3.0 .

[RDFa11 Core] RDFa Core 1.1 . Syntax and processing rules for embedding RDF through attributes. Ben Adida, et al. 26 October 2010.

[RFC2046] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (RFC 2046) . N. Freed, N. Borenstein. November 1996.

[RFC3986] Uniform Resource Identifier (URI): Generic Syntax (RFC 3986) . Berners-Lee, et al. January 2005.

[RFC3987] Internationalized Resource Identifiers (IRIs) (RFC 3987) . M Duerst, et al. January 2005.

[RFC5646] Tags for Identifying Languages (RFC 5646) . A. Phillips, M. Davis. September 2009.

[Unicode] The Unicode Consortium. The Unicode Standard, Version 5.0.0, defined by: The Unicode Standard, Version 5.0 (Boston, MA, Addison-Wesley, 2007. ISBN 0-321-48091-0).

[WOFF] WOFF File Format 1.0 . Jonathan Kew, et al.

[XInclude] XML Inclusions (XInclude) Version 1.0 (Second Edition) . J. Marsh, et al. 15 November 2006.

[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition) . T. Bray, et al. 26 November 2008.

[XML Base] XML Base (Second Edition) . Jonathan Marsh, et al. 28 January 2009.

[XML DSIG Core] XML-Signature Syntax and Processing Version 1.1 . M. Bartel, et al. 3 March 2011.

[XMLNS] Namespaces in XML (Third Edition) . T. Bray, D. Hollander, A. Layman, R. Tobin. W3C. 8 December 2009.

[XSD-DATATYPES] XML Schema Part 2: Datatypes Second Edition . Paul V. Biron et al. 28 October 2004.

Informative References

[EPUB3Changes] EPUB 3 Differences from EPUB 2.0.1 . William McCoy, et al.

[EPUB3Overview] EPUB 3 Overview . Garth Conboy, et al.

[RFC4329] Scripting Media Types . B. Höhrmann. April 2006.

[VP8] VP8 Data Format and Decoding Guide . J. Bankoski, et al.