EPUB 3.0 Specification

The documents canonically located at http://idpf.org/epub/30 reproduced in EPUB 3 format

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Terminology

Author

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

EPUB Container (or Container)

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

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.

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.

SVG Content Document

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

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

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.

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.

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.

Manifest

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

Refer to manifest for more information.

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.

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

OCF Processor

A software application that processes EPUB Containers according to this specification.

Package Document

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

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.

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.

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 might 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 those identified in outbound hyperlinks that resolve outside the EPUB Container (e.g., referenced from an [HTML5] a element href attribute).

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.

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.

EPUB Style Sheet (or Style Sheet)

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

Text-to-Speech (TTS)

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

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.

User

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

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.

SVG Viewport

A Viewport capable of displaying SVG images.

EPUB 3 Overview

Recommended Specification 11 October 2011

This version

http://www.idpf.org/epub/30/spec/epub30-overview-20111011.html

Latest version

http://www.idpf.org/epub/30/spec/epub30-overview.html

Previous version

http://www.idpf.org/epub/30/spec/epub30-overview-20110908.html

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

Copyright © 2010, 2011 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Editors

Garth Conboy, Google Inc.

Matt Garrish, Invited Expert

Markus Gylling, DAISY Consortium

William McCoy, International Digital Publishing Forum (IDPF)

MURATA Makoto, JEPA EPUB Study Group

Daniel Weck, DAISY Consortium

Table of Contents

1. Introduction

1.1. Overview

1.2. Roadmap

2. Features

2.1. Package Document

2.2. Navigation

2.2.1. Reading Order

2.2.2. Navigation Document

2.3. Linking

2.4. Metadata

2.5. Content Documents

2.6. Rendering and CSS

2.7. Multimedia

2.8. Fonts

2.9. Scripting

2.10. Text-to-speech

2.11. Container

3. Global Language Support

3.1. Metadata

3.2. Content Documents

3.3. CSS

3.4. Fonts

3.5. Text-to-speech

3.6. Container

4. Accessibility

4.1. Navigation

4.2. Semantic Markup

4.3. Dynamic Layouts

4.4. Aural Renditions and Media Overlays

4.5. Fallbacks

4.6. Scripting

› 1 Introduction

› 1.1 Overview

The EPUB® specification is a distribution and interchange format standard for digital publications and documents. EPUB defines a means of representing, packaging and encoding structured and semantically enhanced Web content — including HTML5, CSS, SVG, images, and other resources — for distribution in a single-file format.

EPUB 3, the third major release of the standard, consists of a set of four specifications, each defining an important component of an overall EPUB Publication:

EPUB Publications 3.0 [Publications30], which defines publication-level semantics and overarching conformance requirements for EPUB Publications.

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.

EPUB has been widely adopted as the format for digital books (eBooks), and these new specifications significantly increase the format's capabilities in order to better support a wider range of publication requirements, including complex layouts, rich media and interactivity, and global typography features. The expectation is that EPUB 3 will be utilized for a broad range of content, including books, magazines and educational, professional and scientific publications.

This document provides a starting point for content authors and software developers wishing to understand these specifications. It consists of non-normative overview material, including a roadmap to the four building-block specification documents that compose EPUB 3.

Another non-normative document, EPUB 3 Changes from EPUB 2.0.1 [EPUB3Changes], describes changes in EPUB 3 from the previous version, but is intended primarily for Authors and EPUB Reading System vendors migrating from EPUB 2.0.1 to EPUB 3 and for those who anticipate supporting both versions.

› 1.2 Roadmap

This section provides an overview of the EPUB 3 specifications by explaining in brief the components of a Publication. Links to additional information within this document and to the specifications are included.

An EPUB Publication, at its most basic level, is a bundled collection of resources that can be reliably and predictably ingested by an EPUB Reading System in order to render its contents to a User. Some of these resources facilitate the discovery and processing of the EPUB Publication, while others make up the content of the source publication. The latter, EPUB Content Documents, are described in Content Documents and are fully defined in [ContentDocs30].

A Publication's resources are typically bundled for distribution as a ZIP-based archive with the file extension .epub. As conformant ZIP archives, Publications can be unzipped by many software programs, simplifying both their production and consumption. The container format is introduced in Container and defined in [OCF3].

The container format not only provides a means of determining that the zipped content represents an EPUB Publication (the mimetype file), but also provides a universally-named directory of informative resources (/META-INF). Key among these is the container.xml file, which directs Reading Systems to the root file of the Publication, the Package Document.

The Package Document is itself a kind of information warehouse for the Publication, storing metadata about the specific work contained in the Publication, providing an exhaustive list of resources and defining a default reading order. The Package Document is introduced in Package Document and defined in [Publications30].

The preceding components of an EPUB Publication are not new to EPUB 3, and will be familiar to anyone who has worked with Publications before, although they have been changed and enhanced in this version. A new core addition to EPUB 3, however, is the Media Overlay Document, which defines a means of synchronizing text and audio playback. The Overlay Document is introduced in Multimedia and defined in [MediaOverlays30].

The following example shows the resources a minimal "Hello World" Publication might contain:

mimetype
META-INF/container.xml
Content/HelloWorld.opf
Content/HelloWorld.xhtml

While conceptually simple, an EPUB Publication is more than just a collection of HTML pages and dependent assets in a ZIP package as represented in this example. The following sections of this document delve into more detail about the primary features and functionality that Publications provide to enhance the reading experience.

› 2 Features

This section covers the major features of EPUB, including important components and topics that apply to the process of authoring EPUB Publications as a whole.

› 2.1 Package Document

Every EPUB Publication includes a single Package Document, which specifies all the Publication's constituent content documents and their required resources, defines a reading order for linear consumption, and associates Publication-level metadata and navigation information.

The Package Document represents a significant improvement on a typical Web site. A Web site, for example, embeds references to its resources within its content, which, while a simple and flexible means of identifying resources, makes it difficult to enumerate all the resources required to render it. In addition, there is no standard way for a Web site to define that a sequence of pages make up a larger publication, which is precisely what EPUB's spine element does (i.e., it provides an external declarative means to explicitly specify navigation through a collection of documents). Finally, the Package Document defines a standard way to represent metadata globally applicable to a collection of pages.

The Package Document and other Publication-level constructs are specified in [Publications30].

› 2.2 Navigation

› 2.2.1 Reading Order

A key concept of EPUB is that a Publication consists of multiple resources that may be completely navigated and consumed by a person or program in some specific order.

Many publications have an obvious reading order, or logical progression through their content. A novel is an example of a highly sequential document — it typically has a beginning, middle and end — but not all publications are so ordered: a cookbook or collection of photographic images might be considered to be more like a database. All documents do, however, have at least one logical ordering of all their top-level content items, whether by date, topic, location or some other criteria (e.g., a cookbook is typically ordered by type of recipe).

Every EPUB Publication defines at least one such logical ordering of all its top-level content (the spine [Publications30]), as well as a declarative table of contents (the EPUB Navigation Document [ContentDocs30]). Publications make these data structures available in a machine-readable way external to the content, simplifying their discovery and use.

EPUB Publications are not limited to the linear ordering of their contents, nor do they preclude linking in arbitrary ways — just like the Web, EPUB Publications are built on hypertext — but the basic consumption and navigation can be reliably accomplished in a way that is not true for a set of HTML pages.

› 2.2.2 Navigation Document

Every EPUB Publication contains a special XHTML Content Document called the EPUB Navigation Document, which uses the HTML5 nav element to define human- and machine-readable navigation information.

The Navigation Document supersedes the NCX document [OPS2], and the inclusion of NCX documents is only recommended for forward compatibility in older Reading Systems. The Navigation Document, while maintaining the baseline accessibility and navigation support and features of the NCX, introduces new functionality and rendering features to enhance navigation for all Users. Prime among these are better support for internationalization (as an XHTML5 document itself, the Navigation Document natively supports ruby annotations) and support for embedded grammars (MathML and SVG can be included within navigation links).

As XHTML Content Documents, Navigation Documents also provide a flexible means of tailoring the navigation display using CSS and the hidden attribute [ContentDocs30] while not impacting access to information for accessible Reading Systems.

The structure and semantics of Navigation Documents are defined in EPUB Navigation Documents [ContentDocs30].

› 2.3 Linking

The new EPUB Canonical Fragment Identifier (epubcfi) Specification [EPUBCFI] defines a standardized method for linking into a Publication.

Required support for this scheme in Reading Systems means that EPUB now has an interoperable linking mechanism, one that can, for example, facilitate the sharing of bookmarks and reading locations across devices.

› 2.4 Metadata

EPUB Publications provide a rich array of options for adding Publication metadata. The Package Document includes a dedicated metadata section [Publications30] for general information about the Publication, allowing titles, authors, identifiers and other information about the Publication to be easily accessed. It also provides the means to attach complete bibliographic records to a Publication using the link element [Publications30].

The Package Document also allows a Unique Identifier to be established for a Publication using the unique-identifier attribute [Publications30]. The required last-modified date in the Package metadata section can be joined with this identifier to define a Package Identifier, which provides a means of distinguishing EPUB Publications that represent different versions of the same Manifestation (see Publication Identifiers [Publications30]). The Package Identifier addresses the issue of how to release a Publication without changing its Unique Identifier while still identifying it as a new version.

XHTML Content Documents also include the means of annotating document markup with rich metadata, making them more semantically meaningful and useful both for processing and accessibility purposes (Semantic Inflection [ContentDocs30]).

› 2.5 Content Documents

Every EPUB Publication contains one or more EPUB Content Documents, as defined in [ContentDocs30]. These are XHTML or SVG documents that describe the readable content of a Publication and reference associated media resources (e.g., images, audio and video clips).

XHTML Content Documents are defined by a profile of HTML5 that requires the use of XML serialization [HTML5] in order to ensure that content can be reliably manipulated and rendered. This profile also adds two additional EPUB-specific language constructs: the epub:type attribute [ContentDocs30] for element-level metadata and the epub:trigger element [ContentDocs30] for declaratively associating controls with multimedia elements.

These additions do not affect the ability of an HTML5 User Agent [HTML5] to render EPUB XHTML Content Documents, but Publications might not render identically in all User Agents depending on their support.

› 2.6 Rendering and CSS

A key concept of EPUB is that content presentation should adapt to the User rather than the User having to adapt to a particular presentation of content. HTML was originally designed to support dynamic rendering of structured content, but over time HTML as supported in Web browsers has become focused on the needs of Web applications, and most popular Web sites now have fixed-format layouts.

EPUB Publications, however, are designed to maximize accessibility for the visually impaired, and Reading Systems typically perform text line layout and pagination on the fly, adapting to the size of the display area, the User's preferred font size, and other environmental factors. This behavior is not guaranteed in EPUB; images, vector graphics, video and other non-reflowable content may be included, and some Reading Systems might not paginate on the fly, or at all. Nevertheless, supporting dynamic adaptive layout and accessibility has been a primary design consideration throughout the evolution of the EPUB standard.

EPUB Content Documents may optionally reference EPUB Style Sheets, allowing Authors to define the desired rendering properties. EPUB 3 defines a profile of CSS based on CSS 2.1 [CSS2.1] for this purpose, together with capabilities defined by various CSS3 Modules and several additional properties specific to EPUB.

CSS3 properties were selected based on their current level of support in Web browsers, but support for them in Reading Systems and User Agents is not guaranteed (EPUB-defined properties may similarly be ignored).

EPUB 3 also supports CSS styles that enable both horizontal and vertical layout and both left-to-right and right-to-left writing, but Reading Systems might not support all of these capabilities. Reading Systems may also support different rendering options than the Author intended. Refer to CSS in the Global Language Support section for more information.

EPUB 3 also supports the ability to include multiple style sheets that allow users, for example, to select between day/night reading modes or to change the rendering direction of the text. Refer to Alternate Style Tags [ContentDocs30] for more information.

› 2.7 Multimedia

EPUB 3 supports audio and video embedded in [content documents] via the new [HTML5] audio and video elements, inheriting all the functionality and features these elements provide. (For information on supported audio formats, please refer to Core Media Types [Publications30]. For recommendations on embedding video, refer to Reading System Conformance [Publications30].)

Another key new multimedia feature in EPUB 3 is the inclusion of Media Overlay Documents [MediaOverlays30]. When pre-recorded narration is available for a Publication, Media Overlays provide the ability to synchronize that audio with the text of a Content Document (see also Aural Renditions and Media Overlays).

› 2.8 Fonts

EPUB 3 supports two closely-related font formats — OpenType [OpenType] and WOFF [WOFF] — to accommodate both traditional publishing workflows and emerging Web-based workflows. Word processing programs used to create Publications are likely to have access only to a collection of installed OpenType fonts, for example, whereas Web-archival EPUB generators will likely only have access to WOFF resources (which cannot be converted to OpenType without undesirable, and potentially unlicensed, stripping of WOFF metadata).

EPUB 3 also supports both obfuscated and regular font resources for both OpenType and WOFF font formats. Support for obfuscated font resources is required to accommodate font licensing restrictions for many commercially-available fonts.

› 2.9 Scripting

EPUB strives to treat content declaratively — as data that can be manipulated, not programs that must be executed — but does support scripting as defined in HTML5 and SVG (refer to Scripted Content Documents [ContentDocs30] for more information).

It is important to note, however, that scripting support is optional for Reading Systems and may be disabled for security reasons.

Authors should also note that scripting in an EPUB Publication can create security considerations that are different from scripting within a Web browser. For example, typical same-origin policies are not applicable to content that has been downloaded to a User's local system. Therefore, it is strongly encouraged that scripting be limited to container constrained contexts, as further described in Scripted Content Documents — Content Conformance [ContentDocs30].

Scripting consequently should be used only when essential to the User experience, since it greatly increases the likelihood that content will not be portable across all Reading Systems and creates barriers to accessibility and content reusability.

› 2.10 Text-to-speech

EPUB 3 provides the following text-to-speech (TTS) facilities for controlling aspects of speech synthesis, such as pronunciation, prosody and voice characteristics:

Pronunciation Lexicons

The inclusion of generic pronunciation lexicons using the W3C PLS format [PLS] enables Authors to provide pronunciation rules that apply to the entire EPUB Publication. Refer to PLS Documents [ContentDocs30] for more information.

Inline SSML Phonemes

The incorporation of SSML phonemes functionality [SSML] directly into a EPUB Content Document [ContentDocs30] enables fine-grained pronunciation control, taking precedence over default pronunciation rules and/or referenced pronunciation lexicons (as provided by the PLS format mentioned above). Refer to SSML Attributes [ContentDocs30] for more information.

CSS Speech Features

The inclusion of a select set of features from the CSS 3 Speech Module [CSS3Speech] (previously known as CSS 2.1 Aural Stylesheets [CSS2.1]) enables Authors to control further speech synthesis characteristics. Refer to CSS 3.0 Speech [ContentDocs30] for more information.

› 2.11 Container

An EPUB Publication is transported and interchanged as a single file (a "portable document") that contains the Package Document, all Content Documents and all other required resources for processing the Publication. The single-file container format for EPUB is based on the widely adopted ZIP format. An XML manifest that specifies the location in the ZIP archive of the Package Document must be found at a well-defined location within the archive.

This approach provides a clear contract between any creator of an EPUB Publication and any system which consumes such Publications, as well as a reliable representation that is independent of network transport or file system specifics.

An EPUB Publication's representation as a container file is specified in [OCF3].

› 3 Global Language Support

› 3.1 Metadata

EPUB 3 supports alternate representations of all text metadata items in the package metadata section to improve global distribution of Publications. The alternate-script property can be combined with the xml:lang attribute to include and identify alternate script renditions of language-specific metadata.

Using this property, a Japanese Publication could, for example, include an alternate Roman-script representation of the author's name and/or one or more representations of the title in Romance languages. Refer to the alternate-script property [Publications30] for more information.

The page-progression-direction attribute also allows the content flow direction to be globally specified for all Content Documents to facilitate rendering (see the page-progression-direction [Publications30]).

› 3.2 Content Documents

XHTML Content Documents leverage the new HTML5 directionality features to improve support for bidirectional content rendering: the bdi element allows an instance of directional text to be isolated from the surrounding content, the bdo element allows directionality to be overridden for its child content and the dir attribute allows the directionality of any element to be explicitly set.

XHTML Content Documents also support ruby annotations for pronunciation support (which makes them supported in Navigation Document links, as well).

SVG Content Documents support the rendering of bidirectional text, but do not include support for ruby.

› 3.3 CSS

EPUB 3's support for new CSS3 modules enables typography for many different languages and cultures. Some specific enhancements include:

support for vertical writing, which also provides Reading Systems the ability to allow users to toggle direction;

better handling of emphasis, such as the inclusion of bōten;

better control over line breaking, so that breaks can occur at the character level for languages that do not use spaces to delimit new words; and

better control over hyphenation, to further facilitate line breaking.

› 3.4 Fonts

EPUB 3 does not require that Reading Systems come with any particular set of built-in system fonts. As occurs in Web contexts, Users in a particular locale may have installed fonts that omit characters required for other locales, and Reading Systems may utilize intrinsic fonts or font engines that do not utilize operating system installed fonts. As a result, the text content of a Publication might not natively render as intended on all Reading Systems.

To address this problem, EPUB 3 supports the embedding of fonts to facilitate the rendering of text content, and this practice is recommended in order to ensure content is rendered as intended.

Support for embedded fonts also ensures that Publication-specific characters and glyphs can be embedded for proper display.

› 3.5 Text-to-speech

EPUB 3's support for PLS documents and SSML attributes increases the pronunciation control that Authors have over the rendering of any natural language in text-to-speech-enabled Reading Systems. Refer to Text-to-speech in the Features section for more information on these capabilities.

The combination of CSS Speech and inline SSML phonemes also allows fine control over ruby.

› 3.6 Container

The OCF container format supports UTF-8, allowing for internationalized file and directory naming of content resources.

› 4 Accessibility

A major goal of EPUB is to facilitate content accessibility, and a variety of features in EPUB 3 support this requirement. This section reviews these features, detailing some established best practices for ensuring that EPUB Publications are accessible where applicable.

It is important to note that while accessibility is important in its own right, accessible content is also more valuable content: an accessible Publication will be adaptable to more devices and be easier to reuse, in whole or in part, via human and automated workflows. The EPUB Working Group strongly recommends that Authors use EPUB tools that generate accessible content.

› 4.1 Navigation

EPUB 3 improves on NCX documents with the addition of EPUB Navigation Documents. As noted in Content Documents above, the new features these provide represent a more universal and flexible navigation system.

The need to navigate a document is not exclusively an accessibility issue, but a complete Navigation Document is key for all Users to be able to easily and fully access the contents of a document. The primary toc nav element (as defined in The toc nav Element [ContentDocs30]) should fully reflect the structure of the Publication, as a result.

For highly structured documents where it might not be desirable to display the complete table of contents to Users, the display level can be modified using the [HTML5] hidden attribute without minimizing the information that is available for accessible Reading Systems.

Authors are also encouraged to supply additional nav elements if their Publications contain non-structural points of interest, such as figures, tables, etc. in order to further enhance access to the content.

› 4.2 Semantic Markup

HTML5 supports a number of new elements intended to make markup more semantically meaningful (e.g., section, nav, aside) and introduces more clearly defined semantics for some HTML4 elements. These elements, in conjunction with best practices for authoring well-structured Web content, should be utilized when creating EPUB XHTML Content Documents. These additions allow content to be better grouped and defined, both for representing the structure of documents and to facilitate their logical navigation. XHTML Content Documents also natively support the inclusion of ARIA role and state attributes and events, enhancing the ability of Assistive Technologies to interact with the content.

EPUB 3 further introduces the epub:type [ContentDocs30] attribute, which is meant to be functionally equivalent to the W3C Role Attribute [Role]. This attribute allows any element in an XHTML Content Document to include additional information about its purpose and meaning within the work, using controlled vocabularies and terms. Refer to Semantic Inflection [ContentDocs30] for more information.

› 4.3 Dynamic Layouts

The design center of EPUB is dynamic layout: content is typically intended to be formatted on the fly rather than being typeset in a paginated manner in advance (i.e., expecting a particular sized "page"). This core capability is useful, for example, for optimizing rendering onto different sized device screens or window sizes, and it facilitates and simplifies content accessibility.

While it is possible to incorporate more highly formatted content in EPUB — for example via bitmap images or SVG graphics, or even use of CSS explicit positioning and/or table elements to achieve particular visual layouts — Authors are strongly discouraged from utilizing such techniques. They are not reliable in EPUB since many Reading Systems render content in a paginated manner rather than creating a single scrolling Viewport and since each Reading System may define its own pagination algorithm. If these techniques are required to convey the content of the publication (for example, for graphic novels), fallbacks [Publications30] should always be included.

In general, it is preferable to achieve visual richness by using EPUB Style Sheets without absolute sizing or positioning.

› 4.4 Aural Renditions and Media Overlays

Aural renditions of content are important for accessibility and are a desirable feature for many other Users. A baseline to facilitate aural rendering is to utilize semantic HTML designed for dynamic layout. Refer to Text-to-speech for more information on how to use the native facilities that EPUB XHTML Documents include.

Media Overlays provide the ability to synchronize the text and audio content of a Publication, a feature already familiar to readers of DAISY Digital Talking Books. Overlays transcend the accessibility domain in their usefulness: the synchronization of text and audio as a tool for learning to read, for example, being of benefit in many circumstances.

› 4.5 Fallbacks

Not all formats are accessible in their native format, and not all Users prefer to read in the default format provided. EPUB defines a variety of means for providing fallbacks so that alternate renditions of a Publication can be made available in these cases.

Publication and content-level fallbacks are defined in Restrictions and Fallbacks [Publications30]. These allow for the alternate rendition of specific resources within a Publication, such as SVG images or video clips.

In addition, multiple instances of a complete work can be delivered in a single Publication by defining multiple rootfile elements in the OCF container file (as described in Container – META-INF/container.xml [OCF3]). This kind of fallback may be used, for example, so that a formatted graphic novel defined via a sequence of SVG pages can be accompanied by an accessible text version defined via XHTML.

› 4.6 Scripting

EPUB 3 adopts a progressive enhancement approach for scripted content, whereby scripting must not interfere with the integrity of the document (i.e., must not result in information loss when scripting is not available). Consequently, although documents that do employ scripting may provide fallbacks [ContentDocs30] to further facilitate access to their contents, the documents must be accessible without them.

Several mechanisms in EPUB can further minimize and constrain scripting within Publications to improve accessibility:

The declarative trigger element [ContentDocs30] added to the EPUB HTML5 profile enables image or textual elements to act as controls for audio and video playback (for example, to start, stop and pause playback). This element eliminates the common use of scripting to include similar functionality.

The mediaType element [Publications30] provides a means of encapsulating script-based support for rendering custom XML vocabularies or other custom content types, as well as future-proofs Publications in case such content types are natively supported in future Reading Systems.

The semantic inflection capability provided by the type attribute [ContentDocs30] enables Authors to provide hints to Reading Systems about content properties. One use case is to define elements such as images and video as having a zoomable property value, in which case a Reading System may provide a means for Users to access an expanded view that is out-of-line with the normal layout. Such rollover effects are typically implemented via scripting in Web contexts, but scripting cannot be readily implemented given the wide variety of layouts that a Reading System may generate.

The switch element [ContentDocs30] provides a declaractive means for Authors to tailor the content displayed to Users without having to resort to scripted solutions.

Best practices for accessible scripting in Web documents, such as provided in [WAI-ARIA], should always be consulted, and use of scripting should be reserved for situations in which interactivity is critical to the User experience.

EPUB Publications 3.0

Recommended Specification 11 October 2011

This version

http://www.idpf.org/epub/30/spec/epub30-publications-20111011.html

Latest version

http://www.idpf.org/epub/30/spec/epub30-publications.html

Previous version

http://www.idpf.org/epub/30/spec/epub30-publications-20110908.html

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

Please refer to the errata for this document, which may include some normative corrections.

Copyright © 2010, 2011 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

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.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 DCMES Optional Elements

3.4.7. The meta Element

3.4.8. The meta Element (OPF2) [OBSOLETE]

3.4.9. The link Element

3.4.10. The manifest Element

3.4.11. The item Element

3.4.12. The spine Element

3.4.13. The itemref Element

3.4.14. The guide Element [DEPRECATED]

3.4.15. The bindings Element

3.4.16. The mediaType Element

4. Package Metadata

4.1. Publication Identifiers

4.1.1. Unique Identifier

4.1.2. Package Identifier

4.2. Vocabulary Association Mechanisms

4.2.1. Overview

4.2.2. Default Vocabulary

4.2.3. Reserved Vocabularies

4.2.4. The prefix Attribute

4.2.5. The property Data Type

4.2.5.1. Syntax

4.2.5.2. Processing

4.3. Package Metadata Vocabulary

4.3.1. Overview

4.3.2. Metadata meta Properties

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. The application/oebps-package+xml Media Type

› 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 provides an informative overview of EPUB and a roadmap to the rest of the EPUB 3 documents. The Overview should be read first.

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.3 Conformance Statements

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "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 Identifier.

› 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, and may support additional linking schemes as defined in the EPUB Linking Scheme Registry.

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 and encapsulates Publication metadata and resource information.

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.

prefix [optional]

Declaration mechanism for prefixes not reserved by this specification.

Refer to The prefix Attribute for more information.

xml:lang [optional]

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 Publication meta information.

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 [1 or more], DCMES Optional Elements [0 or more], meta [1 or more], OPF2 meta [0 or more], link [0 or more]

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

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

Examples

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>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 [optional]

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

The id attribute is required on the identifier element containing the unique identifier. See below.

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.

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

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

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

The following example shows how an identifier can be additionally marked as a DOI using the identifier-type 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 refines="#pub-id" property="identifier-type" scheme="onix:codelist5">06</meta>
    …
</metadata>

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

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

› 3.4.4 The DCMES title Element

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

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.

xml:lang [optional]

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

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 title-type property should be attached to indicate the type of title (e.g., the main title of a work, a subtitle, etc.).

The following example shows how to indicate different title types.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:title id="t1">A Dictionary of Modern English Usage</dc:title>
    <meta refines="#t1" property="title-type">main</meta>

    <dc:title id="t2">First Edition</dc:title>
    <meta refines="#t2" property="title-type">edition</meta>

    <dc:title id="t3">Fowler's</dc:title>
    <meta refines="#t3" property="title-type">short</meta>
    …
</metadata>

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

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

The following example shows how to indicate display sequence.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:title id="t1">The Red and the Black</dc:title>
    <meta refines="#t1" property="title-type">main</meta>
    <meta refines="#t1" property="display-seq">1</meta>

    <dc:title id="t2">A Chronicle of the Nineteenth Century</dc:title>
    <meta refines="#t2" property="title-type">subtitle</meta>
    <meta refines="#t2" property="display-seq">2</meta>

    <dc:title id="t3">A Chronicle of 1830</dc:title>
    <meta refines="#t3" property="title-type">subtitle</meta>
    <meta refines="#t3" property="display-seq">3</meta>
    …
</metadata>

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

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

Examples

The following example shows how the title "THE LORD OF THE RINGS, Part One: The Fellowship of the Ring" could be classified.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:title id="t1">The Fellowship of the Ring</dc:title>
    <meta refines="#t1" property="title-type">main</meta>

    <dc:title id="t2">The Lord of the Rings</dc:title>
    <meta refines="#t2" property="title-type">collection</meta>
    <meta refines="#t2" property="group-position">1</meta>

    <dc:title id="t3">THE LORD OF THE RINGS, Part One: The Fellowship of the Ring</dc:title>
    <meta refines="#t3" property="title-type">extended</meta>
    …
</metadata>

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 id="t1" xml:lang="fr">Mon premier guide de cuisson, un Mémoire</dc:title>
    <meta refines="#t1" property="title-type">main</meta>
    <meta refines="#t1" property="display-seq">2</meta>

    <dc:title id="t2">The Great Cookbooks of the World</dc:title>
    <meta refines="#t2" property="title-type">collection</meta>
    <meta refines="#t2" property="display-seq">1</meta>

    <dc:title id="t3">The New French Cuisine Masters</dc:title>
    <meta refines="#t3" property="title-type">collection</meta>
    <meta refines="#t3" property="group-position">2</meta>
    <meta refines="#t3" property="display-seq">3</meta>

    <dc:title id="t4">Special Anniversary Edition</dc:title>
    <meta refines="#t4" property="title-type">edition</meta>
    <meta refines="#t4" property="display-seq">4</meta>

    <dc:title id="t5">The Great Cookbooks of the World:
        Mon premier guide de cuisson, un Mémoire.
        The New French Cuisine Masters, Volume Two.
        Special Anniversary Edition</dc:title>
    <meta refines="#t5" property="title-type">extended</meta>
    …
</metadata>

› 3.4.5 The DCMES language Element

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

Element Name

dc:language

Namespace

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

Usage

Required child of metadata.

Attributes

id [optional]

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

Content Model

Text

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

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

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

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

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

› 3.4.6 The DCMES Optional Elements

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

Element Name

contributor | coverage | creator | date | description | format | publisher | relation | rights | source | subject | type

Namespace

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

Usage

Optional child of metadata. Repeatable.

Attributes

id [optional]

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

xml:lang* [optional]

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

Content Model

Text

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

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

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

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

The DCMES contributor Element

The contributor element is used to represent the name of a person, organization, etc. that played a secondary role in the creation of the content of a Publication.

The use of the contributor element is identical to the use of the creator element in all other respects, as detailed in the next section.

The DCMES creator Element

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

The following example shows how to represent a creator as an author using a MARC relators term.

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

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

The following example shows the different ways a creator's name can be included to facilitate processing and rendering.

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

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

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

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

    <dc:creator id="creator02">John Tenniel</dc:creator>
    <meta refines="#creator02" property="role" scheme="marc:relators">ill</meta>
    <meta refines="#creator02" property="display-seq">2</meta>
    …
</metadata>

If no means of establishing the primacy of creators is included, Reading Systems must use the order of creator elements.

Secondary contributors should be represented using DCMES contributor elements.

The DCMES date Element

The date element must only be used to define the publication date of the EPUB Publication. The publication date is not the same as the last modified date (the last time the content was changed), which must be included using the [DCTERMS] modified property.

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

The following example shows a publication date.

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

Additional dates should be expressed using the specialized date properties available in the [DCTERMS] vocabulary, or similar.

The publication date may be common to all instances of a Publication or may change from instance to instance (if the Publication gets generated on demand, for example).

Only one date element is allowed.

The DCMES source Element

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

The following example shows the ISBN identifier for a Publication together with the source ISBN identifier for the print work it was derived from.

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

    <dc:source id="src-id">urn:isbn:9780375704024</dc:source>
    <meta refines="#src-id" property="identifier-type" scheme="onix:codelist5">15</meta>
    …
</metadata>

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

Only one source element is allowed.

The DCMES type Element

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

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

Only one type element is allowed.

› 3.4.7 The meta Element

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

Element Name

meta

Usage

As child of the metadata element. Repeatable.

Attributes

property [required]

A property.

Refer to Vocabulary Association Mechanisms for more information.

refines [context dependent]

Identifies the expression or resource augmented by this element. The value of the attribute must be a relative IRI [RFC3987] pointing to the resource or element it describes.

The refines attribute is optional depending on the type of metadata being expressed. When omitted, the meta element defines a primary expression.

id [optional]

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

scheme [optional]

A property data type value indicating the source the value of the element is drawn from.

Content Model

Text

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

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

A primary expression is one in which the expression defined in the meta element establishes some aspect of the EPUB Publication. A meta element that omits a refines attribute defines a primary expression.

A subexpression is one in which the expression defined in the meta element enhances the meaning of the expression or resource referenced in its refines attribute. A subexpression may refine a media clip, for example, by expressing its duration, or refine a creator or contributor expression by defining the person's role.

Subexpressions are not limited to refining only primary expressions and resources; they may be used to refine the meaning of other subexpressions, thereby creating chains of information.

note

All of the [DCMES] elements represent primary expressions, and permit refinement by meta element subexpressions.

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

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

The following example shows how a subexpression can be attached to an creator to indicate it represents an author. The scheme indicates the value is drawn from the MARC relators terms.

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

If a Reading System does not recognize the scheme attribute value, it should treat the value of the element as a string.

Reading Systems should ignore all meta elements whose property attributes define expressions they do not recognize. A Reading System must not fail when encountering unknown expressions.

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

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

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

Examples

The following example represents a more complete set of metadata that typical Publications will contain.

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

    <dc:identifier id="isbn-id">urn:isbn:9780101010101</dc:identifier>
    <meta refines="#isbn-id" property="identifier-type" scheme="onix:codelist5">15</meta>

    <dc:source id="src-id">urn:isbn:9780375704024</dc:source>
    <meta refines="#src-id" property="identifier-type" scheme="onix:codelist5">15</meta>

    <dc:title id="title">Norwegian Wood</dc:title>
    <meta refines="#title" property="title-type">main</meta>

    <dc:language>en</dc:language>

    <dc:creator id="creator">Haruki Murakami</dc:creator>
    <meta refines="#creator" property="role" scheme="marc:relators" id="role">aut</meta>
    <meta refines="#creator" property="alternate-script" xml:lang="ja">村上 春樹</meta>
    <meta refines="#creator" property="file-as">Murakami, Haruki</meta>

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

</metadata>

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>
        <dc:identifier id="isbn-id">urn:isbn:9780101010101</dc:identifier>

        <meta refines="#isbn-id" property="meta-auth" id="meta-authority-01">Metadata Authority Inc.</meta>
        <link refines="#meta-authority-01" rel="xml-signature" href="../META-INF/Signatures.xml#MAI-Signature"/>
        …
    </metadata>
</package>

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

› 3.4.8 The meta Element (OPF2) [OBSOLETE]

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

EPUB 3 Reading Systems must ignore this element.

› 3.4.9 The link Element

The link element is used to associate resources with a Publication, such as metadata records.

Element Name

link

Usage

As a child of metadata. Repeatable.

Attributes

href [required]

An absolute or relative IRI reference [RFC3987] to a resource.

rel [required]

A space-separated list of property values.

id [optional]

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

refines [optional]

Identifies the expression or resource augmented by this element. The value of the attribute must be a relative IRI [RFC3987] pointing to the resource or element it describes.

When the refines attribute is omitted, the expression applies to the EPUB Publication as a whole.

media-type [optional]

A media type [RFC2046] that specifies the type and format of the resource referenced by this link.

Content Model

Empty

The metadata element may contain zero or more link elements.

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

Resources identified by the link element href attribute must not be represented as items in the manifest.

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

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

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

Examples

The following example shows the link element used to associate three metadata resources with the Publication: an ONIX record, an XMP record, and a link to an informational web page. Note that as foaf is not a predefined prefix, the metadata extensibility mechanism is employed to associate the vocabulary.

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

› 3.4.10 The manifest Element

The manifest element provides an exhaustive list of the Publication Resources that constitute the EPUB Publication, each represented by an item element.

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 accept URIs, resource names should be restricted to the ASCII character set.

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

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 whether they are included in the EPUB Container or made available remotely. Refer to Publication Resource Locations for media type-specific requirements regarding resource locations.

The Publication Resource identified by an item element must conform to the applicable specification(s) as inferred from the MIME media type provided in the media-type attribute. Core Media Type Resources must use the media type designated in EPUB Core Media Types.

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

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

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

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

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="nav"
          href="nav.xhtml"
          properties="nav"
          media-type="application/xhtml+xml"/>
    <item id="intro"
          href="intro.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="c1"
          href="chap1.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="c1-answerkey"
          href="chap1-answerkey.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="c2"
          href="chap2.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="c2-answerkey"
          href="chap2-answerkey.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="c3"
          href="chap3.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="c3-answerkey"
          href="chap3-answerkey.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="notes"
          href="notes.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="cover"
          href="./images/cover.svg"
          properties="cover-image"
          media-type="image/svg+xml"/>
    <item id="f1"
          href="./images/fig1.jpg"
          media-type="image/jpeg"/>
    <item id="f2"
          href="./images/fig2.jpg"
          media-type="image/jpeg"/>
    <item id="css"
          href="./style/book.css"
          media-type="text/css"/>
    <item id="pls"
          href="./speech/dict.pls"
          media-type="application/pls+xml"/>
</manifest>

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.12 The spine Element

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

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 [optional]

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]

The spine represents an ordered subset of the Publication Resources listed in the manifest, with content items not being referenced being ancillary to those that do.

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

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.13 The itemref Element

The child itemref elements of the spine represent a sequential list of Publication Resources (typically EPUB Content Documents). The order of the itemref elements defines the default reading order of the Publication.

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

id [optional]

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

properties [optional]

A space-separated list of property values.

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.

Each referenced manifest item must be either a) an EPUB Content Document or b) another type of Publication Resource which, regardless of whether it is a Core Media Type Resource or a Foreign Resource, must include an EPUB Content Document in its fallback chain.

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 referenced item is considered primary (yes) or auxiliary (no) in the spine. This attribute may be used to enable Reading Systems to distinguish presentation of body content from supplementary content which might be, for example, presented in a popup window or omitted from an aural rendition.

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

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

Examples

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.14 The guide Element [DEPRECATED]

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

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

› 3.4.15 The bindings Element

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

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 capabilities of the User's Reading System, 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.16 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 Vocabulary Association Mechanisms

› 4.2.1 Overview

This section is informative

The property, properties, rel and scheme attributes use the property data type to represent terms from metadata vocabularies. Similar to a CURIE [RDFa10], the property data type represents an IRI [RFC3987] in compact form and simplifies the authoring of metadata from standardized vocabularies.

A property value is an expression that consists of a prefix and a reference, where the prefix — whether literal or implied — is a shorthand mapping of an IRI that typically resolves to a term vocabulary. When the prefix is converted to its IRI representation and combined with the reference, the resulting IRI normally resolves to a fragment within that vocabulary that contains human- and/or machine-readable information about the term.

To assist Reading Systems in processing property values, the means of establishing the IRI a prefix maps to is required, and this specification defines three such mechanisms:

a default vocabulary — defines the mapping when a property value does not include a prefix;

a set of reserved prefixes — these mappings are predefined (i.e., all Reading Systems recognize them) and can be used without having to be declared; and

the prefix attribute — a declarative means of creating new prefix mappings on the root package element.

› 4.2.2 Default Vocabulary

The default vocabulary is a vocabulary that does not require a prefix to be declared in order to use its terms in package metadata, and whose terms must always be unprefixed.

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

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

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

› 4.2.3 Reserved Vocabularies

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

Reserved metadata prefixes

Prefix | IRI
dcterms | http://purl.org/dc/terms/
marc | http://id.loc.gov/vocabulary/
media | http://www.idpf.org/epub/vocab/overlays/#
onix | http://www.editeur.org/ONIX/book/codelists/current.html#
xsd | http://www.w3.org/2001/XMLSchema#

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

› 4.2.4 The prefix Attribute

The prefix attribute defines additional prefix mappings not reserved by the specification.

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

(EBNF productions ISO/IEC 14977)

prefixes | = | mapping , { whitespace, { whitespace } , mapping } ; |
mapping | = | prefix , ":" , space , { space } , ? xsd:anyURI ? ; |
prefix | = | ? xsd:NCName ? ; |
space | = | #x20 ; |
whitespace | = | (#x20 | #x9 | #xD | #xA) ; |

The following example shows prefixes for the Friend of a Friend (foaf) and DBPedia (dbp) vocabularies being declared using the prefix attribute.

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

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

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

› 4.2.5 The property Data Type

› 4.2.5.1 Syntax

The property data type is a compact means of expressing an IRI [RFC3987] and consists of an optional prefix separated from a reference by a colon.

(EBNF productions ISO/IEC 14977)

property | = | [ prefix , ":" ] , reference; |
prefix | = | ? xsd:NCName ? ; |
reference | = | ? irelative-ref ? ; | /* as defined in [RFC3987] */

The property data type is derived from the CURIE data type defined in [RDFa10], and represents a subset of CURIEs.

The following example shows a property value composed of the prefix dcterms and the reference modified.

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

After processing, this property would expand to the following IRI:

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

as the dcterms: prefix is a reserved prefix that maps to the IRI http://purl.org/dc/terms/.

When a prefix is omitted from the property value, the expressed reference represents a term from the default vocabulary.

The following example shows a property value taken from the default vocabulary.

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

This property would expand to:

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

when the IRI for the default vocabulary is concatenated with the reference.

An empty string does not represent a valid property value, even though it is valid to the definition above.

› 4.2.5.2 Processing

A Reading System must use the following rules to create an IRI [RFC3987] from a property:

If the property consists only of a reference, the IRI is obtained by concatenating the IRI stem associated with the default vocabulary to the reference.

If the property consists of a prefix and reference, the IRI is obtained by concatenating the IRI stem associated with the prefix to the reference. If no matching prefix has been defined, the property is invalid.

The resulting IRI must be valid to [RFC3987]. Reading Systems are not required to resolve this IRI, however.

› 4.3 Package Metadata Vocabulary

› 4.3.1 Overview

This section is informative

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

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

note

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

› 4.3.2 Metadata meta Properties

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

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

The following tables detail the available properties.

› 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 refines="#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).

When the display-seq property is attached to some, but not all, of the members in a set, only the elements identified as having a sequence should be included in any rendering.

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 refines="#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 refines="#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).

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 refines="#t3" property="group-position">2</meta>

› identifier-type
Description: | The identifier-type property indicates the form or nature of an identifier. When the identifier-type value is drawn from a code list or other formal enumeration, the scheme attribute should be attached to identify its source.
Allowed value(s): | xsd:string
Extends: | identifier
Cardinality: | In the metadata section: zero or more Attached to other metadata: zero or one
Example: | <meta refines="#src-id" property="identifier-type" scheme="onix:codelist5">15</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 refines="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 attribute 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 refines="#creator" property="role" scheme="marc:relators">aut</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 attribute should be attached to identify its source. When a scheme is not specified, Reading Systems should recognize the following title type values: main, subtitle, short, collection, edition and expanded.

Allowed value(s): | xsd:string
Extends: | title
Cardinality: | In the metadata section: zero or more Attached to other metadata: zero or one
Example: | <meta refines="#title" property="title-type">main</meta>

› 4.3.3 Metadata link Properties

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

› marc21xml-record
Description: | The marc21xml-record property indicates the referenced resource is a MARC21 record [MARC21XML].
Cardinality: | Zero or one
Extends: | Only applies to the Publication. Must not be used when the refines attribute is present.
Example: | <link rel="marc21xml-record" href="pub/meta/nor-wood-marc21.xml"/>

› mods-record
Description: | The mods-record property indicates the referenced resource is a MODS record [MODS].
Cardinality: | Zero or one
Extends: | Only applies to the Publication. Must not be used when the refines attribute is present.
Example: | <link rel="mods-record" href="pub/meta/nor-wood-mods.xml"/>

› onix-record
Description: | The onix-record property indicates the referenced resource is an ONIX record [ONIX].
Cardinality: | Zero or one
Extends: | Only applies to the Publication. Must not be used when the refines attribute is present.
Example: | <link rel="onix-record" href="pub/meta/nor-wood-onix.xml"/>

› xml-signature
Description: | The xml-signature property indicates the referenced resource contains an XML Signature [XML DSIG Core] for the Publication or associated property. The link element's href attribute typically references a specific signature element in the Signatures.xml file [OCF3] via a fragment identifier.
Cardinality: | Zero or more
Extends: | All properties.
Example: | <link refines="#meta-authority-01" rel="xml-signature" href="../META-INF/signatures.xml#MAI-Signature"/>

› xmp-record
Description: | The xmp-record property indicates the referenced resource is an XMP record [XMP].
Cardinality: | Zero or one
Extends: | Only applies to the Publication. Must not be used when the refines attribute is present.
Example: | <link rel="xmp-record" href="pub/meta/nor-wood-xmp.xml"/>

› 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 do not apply recursively to content included into a resource (e.g., via the HTML5 iframe element). For example, if a non-scripted XHTML Content Document embeds a scripted Content Document, only the embedded document's manifest item properties attribute will have the scripted value.

Examples

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/mp4 | [AAC LC], [MP4] | AAC LC audio using MP4 container
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 are also 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 is also 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 that is an XML-Based Media Type must meet the following constraints:

›  It must be a conformant XML 1.0 Document as defined in Conformance of Documents [XMLNS].

›  External identifiers must not appear in the document type declaration [XML].

›  It must not make use of XInclude [XInclude].

›  It must be encoded in UTF-8 or UTF-16 [Unicode].

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

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. The application/oebps-package+xml Media Type

This appendix registers the media type application/oebps-package+xml for the EPUB Package Document. This registration supersedes [RFC4839].

The Package Document is an XML file that describes an EPUB Publication [Publications30]. It identifies the resources in the Publication and provides metadata information. The Package Document and its related standards are maintained and defined by the International Digital Publishing Forum (IDPF).

MIME media type name:

application

MIME subtype name:

oebps-package+xml

Required parameters:

None.

Optional parameters:

None.

Encoding considerations:

Package Documents are UTF-8 or UTF-16 encoded XML.

Security considerations:

Package Documents contain well-formed XML conforming to the XML 1.0 specification.

Clearly, it is possible to author malicious files which, for example, contain malformed data. Most XML parsers protect themselves from such attacks by rigorously enforcing conformance.

All processors that read Package Documents should rigorously check the size and validity of data retrieved.

There is no current provision in the EPUB Publications 3.0 standard for encryption, signing, or authentication within the Package Document format.

Interoperability considerations:

None.

Published specification:

This media type registration is for the EPUB Package Document, as described by the EPUB Publications 3.0 specification located at http://www.idpf.org/epub/30/spec/epub30-publications.html.

The EPUB Publications 3.0 specification supersedes the Open Packaging Format 2.0.1 specification, which is located at http://idpf.org/epub/20/spec/OPF_2.0.1_draft.htm and which also uses the application/oepbs-package+xml media type.

Applications which use this media type:

This media type is in wide use for the distribution of ebooks in the EPUB format. The following list of applications is not exhaustive.

Adobe Digital Editions

Aldiko

Azardi

Apple iBooks

Barnes & Noble Nook

Calibre

Google Books

Ibis Reader

MobiPocket reader

Sony Reader

Stanza

Additional information:

Magic number(s):

none

File extension(s):

.opf

Macintosh File Type Code(s):

TEXT

Fragment Identifiers:

The IDPF maintains a registry of linking schemes at http://idpf.org/epub/linking/. Some of these schemes define custom fragment identifiers that resolve to application/oebps-package+xml documents.

Person & email address to contact for further information:

William McCoy, bmccoy@idpf.org

Intended usage:

COMMON

Author/Change controller:

International Digital Publishing Forum (http://www.idpf.org)

EPUB Content Documents 3.0

Recommended Specification 11 October 2011

This version

http://www.idpf.org/epub/30/spec/epub30-contentdocs-20111011.html

Latest version

http://www.idpf.org/epub/30/spec/epub30-contentdocs.html

Previous version

http://www.idpf.org/epub/30/spec/epub30-contentdocs-20110908.html

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

Please refer to the errata for this document, which may include some normative corrections.

Copyright © 2010, 2011 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Editors

Markus Gylling, DAISY Consortium

William McCoy, International Digital Publishing Forum (IDPF)

Elika J. Etemad, Invited Expert

Matt Garrish, Invited Expert

Table of Contents

1. Overview

1.1. Purpose and Scope

1.2. Relationship to Other Specifications

1.2.1. Relationship to HTML5

1.2.2. Relationship to SVG

1.2.3. Relationship to CSS

1.2.4. EPUB 3 Versioning Strategy

1.4. Conformance Statements

1.5. Namespace prefix mappings

2. EPUB Content Documents

2.1. XHTML Content Documents

2.1.1. Content Conformance

2.1.2. Reading System Conformance

2.1.3. HTML5 Extensions and Enhancements

2.1.3.1. Semantic Inflection

2.1.3.1.1. Introduction

2.1.3.1.2. The epub:type Attribute

2.1.3.1.3. Vocabulary Association

2.1.3.1.4. Processing Requirements

2.1.3.2. SSML Attributes

2.1.3.2.1. Overview

2.1.3.2.2. The ssml:ph attribute

2.1.3.2.3. The ssml:alphabet attribute

2.1.3.3. Content Switching

2.1.3.3.1. Introduction

2.1.3.3.2. Definition

2.1.3.3.2.1. The epub:switch Element

2.1.3.3.2.2. The epub:case Element

2.1.3.3.2.3. The epub:default Element

2.1.3.3.3. Processing

2.1.3.4. The epub:trigger Element

2.1.3.5. Alternate Style Tags

2.1.4. HTML5 Deviations and Constraints

2.1.4.1. Embedded MathML

2.1.4.1.1. Introduction

2.1.4.1.2. Content Conformance

2.1.4.1.3. Reading System Conformance

2.1.4.1.4. Alternative Content

2.1.4.2. Embedded SVG

2.1.4.2.1. Embedded SVG and CSS

2.1.4.3. Unicode Restrictions

2.1.4.4. Discouraged Constructs

2.2. EPUB Navigation Documents

2.2.1. Introduction

2.2.2. Content Conformance

2.2.3. Reading System Conformance

2.2.4. EPUB Navigation Document Definition

2.2.4.1. The nav Element: Restrictions

2.2.4.2. The nav Element: Types

2.2.4.2.1. The nav Element

2.2.4.2.2. The nav Element

2.2.4.2.3. The nav Element

2.2.4.2.4. Other nav Elements

2.2.4.3. The hidden attribute

2.3. SVG Content Documents

2.3.1. Introduction

2.3.2. Content Conformance

2.3.3. Restrictions on SVG 1.1

2.3.4. Reading System Conformance

2.4. Scripted Content Documents

2.4.1. Scripting Contexts

2.4.2. Content Conformance

2.4.3. Reading System Conformance

2.4.4. Security Considerations

2.4.5. Event Model Considerations

3. EPUB Style Sheets

3.1. Content Conformance

3.2. Reading System Conformance

3.3. EPUB 3 CSS Profile

3.3.1. CSS 2.1

3.3.2. CSS 2.0

3.3.3. CSS 3.0 Speech

3.3.4. CSS Fonts Level 3

3.3.5. CSS Text Level 3

3.3.6. CSS Writing Modes

3.3.7. Media Queries

3.3.8. CSS Namespaces

3.3.9. CSS Multi-Column Layout

3.3.10. Ruby Positioning

3.3.11. Display Property Values oeb-page-head and oeb-page-foot

4. PLS Documents

4.1. Overview

4.2. EPUB Publication Conformance

4.3. Content Conformance

4.4. Reading System Conformance

A. Schemas

A.1. XHTML Content Document Schema

A.2. EPUB Navigation Document Schema

A.3. SVG Content Document Schema

B. JavaScript epubReadingSystem Object

B.1. Syntax

B.2. Description

B.3. Properties

B.4. Methods

B.4.1. hasFeature

B.4.1.1. Syntax

B.4.1.2. Description

B.4.1.3. Features

› 1 Overview

› 1.1 Purpose and Scope

This section is informative

This specification, EPUB Content Documents 3.0, defines profiles of HTML5, SVG, and CSS for use in the context of EPUB® Publications.

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 provides an informative overview of EPUB and a roadmap to the rest of the EPUB 3 documents. The Overview should be read first.

EPUB Publications 3.0 [Publications30], which defines publication-level semantics and overarching conformance requirements for 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 Publication Structure (OPS) 2.0.1 [OPS2]. Refer to [EPUB3Changes] for information on differences between this specification and its predecessor.

› 1.2 Relationship to Other Specifications

This section is informative

› 1.2.1 Relationship to HTML5

The XHTML document type defined by this specification is based on W3C [HTML5], and inherits all definitions of semantics, structure and processing behaviors from the HTML5 specification unless otherwise specified.

In addition, this specification defines a set of extensions to the W3C HTML5 document model that Authors may include in XHTML Content Documents.

This specification defines a simplified processing model that does not require Reading Systems to support scripting, HTML5 forms or the HTML5 DOM. EPUB Reading Systems conformant with this specification are only required to be able to process a conforming EPUB Content Document. As support for scripting and HTML5 forms are optional Reading System features, a conformant Reading System might not be a fully-conformant HTML5 User Agent (i.e., it might not implement the complete HTML5 processing model).

› 1.2.2 Relationship to SVG

This specification defines a restricted subset of SVG 1.1 to represent vector graphics inline in XHTML Content Documents and as standalone SVG Content Documents.

› 1.2.3 Relationship to CSS

The CSS profile defined in this specification has CSS 2.1 [CSS2.1] as its baseline. Any CSS Style Sheet that conforms to CSS 2.1 may be used in the context of an EPUB Publication, except as noted in CSS 2.1.

This specification also incorporates features defined by CSS3 Modules and introduces EPUB-specific CSS constructs.

› 1.2.4 EPUB 3 Versioning Strategy

EPUB 3 references W3C specifications that are not yet final, and incompatible changes to them may occur in the future that would cause EPUB 3 Content Documents that were previously conformant to no longer be conformant to the latest versions of the referenced specifications.

The IDPF anticipates revising the EPUB 3 specifications if and when such incompatible changes occur, updating the normative constraints defined herein as necessary and incrementing the minor version number of EPUB 3 (e.g., publishing an EPUB 3.0.n).

› 1.4 Conformance Statements

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "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.

› 1.5 Namespace prefix mappings

For convenience, the following namespace prefix mappings [XMLNS] are used throughout this specification:

prefix | namespace URI
epub | http://www.idpf.org/2007/ops
m | http://www.w3.org/1998/Math/MathML
pls | http://www.w3.org/2005/01/pronunciation-lexicon
ssml | http://www.w3.org/2001/10/synthesis
svg | http://www.w3.org/2000/svg

› 2 EPUB Content Documents

› 2.1 XHTML Content Documents

This section defines a profile of [HTML5] for creating XHTML Content Documents. An instance of an XML document that conforms to this profile is a Core Media Type and is referred to in this specification and its sibling specifications as an XHTML Content Document.

Unless otherwise specified, this specification inherits all definitions of semantics, structure and processing behaviors from the [HTML5] specification.

caution

The EPUB 3 XHTML Content Document definition references features in the W3C [HTML5] specification that are still works in progress and may change in incompatible ways. When utilizing such features, authors should consider the inherent risks in terms of the potential impact on interoperability and document longevity.

› 2.1.1 Content Conformance

An XHTML Content Document must meet all of the following criteria:

Document Properties

›  It must meet the conformance constraints for XML documents defined in XML Conformance [Publications30].

› It must use the XHTML syntax [HTML5].

› It must be valid to the XHTML Content Document schema as defined in XHTML Content Document Schema.

› For all document constructs used that are defined by [HTML5], it must conform to the conformance criteria defined for those constructs in that specification, unless explicitly overridden in HTML5 Deviations and Constraints.

› It must conform to all content conformance constraints defined in HTML5 Extensions and Enhancements.

File Properties

› The XHTML Content Document filename should use the file extension .xhtml.

note

All Publication Resources referenced from an XHTML Content Document must conform to the constraints for Publication Resources defined in EPUB Publication — Content Conformance [Publications30]

› 2.1.2 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing XHTML Content Documents:

› Unless explicitly defined by this specification or its sibling specifications as overridden, it must process XHTML Content Documents using semantics defined by the [HTML5] specification and honor any applicable User Agent conformance constraints expressed therein.

› It must meet all Reading System conformance criteria defined in HTML5 Extensions and Enhancements.

› It must recognize and adapt behaviorally to the constraints defined in HTML5 Deviations and Constraints.

› It must meet the Reading System conformance criteria defined in Scripted Content Documents — Reading System Conformance.

› It must support visual rendering of XHTML Content Documents as defined in EPUB Style Sheets — Reading System Conformance.

› It should recognize embedded ARIA markup and support exposure of any given ARIA roles, states and properties to platform accessibility APIs [WAI-ARIA].

› 2.1.3 HTML5 Extensions and Enhancements

This section defines EPUB 3 XHTML Content Document extensions to the underlying [HTML5] document model.

› 2.1.3.1 Semantic Inflection

› 2.1.3.1.1 Introduction

This section is informative

Semantic inflection is the process of attaching additional meaning about the specific purpose and/or nature an element plays in an XHTML Content Document. In the context of EPUB Publications, the epub:type attribute is typically used to express domain-specific semantics, with the inflection(s) it carries complementing the underlying [HTML5] host vocabulary. The applied semantics always refine the meaning of their containing elements, never override their nature (e.g., the attribute can be used to indicate a section is a chapter in a work, but cannot be used to turn p elements into list items to avoid proper list structures).

Semantic metadata is not intended for human consumption; it instead provides a controlled way for Reading Systems and other User Agents to learn more about the structure and content of a document, providing them the opportunity to enhance the reading experience for Users.

This specification defines a method for semantic inflection using the attribute axis: instead of adding new XML elements to the XHTML Content Document vocabulary, the epub:type attribute can be appended to existing elements to inflect the desired semantics. A mechanism to identify external vocabularies that provide controlled values for the attributes is also defined.

› 2.1.3.1.2 The epub:type Attribute

The epub:type attribute inflects semantics on the element on which it appears. Its value is one or more space-separated terms stemming from external vocabularies associated with the document instance, as defined in Vocabulary Association.

The inflected semantic must express a subclass of the semantic of the carrying element. In the case of semantically neutral elements (such as [HTML5] div and span), the inflected semantic must not attach a meaning that is already conveyed by an existing element (e.g., that a div represents a paragraph or section). Reading Systems must ignore inflected semantics that conflict with the carrying element.

note

The epub:type attribute is intended to be functionally equivalent to the W3C Role Attribute [Role], but with restrictions as specified in Vocabulary Association.

Attribute Name

type

Namespace

http://www.idpf.org/2007/ops

Usage

May be specified on all elements.

Value

A space-separated list of property [Publications30] values, with restrictions as defined in Vocabulary Association.

› 2.1.3.1.3 Vocabulary Association

This specification adopts the vocabulary association mechanisms defined in Vocabulary Association Mechanisms [Publications30], with the following modifications:

Default Vocabulary

The default vocabulary for Content Documents is defined to be the EPUB 3 Structural Semantics Vocabulary.

Reserved Vocabularies

This specification does not reserve any prefixes.

The prefix Attribute

The prefix attribute definition is unchanged, but the attribute is defined to be in the namespace http://www.idpf.org/2007/ops when used in Content Documents.

Examples

The following example shows the epub:type attribute used to inflect footnote and note reference semantics. The properties used are defined in the default vocabulary.

<html … xmlns:epub="http://www.idpf.org/2007/ops">

    …

    <p> … <a epub:type="noteref" href="#n1">1</a> … </p>

    …

    <aside epub:type="footnote" id="n1">

        …

    </aside>

    …

</html>

The following example shows the epub:type attribute used to inflect glossary semantics on an HTML5 definition list. The property used is defined in the default vocabulary.

<html … xmlns:epub="http://www.idpf.org/2007/ops">

    …

    <dl epub:type="glossary">

        …

    </dl>

    …

</html>

The following example shows the epub:type attribute used to inflect source publication pagebreak semantics. The property used is defined in the default vocabulary. (Note that the dc:source [Publications30] element provides a means of identifying the source publication to which the given pagination information applies.)

<html … xmlns:epub="http://www.idpf.org/2007/ops">

   …

  <p> … <span epub:type="pagebreak" title="234"/> … </p>

   …

</html>

› 2.1.3.1.4 Processing Requirements

A Reading System must process the epub:type attribute as follows:

› It may associate specialized behaviors with none, some or all of the terms defined in the default vocabulary.

› It may associate specialized behaviors with terms given in vocabularies other than the default.

› It must ignore terms that it does not recognize.

When Reading System behavior associated with a given epub:type value conflicts with behavior associated with the carrying element, the behavior associated with the element must be given precedence.

› 2.1.3.2 SSML Attributes

› 2.1.3.2.1 Overview

The W3C Speech Synthesis Markup Language [SSML] is a language used for assisting Text-to-Speech (TTS) engines in generating synthetic speech. Although SSML is designed as a standalone document type, it also defines semantics suitable for use within other host languages.

This specification recasts the SSML 1.1 phoneme element as two attributes — ssml:ph and ssml:alphabet — and makes them available within EPUB XHTML Content Documents.

Reading Systems with Text-to-Speech (TTS) capabilities should support the SSML Attributes as defined below.

note

For more information on EPUB 3 features related to synthetic speech, refer to Text-to-speech [EPUB3Overview].

› 2.1.3.2.2 The ssml:ph attribute

The ssml:ph attribute specifies a phonemic/phonetic pronunciation of the text represented by the element to which the attribute is attached.

Attribute Name

ph

Namespace

http://www.w3.org/2001/10/synthesis

Usage

May be specified on all elements with which a phonetic equivalent can logically be associated (e.g., elements that contain textual information).

Must not be specified on a descendant of an element that already carries this attribute.

Value

A phonemic/phonetic expression, syntactically valid with respect to the phonemic/phonetic alphabet being used.

This attribute inherits all the semantics of the SSML 1.1 phoneme element ph attribute, with the following addition:

›  When the ssml:ph attribute appears on an element that has text node descendants, the corresponding document text to which the pronunciation applies is the string that results from concatenating the descendant text nodes, in document order. The specified phonetic pronunciation must therefore logically match the element's textual data in its entirety (i.e., not just an isolated part of its content).

note

Reading Systems that support the SSML Attributes and PLS Documents must honor the defined precedence rules for these two constructs.

› 2.1.3.2.3 The ssml:alphabet attribute

The ssml:alphabet attribute specifies which phonemic/phonetic pronunciation alphabet is used in the value of the ssml:ph attribute.

Attribute Name

alphabet

Namespace

http://www.w3.org/2001/10/synthesis

Usage

Global, may be specified on any element.

Value

The name of the pronunciation alphabet used in the value of ssml:ph (inherited).

This attribute inherits all the semantics of the SSML 1.1 phoneme element alphabet attribute, with the following addition:

› The value of the ssml:alphabet attribute is inherited in the document tree. The pronunciation alphabet used in a given ssml:ph attribute value is determined by locating the first occurrence of the ssml:alphabet attribute starting with the element on which the ssml:ph attribute appears, followed by the nearest ancestor element.

Reading Systems that support the SSML Attributes feature of this specification should support the ipa alphabet.

› 2.1.3.3 Content Switching

› 2.1.3.3.1 Introduction

This section is informative

The switch element provides a simple mechanism through which Authors can tailor the Publication content displayed to Users, one that isn't dependent on the scripting capabilities of the Reading System.

Reading System developers may choose to support XML vocabularies and new HTML elements that are not valid in XHTML Content Documents. The switch mechanism encourages this type of development and experimentation, but at the same time provides Authors who wish to take advantage of it the security of knowing that their content will still display on any compliant Reading System (i.e., it maintains the baseline requirement that all XHTML Content Documents be valid if none of the specialized markup is supported).

Content switching is not just about encouraging future development, however; it can also be used to create Publications that maintain a level of compatibility with older Reading Systems unable to handle the new features of EPUB 3. For example, instances of MathML, now a native type, could be added using switch elements so that EPUB 2 Reading Systems could instead provide fallback images or text.

› 2.1.3.3.2 Definition

› 2.1.3.3.2.1 The epub:switch Element

The switch element allows an XML fragment to be conditionally inserted into the content model of an XHTML Content Document.

Element name

switch

Namespace

http://www.idpf.org/2007/ops

Usage

In Flow and Inline content. Repeatable.

Attributes

id [optional]

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

Content Model

In this order: case [1 or more], default [exactly 1].

A Reading System must individually process each switch element in a document to determine whether it can render any of the child case elements (as determined by the value of their required-namespace attributes).

For each switch encountered, the Reading System should render the content of the first case it supports, but is free to select from any of the available options. If the Reading System does not support the markup contained in any of the child case elements, it must render the contents of the default element.

The [HTML5] object element should be used to embed custom (non-core) content types in XHTML Content Documents. Custom markup should be wrapped in a switch element only when the content it represents is an integral part of the document and depends on the context of the document to be properly processed.

Examples

An example of ChemML markup inserted using the switch element.

<epub:switch id="cmlSwitch">

   <epub:case required-namespace="http://www.xml-cml.org/schema">
      <cml xmlns="http://www.xml-cml.org/schema">
         <molecule id="sulfuric-acid">
            <formula id="f1" concise="H 2 S 1 O 4"/>
         </molecule>
      </cml>
   </epub:case>

   <epub:default>
      <p>H<sub>2</sub>SO<sub>4</sub></p>
   </epub:default>

</epub:switch>

An example of adding MathML markup for compliance with EPUB 2 Reading Systems.

<epub:switch id="mathmlSwitch">

   <epub:case required-namespace="http://www.w3.org/1998/Math/MathML">
      <math xmlns="http://www.w3.org/1998/Math/MathML">
         <mrow>
            <mn>2</mn>
            <mo> &#x2061;<!--INVISIBLE TIMES--></mo>
            <mi>x</mi>
         </mrow>
         <mrow>
            <mo>+</mo>
            <mi>y</mi>
            <mo>-</mo>
            <mi>z</mi>
         </mrow>
      </math>
   </epub:case>

   <epub:default>
      <p>2x + y - z</p>
   </epub:default>

</epub:switch>

› 2.1.3.3.2.2 The epub:case Element

The case element contains an instance of markup from an XML vocabulary. The included markup may be natively supported in XHTML Content Documents (in the case of MathML and SVG), but such support is not a requirement.

Element name

case

Namespace

http://www.idpf.org/2007/ops

Usage

Required first child of switch. Repeatable.

Attributes

id [optional]

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

required-namespace [required]

An extension identifier in URI form [RFC2046] that identifies the XML vocabulary or extension that the Reading System must support in order to process the content of the case element.

Content Model

An XML fragment conforming to the markup vocabulary identified in the required-namespace attribute.

Each case element must contain an alternate representation of the same content. To ensure the best rendering of their content, Authors should order case elements by to their optimal rendering format.

If the case element contains markup that is valid in an XHTML Content Document (e.g., MathML), that content must be valid at the point where the switch element has been inserted (i.e., its addition must not result in an invalid document).

Foreign markup in a case element must be well formed, but does not have to be valid at its point of insertion. Authors should ensure that any foreign markup matches the context in which it is used (e.g., a block element should not be included in a switch element inserted in an inline context).

note

The IDPF maintains an informative registry of common extension identifiers for use in the required-namespace attribute at http://www.idpf.org/epub/switch/.

› 2.1.3.3.2.3 The epub:default Element

The default element provides markup that is valid in any XHTML Content Document for when a Reading System cannot render any of the case elements.

Element name

default

Namespace

http://www.idpf.org/2007/ops

Usage

Required last child of epub:switch.

Attributes

id [optional]

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

Content Model

An [HTML5]-compliant markup fragment.

The default element acts as a fallback for the switch and must include a representation of the content that is valid in XHTML Content Documents.

The default element must not include content that would invalidate the document at the point where the switch has been inserted: XHTML Content Documents must be valid if all the switch elements are replaced by their child default elements.

› 2.1.3.3.3 Processing

EPUB Reading Systems must support the switch element.

This specification does not require a specific rendering approach for switch elements. A Reading Systems may choose to apply CSS styling to render each switch, for example, but may use any other approach as appropriate. All Reading Systems must present the content of only one case element or the default element per switch for rendering, however.

The switch element must be processed as though all of its children but one have the HTML5 hidden attribute set (i.e., all the same processing rules and requirements outlined for that attribute should be applied to the content not to be rendered).

note

As the content that may be rendered depends on the capabilities of the User's Reading System, linking can be guaranteed only to the switch element. Deep referencing into the switch element is not recommended.

note

The occurrence of switch elements in XHTML Content Document is indicated in the Package Document manifest through the switch [Publications30] property.

› 2.1.3.4 The epub:trigger Element

The trigger element enables the creation of markup-defined user interfaces for controlling multimedia objects, such as audio and video playback, in both scripted and non-scripted contexts.

Element name

trigger

Namespace

http://www.idpf.org/2007/ops

Usage

As a child of head and in Flow content. Repeatable.

Attributes

id [optional]

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

action [required]

The action to perform for this event.

Allowed values: show | hide | play | pause | resume | mute | unmute

ref [required]

An IDREF [XML] that identifies the element that is the object of the action.

ev:event [required]

The applicable event for this trigger, as defined in [XML Events].

ev:observer [required]

The source object for this trigger, as defined in [XML Events].

Content Model

Empty.

The trigger element associates an event from a specified source object (observer) with a desired action to be performed with a specified target object (ref).

The semantics of the defined action values are:

show – set the element's DOM visibility [CSS2.1] property to visible.

hide – set the element's DOM visibility [CSS2.1] property to hidden.

play – play the associated resource from the beginning (only applicable to video or audio elements).

pause – pause playing (only applicable to video or audio elements).

resume – resume playing (only applicable to video or audio elements).

mute – mute sound (only applicable to video or audio elements).

unmute – unmute sound (only applicable to video or audio elements).

Reading Systems that support video or audio playback must support the epub:trigger element.

Sample markup of a video player that uses trigger elements to control playback and muting.

<html xmlns="http://www.w3.org/1999/xhtml"
  xmlns:epub="http://www.idpf.org/2007/ops"
  xmlns:ev="http://www.w3.org/2001/xml-events">
  <head>
    <epub:trigger ev:observer="pause" ev:event="click" action="pause" ref="test"/>
    <epub:trigger ev:observer="resume" ev:event="click" action="resume" ref="test"/>
    <epub:trigger ev:observer="mute" ev:event="click" action="mute" ref="test"/>
    <epub:trigger ev:observer="mute" ev:event="click" action="show" ref="muted"/>
    <epub:trigger ev:observer="unmute" ev:event="click" action="unmute" ref="test"/>
    <epub:trigger ev:observer="unmute" ev:event="click" action="hide" ref="muted"/>
  </head>
  <body>
    <video id="test" src="birds.mp4" width="320" height="240"/>
    <p>
      <span class="button" id="resume">Play/Resume</span>
      <span class="button" id="pause">Pause</span>
      <span class="button" id="mute">Mute</span>
      <span class="button" id="unmute">Unmute</span>
      <span id="muted">MUTED</span>
    </p>
  </body>
</html>

› 2.1.3.5 Alternate Style Tags

In accordance with [AltStyleTags] , the link element class attribute may include any of the following values: horizontal, vertical, day and night. These values inherit the semantics defined by that specification for their use.

Reading Systems should select and utilize such tagged style sets as appropriate, and as described in that specification.

› 2.1.4 HTML5 Deviations and Constraints

This section defines deviations and/or constraints in EPUB 3 XHTML Content Documents to the underlying [HTML5] document model.

› 2.1.4.1 Embedded MathML

› 2.1.4.1.1 Introduction

This section is informative

XHTML Content Documents support embedded [MATHML] but limit its usage to a restricted subset of the full MathML markup language.

This subset is designed to ease the implementation burden on Reading Systems and to promote accessibility, while retaining compatibility with [HTML5] User Agents.

note

The mathml [Publications30] property of the manifest item element indicates that an XHTML Content Document contains embedded MathML.

› 2.1.4.1.2 Content Conformance

Any occurrence of MathML markup in XHTML Content Documents must conform to the constraints expressed in the MathML specification [MATHML], with the following additional restrictions:

Presentation MathML

› The m:math element must contain only Presentation MathML, with the exception of the m:annotation-xml element as defined below.

Content MathML

› Content MathML may be included within MathML markup in XHTML Content Documents, and, when present, must occur within an m:annotation-xml child element of an m:semantics element.

› When Content MathML is included as per the previous condition, the given m:annotation-xml element's encoding attribute must be set to either of the functionally-equivalent values MathML-Content or application/mathml-content+xml, and its name attribute must be set to contentequiv.

Deprecated MathML

› Elements and attributes marked as deprecated in [MATHML] must not be included within MathML markup in XHTML Content Documents.

XHTML Content Document fragments

› XHTML Content Document fragments may be included within MathML markup in XHTML Content Documents, and, when present, must occur within an m:annotation-xml child element of an m:semantics element.

› When an XHTML Content Document fragment is included as per the above paragraph, the given m:annotation-xml element's encoding attribute must be set to application/xhtml+xml and its name attribute must be set to alternate-representation.

› Any included XHTML Content Document fragments must not themselves contain MathML markup.

› Any included XHTML Content Document fragments must conform to the content model in which the ancestor m:math element occurs, such that if the m:math element is replaced by the given XHTML Content Document fragment the document remains valid.

Alternative Content

› Alternative content should be included, and, when present, must be represented as defined in Alternative Content.

› 2.1.4.1.3 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing MathML embedded in XHTML Content Documents:

› It must support processing of Presentation MathML, and may support processing of Content MathML, using semantics defined by the MathML 3.0 specification [MATHML].

› If it has a Viewport, it must support visual rendering of Presentation MathML.

› When producing alternative textual content for MathML markup, it should be able to dynamically generate such content from the given Presentation MathML, and if not, must give preference to XHTML Content Document fragments followed by the alttext attribute on the m:math element.

› It must regard the mathml [Publications30] property of the Package Document manifest item element as the authoritative definition of whether an XHTML Content Document includes embedded MathML.

› 2.1.4.1.4 Alternative Content

Reading Systems should be able to generate any necessary alternative textual renditions dynamically using the given Presentation MathML markup (e.g., as output to Text-to-Speech (TTS) engines). To support Reading Systems that are not so capable, alternative textual content should be included with each occurrence of the m:math element in XHTML Content Documents.

The alttext attribute on the m:math element should be used for this purpose primarily when shorter alternative text runs are sufficient. When more extensive alternative text is required, XHTML Content Document fragments should be used. (Note that Reading Systems query these two alternative text locations using a defined preference order.)

For Reading System forward compatibility purposes, fallback images may be provided using the altimg attribute on the m:math element. It is recommended that the dimension and alignment attributes (altimg-width, altimg-height and altimg-valign) be used in conjunction with the altimg attribute.

note

All referenced Publication Resources must conform to the constraints for Publication Resources defined in EPUB Publication — Content Conformance [Publications30].

› 2.1.4.2 Embedded SVG

XHTML Content Documents support the embedding of SVG 1.1 document fragments by reference (embedding via reference, for example, from an img or object element) and by inclusion (embedding via direct inclusion of the svg:svg element in the XHTML Content Document) [SVG].

The content conformance constraints for SVG embedded in XHTML Content Documents are the same as defined for SVG Content Documents in Restrictions on SVG 1.1.

Reading Systems must process SVG embedded in XHTML Content Documents as defined in SVG Content Documents — Reading System Conformance.

note

The svg [Publications30] property of the manifest item element indicates that an XHTML Content Document contains embedded SVG.

› 2.1.4.2.1 Embedded SVG and CSS

For the purposes of styling SVG embedded in XHTML Content Documents by reference, Reading Systems must not apply CSS style rules of the containing document to the referenced SVG document.

For the purposes of styling SVG embedded in XHTML Content Documents by inclusion, Reading Systems must apply applicable CSS rules of the containing document to the included SVG elements.

note

SVG included by reference is processed as a separate document, and may include its own CSS style rules just like an SVG Content Document would. Note that this is consistent with situations where an [HTML5] object element references an external [HTML5] element.

› 2.1.4.3 Unicode Restrictions

This section lists restrictions on the Unicode character repertoire.

Private Use Characters and Embedded Fonts

Any included characters that map to a code point within one of the Private Use Area (PUA) ranges as defined in [Unicode] must occur within a string that is styled or attributed in a manner that includes a reference to an embedded font that contains an appropriate glyph for that code point.

› 2.1.4.4 Discouraged Constructs

The rp Element

› The [HTML5] rp element is intended to provide a fallback — an optional parenthesis display around ruby markup — for older version Reading Systems that do not recognize ruby markup. As EPUB 3 Reading Systems are ruby-aware, and can provide fallbacks, the use of rp elements in Content Documents is discouraged.

The embed Element

› Since the [HTML5] embed element does not provide intrinsic facilities to provide fallbacks for Reading Systems that do not support scripting, its use is discouraged when the resource referenced has scripting components. Authors should use the object element instead.

› 2.2 EPUB Navigation Documents

› 2.2.1 Introduction

This section is informative

The EPUB Navigation Document is a required component [Publications30] of EPUB Publications. It provides the Author with a mechanism to include a human- and machine-readable global navigation layer in the Publication, thereby ensuring increased usability and accessibility for the User.

The EPUB Navigation Document is an adaptation of XHTML Content Document and is, by definition, a valid XHTML Content Document instance. All Content and Reading System conformance requirements that apply to XHTML Content Documents also apply to the EPUB Navigation Document.

The navigation features of this adaptation are expressed through specializations of the [HTML5] nav element. Each nav element in an EPUB Navigation Document represents a data island — an embedded source of specialized information within the general markup — from which Reading Systems can retrieve navigational information. Unlike typical XML data islands, however, the information within the nav element remains human readable as an [HTML5] document.

To facilitate machine readability, the content model of nav elements in EPUB Navigation Documents is restricted relative to what is allowed in general XHTML Content Documents.

note

The EPUB Navigation Document is identified in the Package Document manifest through the nav [Publications30] property.

note

The EPUB Navigation Document supersedes the NCX document type as defined in [OPF2].

Information on how EPUB 3 Publications may include an NCX document for EPUB 2 Reading System forwards compatibility purposes is available in NCX Superseded [Publications30].

› 2.2.2 Content Conformance

A conformant EPUB Navigation Document must meet all of the following criteria:

Document Properties

› It must conform to all content conformance constraints for XHTML Content Documents as defined in XHTML Content Documents — Content Conformance.

› It must be valid to the EPUB Navigation Document schema as defined in EPUB Navigation Document Schema and conform to all content conformance constraints specific for EPUB Navigation Documents expressed in EPUB Navigation Document Definition.

› As a conforming XHTML Content Document, it may be included in the Publication spine, but may also be provided independently of it.

› 2.2.3 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing EPUB Navigation Document:

› When requested by a User, Reading Systems must provide access to the links and link labels in the nav elements of the EPUB Navigation Document in a fashion that allows the User to activate the links provided. When a link is activated, the Reading System must relocate the application's current reading position to the destination identified by that link.

› Reading Systems must honor the above requirement irrespective of whether the EPUB Navigation Document provided in a Publication is part of the spine.

› 2.2.4 EPUB Navigation Document Definition

› 2.2.4.1 The nav Element: Restrictions

This specification restricts the content model of the nav element and its descendants in EPUB Navigation Documents as follows:

› Each nav element may contain an optional heading indicating the title of the navigation list. The heading must be one of the [HTML5] h1 through h6 elements or an hgroup.

› The optional heading must be followed by a single ol ordered list; no other elements are permitted as direct children of the nav element. This ordered list represents the primary level of content navigation.

› Each list item (li) of the ordered list represents a primary heading, structure or other point of interest within the Publication and must contain either a child a element or a child span element. The a element describes the target within the Content Document that the link points to. The span element serves as a heading for breaking down lists into distinct groups (for example, a large list of illustrations can be segmented into several lists, one for each chapter).

› Each child a or span element of a list item may contain any valid HTML5 phrasing content, but must not result in a zero-length text string after concatenation of all child content and application of whitespace normalization rules.

› If the a element contains instances of HTML5 embedded content that do not provide intrinsic text alternatives, it must also include a title attribute with an alternate text rendition of the link label.

› The relative IRI reference provided in the href attribute of the a element must resolve to an EPUB Content Document or fragment therein.

› The a element may optionally be followed by an ol ordered list representing a subsidiary content level below that heading (e.g., all the subsection headings of a section). The span element must be followed by an ol ordered list: it cannot be used in "leaf" li elements. Regardless of whether an a or span element precedes it, this sublist must adhere to all the content requirements defined in this section for constructing the primary navigation list, and recursively (for each additional level of the Publication's hierarchy represented in this manner).

› The ol element represents an ordered list. In the context of this specification, the default display style of list items must be equivalent to CSS list-style: none (Reading Systems with no CSS support must not show list item numbering). Authors may specify alternative list item styles using CSS, but these would obviously be ignored by Reading Systems that do not support Cascading Style Sheets.

The following example shows a partial lot ("list of tables") nav element, with span elements used as link-less headings for grouping the sublists.

<nav epub:type="lot">
    <h2>List of tables, broken down into individual groups, one per major section of the publication content</h2>
    <ol>
        <li><span>Tables in Chapter 1</span>
            <ol>
                <li><a href="chap1.xhtml#table-1.1">Table 1.1</a>
                </li>
                <li><a href="chap1.xhtml#table-1.2">Table 1.2</a></li>
            </ol>
        </li>

        <li><span>Tables in Chapter 2</span>
            <ol>
                <li><a href="chap2.xhtml#table-2.1">Table 2.1</a>
                </li>
                <li><a href="chap2.xhtml#table-2.2">Table 2.2</a></li>
                <li><a href="chap2.xhtml#table-2.3">Table 2.3</a></li>
            </ol>
        </li>
        ...
        <li><span>Tables in Appendix</span>
            <ol>
                <li><a href="appendix.xhtml#table-a.1">Table A.1</a>
                </li>
                <li><a href="appendix.xhtml#table-a.2">Table B.2</a></li>
            </ol>
        </li>
    </ol>
</nav>

› 2.2.4.2 The nav Element: Types

The nav elements defined in an EPUB Navigation Document are distinguished semantically by the value of their epub:type attribute. By default, values of epub:type are drawn from the EPUB 3 Structural Semantics Vocabulary [StructureVocab], but values drawn from other vocabularies are also allowed. Refer to The epub:type Attribute for more information.

› 2.2.4.2.1 The toc nav Element

The toc nav element defines the primary navigational hierarchy of the EPUB Publication. It conceptually corresponds to a table of contents in a printed work (i.e., it provides navigation to the structural sections of the Publication).

For usability and accessibility reasons, Authors should provide a comprehensive table of contents: the toc nav should not exclude references based solely on their nesting depth within the document hierarchy, as is often the case in print works (particularly in reduced tables of contents).

In the case of Publications that exclusively reference XHTML Content Documents from their spines, the toc nav will typically correspond to the aggregation of HTML5 outlines of those documents (excluding any subtrees that do not contribute to the primary Publication outline).

The order of li elements contained within the toc nav element must match the order of the targeted elements within each targeted EPUB Content Document, and must also follow the order of Content Documents in the Publication spine.

The toc nav element must occur exactly once in EPUB Navigation Documents.

note

The toc nav element corresponds to the navMap element in the superseded NCX [OPF2].

› 2.2.4.2.2 The page-list nav Element

The page-list nav element is a container for pagination information. It provides navigation to positions in the Publication content that correspond to the locations of page boundaries present in a print source being represented by this EPUB Publication.

The page-list nav element is optional in EPUB Navigation Documents and must not occur more than once.

The order of li elements contained within a page-list nav structure must match the order of the actual pages inside each targeted EPUB Content Document and must also follow the order of Content Documents in the Publication spine.

The page-list nav element should contain only a single ol descendant (i.e., it should be a flat list, not a nested structure of navigation items).

note

The page-list nav element corresponds to the pageList element in the superseded NCX. [OPF2]

note

The dc:source [Publications30] element provides a means of identifying the source publication to which the given pagination information applies.

› 2.2.4.2.3 The landmarks nav Element

The landmarks nav element identifies fundamental structural components of the publication in order to enable Reading Systems to provide the User efficient access to them.

The structural semantics of each link target within the landmarks nav element is determined by the value of the epub:type attribute on the a element descendants. The epub:type attribute is required on a element descendants of the landmarks nav element.

The landmarks nav element extends the suggested HTML context of terms from the EPUB Structural Semantics Vocabulary to include the a element.

The following example shows a landmarks nav element with structural semantics drawn from the EPUB Structural Semantics Vocabulary.

<nav epub:type="landmarks">
    <h2>Guide</h2>
    <ol>
        <li><a epub:type="toc" href="#toc">Table of Contents</a></li>
        <li><a epub:type="loi" href="content.html#loi">List of Illustrations</a></li>
        <li><a epub:type="bodymatter" href="content.html#bodymatter">Start of Content</a></li>
    </ol>
</nav>

The landmarks nav element is optional in EPUB Navigation Documents and must not occur more than once.

note

The landmarks nav element corresponds to the deprecated OPF guide element. Refer to guide [Publications30] for more information.

› 2.2.4.2.4 Other nav Elements

EPUB Navigation Documents optionally may include one or more nav elements in addition to the toc, page-list and landmarks nav elements defined above. Such additional nav elements should have an epub:type attribute to provide a machine-readable semantic, and must have a human-readable heading as their first child.

This specification imposes no restrictions on the semantics of such additional nav elements: they may be used to represent navigational semantics for any information domain, and they may contain link targets with homogeneous or heterogeneous semantics.

› 2.2.4.3 The hidden attribute

In some cases, Authors may wish to hide parts of the navigation data within the content flow (i.e., the Reading System's principal rendering of the spine contents). A typical example is the list of page breaks, which usually isn't rendered as part of the content flow but instead exposed to the User separately in a dedicated navigation user interface.

While the CSS display property can be used to control the visual rendering of EPUB Navigation Documents in Reading Systems with CSS Viewports, not all Reading Systems provide such an interface. To control rendering across all Reading Systems, authors must use the [HTML5] hidden attribute to indicate which (if any) portions of the navigation data are excluded from rendering in the content flow. The hidden attribute has no effect on how navigation data is rendered outside of the content flow (such as in dedicated navigation user interfaces provided by Reading Systems).

The following example shows a partial page-list nav element. The presence of the hidden attribute on the root indicates that the entire list is excluded from rendering in the content flow.

<nav epub:type="page-list" hidden="">
    <h2>Pagebreaks of the print version, third edition</h2>
    <ol>
        <li><a href="frontmatter.xhtml#pi">I</a></li>
        <li><a href="frontmatter.xhtml#pii">II</a></li> … <li><a href="chap1.xhtml#p1">1</a></li>
        <li><a href="chap1.xhtml#p2">2</a></li> … </ol>
</nav>

The following example shows a partial toc nav element where the hidden attribute is used to limit content flow rendering to the two topmost hierarchical levels.

<nav epub:type="toc" id="toc">
  <h1>Table of contents</h1>
  <ol>
    <li>
      <a href="chap1.xhtml">Chapter 1</a>
      <ol>
        <li>
          <a href="chap1.xhtml#sec-1.1">Chapter 1.1</a>
          <ol hidden="">
            <li>
              <a href="chap1.xhtml#sec-1.1.1">Section 1.1.1</a>
            </li>
            <li>
              <a href="chap1.xhtml#sec-1.1.2">Section 1.1.2</a>
            </li>
          </ol>
         </li>
         <li>
           <a href="chap1.xhtml#sec-1.2">Chapter 1.2</a>
         </li>
       </ol>
     </li>
    <li>
      <a href="chap2.xhtml">Chapter 2</a>
    </li>
  </ol>
</nav>

› 2.3 SVG Content Documents

› 2.3.1 Introduction

This section is informative

The Scalable Vector Graphics (SVG) 1.1 (Second Edition) specification [SVG] defines a format for representing final-form vector graphics and text.

Although an EPUB Publication typically uses XHTML Content Documents as the top-level document type, the use of SVG Content Documents is also permitted. SVGs are typically only used in certain special circumstances, such as when final-form page images are the only suitable representation of the content (as may be the case, for example, in the context of manga or comic books).

This section defines a profile for [SVG] documents. An instance of an XML document that conforms to this profile is a Core Media Type and is referred to in this specification and its sibling specifications as an SVG Content Document.

note

This section defines conformance requirements for SVG Content Documents. Refer to Embedded SVG for conformance requirements for SVG embedded in XHTML Content Documents.

› 2.3.2 Content Conformance

An SVG Content Document must meet all of the following criteria:

Document Properties

›  It must meet the conformance constraints for XML documents defined in XML Conformance [Publications30].

› It must be an SVG 1.1 document fragment valid to the SVG Content Document schema as defined in SVG Content Document Schema and conform to all content conformance constraints expressed in Restrictions on SVG 1.1.

› It should adhere to the accessibility guidelines given in [SVG Access].

File Properties

› The SVG Content Document filename should use the file extension .svg.

note

All Publication Resources referenced from an SVG Content Document must conform to the constraints for Publication Resources defined in EPUB Publication — Content Conformance [Publications30]

› 2.3.3 Restrictions on SVG 1.1

This specification restricts the content model of SVG Content Documents and SVG embedded in XHTML Content Documents as follows:

› The [SVG] Animation Elements and Animation event attributes must not occur.

› The [SVG] svg:foreignObject element must contain only valid XHTML Content Document Flow content, and its requiredExtensions attribute, if given, must be set to http://www.idpf.org/2007/ops.

› The [SVG] svg:title element must contain only valid XHTML Content Document Phrasing content.

› 2.3.4 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing SVG Content Documents and SVG embedded in XHTML Content Documents:

› It must support the language features of SVG that correspond to the feature string http://www.w3.org/TR/SVG11/feature#SVG-dynamic minus the http://www.w3.org/TR/SVG11/feature#Animation and http://www.w3.org/TR/SVG11/feature#AnimationEventsAttribute features (see Feature strings) [SVG].

› It must meet the Reading System conformance criteria defined in Scripted Content Documents — Reading System Conformance.

› If it has an SVG Viewport, it must support the visual rendering of SVG using CSS as defined in Section 6 of [SVG], and it should support all properties defined in Appendix N of that specification. In the case of embedded SVG, it must also conform to the constraints defined in Embedded SVG and CSS.

› It should support User selection and searching of text within SVG elements.

› It must recognize the value http://www.idpf.org/2007/ops of the requiredExtensions attribute when appearing on the svg:switch and svg:foreignObject elements as representing the occurrence of XHTML Content Document fragments.

› It must regard the svg [Publications30] property of the Package Document manifest item element as the authoritative definition of whether an EPUB XHTML Content Document includes embedded SVG.

› 2.4 Scripted Content Documents

EPUB Content Documents may contain scripting using the facilities defined for this in the respective underlying specifications ([HTML5] and [SVG]). When an EPUB Content Document contains scripting, it is referred to in this specification and its sibling specifications as a Scripted Content Document. This label also applies to XHTML Content Documents when they contain instances of HTML5 forms.

› 2.4.1 Scripting Contexts

This specification defines two contexts in which scripts may appear:

spine-level

An instance of the [HTML5] script element included in a Top-level Content Document.

container-constrained

An instance of the [HTML5] script element included in an EPUB Content Document that is embedded in a parent Content Document using one of the [HTML5] object, iframe or embed elements.

In both of the above-defined contexts, whether the JavaScript code is embedded directly in the script element or referenced via its src attribute makes no difference to the executing context.

Which context a script is used in determines the rights and restrictions that a Reading System may place on it. Refer to Content Conformance and Reading System Conformance for some specific requirements that must be adhered to (not all Reading Systems may provide the same scripting functionality).

Example

Consider the following example Package Document:

<package …>
    …
    <manifest>
        …
        <item id="chap01"
            href="scripted01.xhtml"
            media-type="application/xhtml+xml"
            properties="scripted"/>
        <item id="inset01"
            href="scripted02.xhtml"
            media-type="application/xhtml+xml"
            properties="scripted"/>
        <item id="slideshowjs"
            href="slideshow.js"
            media-type="text/javascript"/>
    </manifest>

    <spine …>
        <itemref idref="chap01"/>
        …
    </spine>
    …
</package>

and the following file scripted01.xhtml:

<html …>
    <head>
        …
        <script type="text/javascript">
            alert("Reading System name: " + navigator.epubReadingSystem.name);
        </script>
    </head>
    <body>
        …
        <iframe src="scripted02.xhtml" … />
        …
    </body>
</html>

and the following file scripted02.xhtml:

<html …>
    <head>
        …
        <script type="text/javascript" href="slideshow.js"></script>
    </head>
    <body>
        …
    </body>
</html>

From these examples, it is true that:

the code in the script element in the head in scripted01.xhtml is a spine-level script because the document is referenced from the spine;

the code in the script element in scripted02.xhtml is a container-constrained script because the HTML file it occurs in is included in scripted01.xhtml via the iframe element.

› 2.4.2 Content Conformance

Container-constrained scripts

› A container-constrained script must not contain instructions for modifying the DOM of the parent Content Document or other contents in the Publication, and must not contain instructions for manipulating the size of its containing rectangle.

Spine-level scripts

› EPUB Content Documents that include spine-level scripting must utilize the progressive enhancement technique, which for the purposes of this specification has the following definition: when the document is rendered by a Reading System without scripting support or with scripting support disabled, the top-level document content must retain its integrity, remaining consumable by the User without any information loss or other significant deterioration.

Accessibility

› EPUB Content Documents that include scripting — using any inclusion model — should employ relevant accessibility techniques to ensure that the content remains consumable by all Users. [WAI-ARIA] [WCAG20]

Fallbacks

› EPUB Content Documents that include scripting — using any inclusion model — may provide fallbacks for such content, either by using intrinsic fallback mechanisms (such as those available for the [HTML5] object and canvas elements) or, when an intrinsic fallback is not applicable, by using a manifest-level [Publications30] fallback.

note

The scripted [Publications30] property of the manifest item element indicates that an EPUB Content Document is a Scripted Content Document.

› 2.4.3 Reading System Conformance

EPUB Reading System support for scripting is optional. A Reading System that supports scripting must meet the following criteria:

› It must support container-constrained scripting and may support spine-level scripting.

› It may render Scripted Content Documents as an interactive, scripted User Agent according to [HTML5].

› It must not allow a container-constrained script to modify the DOM of the parent Content Document or other contents in the Publication, and must not allow it to manipulate the size of its containing rectangle. (Note: Even if a script is not container-constrained, the Reading System may impose restrictions on modifications (see also the dom-manipulation feature).)

› It may place additional limitations on the capabilities provided to scripts during execution (e.g., limiting networking).

› It must implement the JavaScript navigator extension object epubReadingSystem defined in Appendix B, JavaScript epubReadingSystem Object. It also must support the dom-manipulation and layout-change features defined in Features in container-constrained scripting contexts.

› It must regard the scripted [Publications30] property of the Package Document manifest item element as the authoritative definition of whether an EPUB Content Document includes scripting.

A Reading System that does not support scripting must meet the following criteria:

› It must process fallbacks for scripted content as defined in Fallbacks for Scripted Content Documents.

note

Reading Systems may render Scripted Content Documents in a manner that disables other EPUB capabilities and/or provides a different rendering and User experience (e.g., by disabling pagination).

Authors choosing to restrict the usage of scripting to the container-constrained model will ensure a more consistent User experience between scripted and non-scripted content (e.g., consistent pagination behavior).

Authors should use declarative techniques whenever practical to increase the interoperability, longevity and accessibility of their Publications, and avoid the inclusion of scripting whenever practical.

› 2.4.4 Security Considerations

This section is informative

All EPUB Authors and Reading System developers need to be aware of the security issues that arise when scripted content is executed by a Reading System. As the underlying scripting model employed by Reading Systems and browsers is the same, the same kinds of issues encountered in Web contexts must be taken into consideration.

Each Reading System should establish if the scripts in a particular document are to be trusted or not. It is recommended that all scripts be treated as untrusted (and potentially malicious), and that all vectors of attack be examined and protected against. In particular, the following should be considered:

an attack against the runtime environment (e.g., stealing files from a User's hard drive);

an attack against the Reading System itself (e.g., stealing a list of a User's books or causing unexpected behavior);

an attack of one Content Document against another (e.g., stealing data that originated in a different document);

an attack of an unencrypted script against an encrypted portion of a document (e.g., an injected malicious script extracting protected content);

an attack against the local network (e.g., stealing data from a server behind a firewall).

The following recommendations are provided as a guide to handling untrusted scripts:

Reading Systems should behave as if a unique domain were allocated to each Content Document, as browser-based security relies heavily on document URLs and domains. Adopting this approach will isolate documents from each other and from other Internet domains, thereby limiting access to external URLs, cookies, DOM storage, etc.

Reading Systems that enable scripting and network access should also consider including methods to notify the user that network activity is occurring and/or that allow them to disable it.

note

In practice, Reading Systems may share domains across documents, but they still should maintain isolation between documents.

If parts of a document are encrypted and parts are not, or if different encryption keys are used for different parts of the document, a unique per-document domain might not provide sufficient protection.

If a Reading System allows persistent data to be stored, that data should be treated as sensitive. Scripts may save persistent data through cookies and DOM storage, but Reading Systems may block such attempts. Reading Systems that do allow data to be stored must ensure that it is not made available to other unrelated documents (e.g., ones that could have been spoofed). In particular, checking for a matching document identifier (or similar metadata) is not a valid method to control access to persistent data.

Reading Systems that allow local storage should also provide methods for Users to inspect, disable, or delete that data. The data should be destroyed if the corresponding EPUB Publication is deleted.

Note that compliance with these recommendations does not guarantee protection from the possible attacks listed above; developers must examine each potential vulnerability within the context of their Reading System.

› 2.4.5 Event Model Considerations

This section is informative

Reading Systems should follow the DOM Event model as per [HTML5] and pass UI events to the scripting environment before performing any default action associated with these events. Reading System implementers should ensure that scripts cannot disable critical functionality (such as navigation) to constrain the extent to which a potentially malicious script could impact their Reading Systems. As a result, although the scripting environment should be able to cancel the default action of any event, some events either might not be passed through or might not be cancelable.

Authors should take into account the wide variety of possible Reading System implementations when adding scripting functionality to their Publications (e.g., not all devices have physical keyboard, and in many cases a soft keyboard is only activated only for text input elements). Consequently, relying on keyboard events alone is not recommended; alternative ways to trigger the desired action should always be provided.

› 3 EPUB Style Sheets

This section defines a profile for Cascading Style Sheets (CSS) intended to be used for styling of XHTML Content Documents. An instance of a CSS Style Sheet that conforms to this profile is a Core Media Type and is referred to in this specification and its sibling specifications as an EPUB Style Sheet.

caution

The EPUB 3 CSS Profile references CSS specifications that are still works in progress and may change in incompatible ways. When utilizing features from such specifications, authors should consider the inherent risks in terms of the potential impact on interoperability and document longevity.

note

The EPUB 3 CSS Profile employs the usage of the -epub- prefix for a number of CSS3 property names, as detailed below. As the CSS3 modules that define these properties mature and stabilize, EPUB authoring guidelines may encourage authors to also include unprefixed equivalents of these properties in EPUB 3 Style Sheets.

› 3.1 Content Conformance

A conformant EPUB Style Sheet must meet all of the following criteria:

› It must adhere to all content restrictions given in EPUB 3 CSS Profile.

› It may include constructs not explicitly identified in the EPUB 3 CSS Profile, but should be authored so that rendering fidelity does not depend on such additional constructs.

› It must be UTF-8 or UTF-16 encoded.

note

All Publication Resources referenced from a CSS Style Sheet must conform to the constraints for Publication Resources defined in EPUB Publication — Content Conformance [Publications30]

› 3.2 Reading System Conformance

› Reading Systems with a CSS Viewport should support — render as defined by the corresponding specification in the Viewport — all CSS constructs included in this profile unless detailed otherwise in EPUB 3 CSS Profile.

› Reading Systems may support additional CSS constructs not explicitly identified in the EPUB 3 CSS Profile, and must handle any unsupported constructs as defined in [CSS2.1].

note

Reading Systems have varying capabilities with regards to CSS rendering support, so may ignore some or all style information of an EPUB Style Sheet.

In addition, even when a Reading System does have a CSS Viewport, it is likely to render content in a manner that differs from typical HTML5 User Agents (e.g., paginating content rather than providing a infinitely scrolling surface).

› 3.3 EPUB 3 CSS Profile

› 3.3.1 CSS 2.1

The style baseline of the EPUB 3 CSS Profile is Cascading Style Sheets Level 2 Revision 1 [CSS2.1]. The profile includes all style sheet constructs normatively defined in [CSS2.1], with the following exceptions:

The fixed value of the position property is not part of the EPUB 3 CSS Profile. To avoid potential rendering and interoperability issues, it should not be included in an EPUB Style Sheet.

The direction and unicode-bidi properties must not be included in an EPUB Style Sheet. Authors should use appropriate [HTML5] markup to express directionality information instead.

Reading Systems that have a CSS Viewport must support the font-family property.

note

The ability of Reading Systems to paginate absolutely positioned layouts is not guaranteed, so reliance on absolute positioning is discouraged. Reading Systems might not support these property values.

› 3.3.2 CSS 2.0

The EPUB 3 CSS Profile includes the following values for the list-style-type property as defined in [CSS2.0]:

cjk-ideographic

hebrew

hiragana

hiragana-iroha

katakana

katakana-iroha

› 3.3.3 CSS 3.0 Speech

The EPUB 3 CSS Profile includes -epub- prefixed versions of the following properties from the CSS3 Speech Module [CSS3Speech] using syntax as defined in [CSS3Speech-20110818] and semantics as defined in [CSS3Speech]:

-epub-cue

-epub-pause

-epub-rest

-epub-speak

-epub-speak-as

-epub-voice-family

note

For more information on EPUB 3 features related to synthetic speech, refer to Text-to-speech [EPUB3Overview].

› 3.3.4 CSS Fonts Level 3

The EPUB 3 CSS Profile includes @font-face rules and descriptors as defined in the CSS Fonts Module Level 3 [CSS3Fonts] specification, using syntax as defined in [CSS3Fonts-20110324] and semantics as defined in [CSS3Fonts].

Reading Systems with a CSS Viewport must support OpenType [OpenType] and WOFF [WOFF] fonts embedded using the @font-face rule.

note

Refer to Embedded Font Intrinsic Fallback [Publications30] for font fallback processing requirements.

In addition, Reading Systems must support at least the following @font-face font descriptors.

font-family

font-style

font-weight

src

unicode-range

For forwards compatibility with EPUB 2 Reading Systems that do not support @font-face rules, authors should reference a generic font using the font-family property.

note

Refer to Font Obfuscation [OCF3] for Reading System font obfuscation requirements.

› 3.3.5 CSS Text Level 3

The EPUB 3 CSS Profile includes -epub- prefixed versions of the following properties from the CSS Text Level 3 [CSS3Text] specification using syntax as defined in [CSS3Text-20110412] and semantics as defined in [CSS3Text].

-epub-hyphens*

-epub-line-break

-epub-text-align-last

-epub-text-emphasis

-epub-text-emphasis-color

-epub-text-emphasis-style

-epub-word-break

* The -epub-hyphens property does not include support for the value all.

In addition, the EPUB 3 CSS Profile includes the unprefixed text-transform property from CSS Text Level 3 using semantics as defined in [CSS3Text] and syntax as defined in [CSS3Text-20110412], with the exception that the fullwidth and fullsize-kana values are prefixed in the EPUB 3 CSS Profile (-epub-fullwidth and -epub-fullsize-kana, respectively).

› 3.3.6 CSS Writing Modes

With exceptions for the direction and unicode-bidi properties as noted below, the EPUB 3 CSS Profile includes all of the features defined in the CSS Writing Modes Module Level 3 [CSS3WritingModes] specification using -epub- prefixed property names, syntax as defined in [CSS3WritingModes-20110428] and semantics as defined in [CSS3WritingModes].

The direction and unicode-bidi properties from [CSS3WritingModes] are not included in the EPUB 3 CSS Profile. Authors should use appropriate [HTML5] markup to express directionality information instead.

› 3.3.7 Media Queries

The EPUB 3 CSS Profile includes @media and @import rules with media queries as defined in the Media Queries [MediaQueries] specification.

› 3.3.8 CSS Namespaces

The EPUB 3 CSS Profile includes the @namespace rule defined in [CSS Namespaces] for declaring the default namespace for a style sheet and for binding prefixes to namespaces.

› 3.3.9 CSS Multi-Column Layout

The EPUB 3 CSS Profile includes all of the features defined in the CSS Multi-column Layout Module [CSSMultiCol] specification with the exception of the column-span property.

caution

Authors should not rely on column behavior in overflow conditions as this behavior is unstable and may change.

caution

Pagination algorithms are not fully defined in CSS. Authors should therefore expect exact pagination points to vary from Reading System to Reading System.

Reading Systems must treat the oeb-column-number property as an alias for the column-count property. The use of the oeb-column-number property in EPUB Style Sheets is deprecated; this conformance requirement may be removed in the next major version of EPUB.

› 3.3.10 Ruby Positioning

The EPUB 3 CSS Profile includes the -epub-ruby-position property as defined below:

Name: | -epub-ruby-position
Value: | over | under | inter-character
Initial: | over
Applies to: | ruby text elements
Inherited: | yes
Percentages: | N/A
Media: | visual
Computed value: | as specified

This property controls the placement of ruby text with respect to its base text. Values have the following meanings:

over

Ruby text is positioned on the over side of the ruby base.

under

Ruby text is positioned on the under side of the ruby base.

inter-character

Ruby text is positioned on the right side of the base text. (This value is typically used for Zhuyin Fuhao (Bopomofo) ruby.)

note

The -epub-ruby-position property will become an alias for the ruby-position property in the CSS Ruby Module [CSS3Ruby].

› 3.3.11 Display Property Values oeb-page-head and oeb-page-foot

In addition to the standard values defined for the display property in Section 9.2.4 of [CSS2.1], EPUB Style Sheets may specify the values oeb-page-head and oeb-page-foot.

Reading Systems should present the content of an element assigned display: oeb-page-head only as a header, and the content of an element assigned display: oeb-page-foot only as a footer. Neither should be presented simply as if it were inline or block. The way Reading Systems present headers and footers is not defined by this specification (e.g., they may render them in fixed positions as per print layouts or pop them up on demand if only limited screen space is available).

For the purposes of page layout, these display values are similar to block boxes with an absolute position (i.e., a position value of fixed or absolute). That is, they are removed from the normal flow and a new block box is created with its own flow. Margins, padding, and other block characteristics are determined as if the element had position: fixed set.

An element assigned display: oeb-page-head or display: oeb-page-foot must not be considered in effect while any markup specified before such an element is still being rendered in the same context (for example, if it is on the same page in a paginated context, or in the viewport for a scrolled context). Once in effect, the element must remain in effect until either of the following conditions is true:

another header or footer (respectively) is in effect instead; or

no part of its parent element remains presented.

For example, when rendered to a screen with appropriate style settings, the myhead-classed div element in the following example would become the page header as soon as nothing preceding the containing div is displayed, and go out of effect when that div is no longer visible:

 <div>
   <div class="myhead" style="display: none; display: oeb-page-head">
      The OEB Publication Structure: Introduction
   </div>
   <h2>Introduction</h2>
   <p>…</p>
</div>

note

The display property has its value set to none in the preceding example before setting it to oeb-page-head to ensure that Reading Systems that do not support this feature do not display the content. This approach is recommended whenever setting the oeb-page-head or oeb-page-foot values.

› 4 PLS Documents

› 4.1 Overview

This section is informative

The W3C Pronunciation Lexicon Specification [PLS] defines syntax and semantics for XML-based pronunciation lexicons to be used by Automatic Speech Recognition and Text-to-Speech (TTS) engines.

The following sections define conformance criteria for PLS documents when included in EPUB Publications, and rules for associating PLS Documents with XHTML Content Documents.

note

For more information on EPUB 3 features related to synthetic speech, refer to Text-to-speech [EPUB3Overview].

› 4.2 EPUB Publication Conformance

A conformant EPUB Publication must meet all of the following criteria for inclusion of PLS Documents:

› PLS Documents may be associated with XHTML Content Documents. Each XHTML Content Document may contain zero or more PLS Document associations.

› PLS Documents must be associated with the XHTML Content Document to which it applies using the [HTML5] link element with its rel attribute set to pronunciation and its type attribute set to the PLS media type (application/pls+xml).

› The link element hreflang attribute should be specified on each PLS link, and its value must match the language for which the pronunciation lexicon is relevant [PLS] when specified.

› PLS Documents must meet the content conformance criteria defined in PLS Documents — Content Conformance.

› PLS Documents must be represented and located as defined in EPUB Publication — Content Conformance [Publications30].

Examples

The following example shows two PLS Documents (one for Chinese and one for Mongolian) associated with an XHTML Content Document.

<html … >
    <head>
        …
        <link rel="pronunciation" type="application/pls+xml" hreflang="zh" href="../speech/zh.pls"/>
        <link rel="pronunciation" type="application/pls+xml" hreflang="mn" href="../speech/mn.pls"/>
    </head>
    …
</html>

› 4.3 Content Conformance

To be considered a Core Media Type Resource, a PLS Document must meet all of the following criteria:

Document Properties

›  It must meet the conformance constraints for XML documents defined in XML Conformance [Publications30].

› It must be valid to the RELAX NG schema for PLS documents available at the URI http://www.w3.org/TR/pronunciation-lexicon/pls.rng [PLS].

File Properties

› The PLS Document filename should use the file extension .pls.

› 4.4 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing PLS Documents:

› Reading Systems with Text-to-Speech (TTS) capabilities should support PLS.

› Reading Systems that support PLS must process PLS documents as defined in [PLS].

› Reading Systems that support PLS must apply the supplied pronunciation instructions to all text nodes in the current XHTML Content Document whose language [HTML5] matches the language for which the pronunciation lexicon is relevant [PLS]. The algorithm for matching language tags is defined in BCP47.

›  When a pronunciation rule is specified more than once for a given string target in a given language, the last occurrence of the rule takes precedence, in such a way that any previously-defined pronunciation rule gets overridden.

› Reading Systems that support PLS and the SSML Attributes must let any pronunciation instructions provided via the ssml:ph attribute take precedence in cases where a pls:grapheme matches a text node of an element that carries the ssml:ph attribute.

› Appendix A. Schemas

The schemas in this Appendix are normative.

note

Validation using these schemas 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.

› A.1 XHTML Content Document Schema

The schema for XHTML Content Documents is available at http://www.idpf.org/epub/30/schema/epub-xhtml-30.nvdl.

Note that all custom data attributes (data-*) must be removed prior to validation.

› A.2 EPUB Navigation Document Schema

The schema for EPUB Navigation Documents is available at http://www.idpf.org/epub/30/schema/epub-nav-30.nvdl.

Note that all custom data attributes (data-*) must be removed prior to validation.

› A.3 SVG Content Document Schema

The schema for SVG Content Documents is available at http://www.idpf.org/epub/30/schema/epub-svg-30.nvdl.

› Appendix B. JavaScript epubReadingSystem Object

› B.1 Syntax

ReadingSystem = navigator.epubReadingSystem;

› B.2 Description

The epubReadingSystem object provides an interface through which a Scripted Content Document can query information about a User's Reading System.

The object exposes a number of properties, about the Reading System, such as its name and version, and provides the hasFeature method which can be invoked to determine the features it supports.

Example JavaScript function that displays the name of the current Reading System.

alert("Reading System name: " + navigator.epubReadingSystem.name);

› B.3 Properties

The following properties must be made available for retrieving information about the Reading System.

Required epubReadingSystem properties

Name | Description
name | Returns a String value representing the name of the Reading System (e.g., iBooks, Kindle).
version | Returns a String value representing the version of the Reading System (e.g., 1.0, 2.1.1).
layoutStyle | Returns a String value representing the style of layout for the content. A Reading System will typically return one of the values paginated or scrolling, but may define values for any additional layout formats it supports.

› B.4 Methods

› B.4.1 hasFeature

› B.4.1.1 Syntax

hasFeature(feature[, version])

› B.4.1.2 Description

For recognized features, the hasFeature method returns a boolean value indicating whether any version is supported.

If the optional version parameter is included, the return value indicates support only for the specified version.

The method returns undefined if the feature is not recognized by the Reading System.

Example JavaScript function that displays whether the current Reading System supports scripted manipulation of the DOM.

var feature = "dom-manipulation";

var conformTest = navigator.epubReadingSystem.hasFeature(feature);

alert("Feature " + feature + " supported?: " + conformTest);

› B.4.1.3 Features

The following table details the features that must be recognized by all Reading Systems that support scripting (spine-level or container-constrained). Reading Systems may support some or all of these features (refer to Scripted Content Documents — Reading System Conformance for more information).

Feature names are case-insensitive.

Required epubReadingSystem features

Name | Description
dom-manipulation | Scripts may make structural changes to the document’s DOM (applies to spine-level scripting only).
layout-changes | Scripts may modify attributes and CSS styles that affect content layout (applies to spine-level scripting only).
touch-events | The device supports touch events and the Reading System passes touch events to the content.
mouse-events | The device supports mouse events and the Reading System passes mouse events to the content.
keyboard-events | The device supports keyboard events and the Reading System passes keyboard events to the content.
spine-scripting | Spine-level scripting is supported.

If a Reading System supports a feature defined in this section, it must return a true value both when queried without the version parameter set and when that parameter is set to the value 1.0. Otherwise, it must return false. Reading System developers should not change the version number of these features independently of this specification.

Additional features may be added by Reading System developers, but future versions of this specification may append to this list in ways that may conflict or be incompatible with any such custom additions.

EPUB Media Overlays 3.0

Recommended Specification 11 October 2011

This version

http://www.idpf.org/epub/30/spec/epub30-mediaoverlays-20111011.html

Latest version

http://www.idpf.org/epub/30/spec/epub30-mediaoverlays.html

Previous version

http://www.idpf.org/epub/30/spec/epub30-mediaoverlays-20110908.html

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

Please refer to the errata for this document, which may include some normative corrections.

Copyright © 2010, 2011 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Editors

Marisa DeMeglio, DAISY Consortium

Daniel Weck, DAISY Consortium

Table of Contents

1. Overview

1.1. Purpose and Scope

1.2. Relationship to Other Specifications

1.4. Conformance Statements

2. Media Overlay Document Definition

2.1. Introduction

2.2. Content Conformance

2.3. Reading System Conformance

2.4. Media Overlay Document Definition

2.4.1. The smil Element

2.4.2. The head Element

2.4.3. The metadata Element

2.4.4. The body Element

2.4.5. The seq Element

2.4.6. The par Element

2.4.7. The text Element

2.4.8. The audio Element

3. Creating Media Overlays

3.1. Overview

3.2. Relationship to the EPUB Content Document

3.2.1. Structure

3.2.2. Granularity

3.2.3. Embedded Audio and Video

3.2.4. Text-to-Speech

3.3. Semantic Inflection

3.4. Associating Style Information

3.5. Packaging

3.5.1. Including Media Overlays

3.5.2. Media Overlays Metadata Vocabulary

4. Playback Behaviors

4.1. Loading the Media Overlay

4.2. Basic Playback

4.2.1. Timing and Synchronization

4.2.2. Rendering Audio

4.2.3. Rendering EPUB Content Document Elements

4.3. Interacting with the EPUB Content Document

4.3.1. Navigation

4.3.2. Embedded Audio and Video

4.3.3. Text-to-Speech

4.4. Skippability and Escapability

4.4.1. Skippability

4.4.2. Escapability

A. Media Overlays Schema

A.1. Using the Media Overlays Schema

B. Examples of Clock Values

› 1 Overview

› 1.1 Purpose and Scope

This section is informative

This specification, EPUB Media Overlays 3.0, defines a usage of [SMIL] (Synchronized Multimedia Integration Language), the Package Document, the EPUB® Style Sheet, and the EPUB Content Document for representation of audio synchronized with the EPUB Content Document.

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 provides an informative overview of EPUB and a roadmap to the rest of the EPUB 3 documents. The Overview should be read first.

EPUB Publications 3.0 [Publications30], which defines publication-level semantics and overarching conformance requirements for EPUB Publications.

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.

› 1.2 Relationship to Other Specifications

This section is informative

This specification relies on a subset of [SMIL], from which the EPUB Media Overlays elements and attributes defined in Media Overlay Document Definition are derived.

› 1.4 Conformance Statements

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "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 Media Overlay Document Definition

› 2.1 Introduction

This section is informative

Books featuring synchronized audio narration are found in mainstream e-books, educational tools and e-books formatted for persons with print disabilities. In EPUB 3, these types of books are created by using Media Overlay Documents to describe the timing for the pre-recorded audio narration and how it relates to the EPUB Content Document markup. The file format for Media Overlays is defined as a subset of SMIL, a W3C recommendation for representing synchronized multimedia information in XML.

The Media Overlays feature is designed to be transparent to EPUB Reading Systems that do not support the feature. The inclusion of Media Overlays in an EPUB Publication has no impact on the ability of Media Overlay-unaware Reading Systems to render that Publication as a "regular" EPUB Publication.

Although future versions of this specification may incorporate support for video media (e.g., synchronized text/sign-language books), this version supports only synchronizing audio media with the EPUB Content Document.

› 2.2 Content Conformance

A Media Overlay Document must meet all of the following criteria:

Document Properties

›  It must meet the conformance constraints for XML documents defined in XML Conformance [Publications30].

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

› It must be authored to reflect the structure of the EPUB Content Document with which it is associated, as stated in Structure .

› Authors should avoid using scripts to control audio and video embedded in the EPUB Content Document, as stated in Embedded Audio and Video.

› It should use semantic markup where appropriate, as described in Semantic Inflection.

› It must be packaged with the EPUB Publication as shown in Packaging.

File Properties

› The Media Overlay Document filename should use the file extension .smil.

› 2.3 Reading System Conformance

EPUB Reading System support for Media Overlays is optional. A Reading System that supports Media Overlays must meet the following criteria:

› It must process the Media Overlay Document in conformance with all Reading System conformance constraints expressed in Media Overlay Document Definition.

› It must support XHTML Content Documents, and it may support SVG Content Documents.

› It must render Media Overlay elements as described in Basic Playback.

› It must allow User navigation while a Media Overlay is being played, as discussed in Navigation.

› It must adhere to rules regarding referenced audio and video embedded in the EPUB Content Document, as stated in Embedded Audio and Video.

› Text-to-Speech (TTS)-capable Reading Systems should conform to Reading System Text-to-Speech Conformance Requirements [Publications30].

› It should offer the skippability and escapability features described in Skippability and Escapability.

A Reading System that does not support Media Overlays must meet the following criteria:

› It must ignore both the media-overlay attribute on manifest item elements and the manifest item elements where the media-type attribute value equals application/smil+xml.

› 2.4 Media Overlay Document Definition

All elements [XML] defined in this section are in the http://www.w3.org/ns/SMIL namespace [XMLNS] unless otherwise specified.

› 2.4.1 The smil Element

The smil element must be the root element of all Media Overlay Documents.

Element Name

smil

Usage

The smil element is the root element of the Media Overlay Document.

Attributes

version [required]

Specifies the version number of the [SMIL] specification to which the Media Overlay adheres.

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

id [optional]

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

epub:prefix [optional]

Declares additional metadata vocabulary prefixes.

Refer to Semantic Inflection for more information.

Content Model

In this order: head [optional], body [required]

› 2.4.2 The head Element

The head element is the container for metadata in the Media Overlay Document, and consists of zero or one child metadata element.

Element Name

head

Usage

The head element is the optional first child of the smil element.

Attributes

None.

Content Model

metadata [0 or 1].

As this specification defines no metadata properties that must occur in the Media Overlay Document, the head element is optional.

› 2.4.3 The metadata Element

The metadata element represents metadata for the Media Overlay Document. The metadata element is an extension point that allows the inclusion of metadata from any metainformation structuring language.

Element Name

metadata

Usage

As a child of the head element.

Attributes

None.

Content Model

[0 or more] elements from any namespace.

This specification defines no metadata properties that must occur in the Media Overlay Document; the metadata element is provided for custom metadata requirements.

› 2.4.4 The body Element

The body element is the starting point for the presentation contained in the Media Overlay Document. It contains the main sequence of par and seq elements.

Element Name

body

Usage

The body element is the required second child of the smil element.

Attributes

epub:type [optional]

An expression of the structural semantics of the corresponding element in the EPUB Content Document.

The value is a whitespace separated list of property [Publications30] types. Refer to Semantic Inflection for more information.

id [optional]

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

epub:textref [optional]

The relative IRI reference [RFC3987] of the corresponding EPUB Content Document, including a fragment identifier that references the specific element as per the [XPTRSH].

Content Model

In any order: seq [0 or more] or par [0 or more]

At least one par or seq is required.

› 2.4.5 The seq Element

The seq element contains media objects which are to be rendered sequentially.

Element Name

seq

Usage

One or more seq elements may occur as children of the body element and of the seq element.

Attributes

epub:type [optional]

An expression of the structural semantics of the corresponding element in the EPUB Content Document.

The value is a whitespace separated list of property [Publications30] types. Refer to Semantic Inflection for more information.

id [optional]

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

epub:textref [required]

The relative IRI reference [RFC3987] of the corresponding EPUB Content Document, including a fragment identifier that references the specific element as per the [XPTRSH].

Content Model

In any order: seq [0 or more] or par [0 or more].

At least one par or seq is required.

› 2.4.6 The par Element

The par element contains media objects which are to be rendered in parallel.

Element Name

par

Usage

One or more par elements may occur as children of the body and seq elements.

Attributes

epub:type [optional]

An expression of the structural semantics of the corresponding element in the EPUB Content Document.

The value is a whitespace separated list of property [Publications30] types. Refer to Semantic Inflection for more information.

id [optional]

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

Content Model

In any order: text [required] and audio [optional]

The audio element is optional only if its sibling text element refers to audio or video media (see Embedded Audio and Video), or to textual content intended for rendering via Text-to-Speech (TTS).

› 2.4.7 The text Element

The text element references an element in the EPUB Content Document. A text element typically refers to a textual element, but can also refer to other EPUB Content Document media elements (see Embedded Audio and Video).

Element Name

text

Usage

As a required child of the par element.

Attributes

src [required]

The relative IRI reference [RFC3987] of the corresponding EPUB Content Document, including a fragment identifier that references the specific element as per the [XPTRSH].

id [optional]

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

Content Model

Empty.

› 2.4.8 The audio Element

The audio element represents a clip of audio media.

Element Name

audio

Usage

A required child of the par element unless its sibling text element refers to audio or video media, in which case it is optional (see Embedded Audio and Video).

Attributes

id [optional]

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

src [required]

The relative or absolute IRI reference [RFC3987] of an audio file. The audio file must be one of the audio formats listed in the Core Media Types [Publications30] table.

clipBegin [optional]

A clock value that specifies the offset into the physical media corresponding to the start point of an audio clip.

Clock values are a subset of SMIL clock values, defined in [SMIL]. See Appendix B, Examples of Clock Values.

clipEnd [optional]

A clock value that specifies the offset into the physical media corresponding to the end point of an audio clip.

Clock values are a subset of SMIL clock values, defined in [SMIL]. See Appendix B, Examples of Clock Values.

The chronological offset of the terminating position must be after the starting offset specified in the clipBegin attribute.

Content Model

Empty.

› 3 Creating Media Overlays

› 3.1 Overview

This section is informative

A pre-recorded narration of a publication can be represented as a series of audio clips, each corresponding to part of the EPUB Content Document. A single audio clip, for example, typically represents a single phrase or paragraph, but infers no order relative to the other clips or to the text of a document. Media Overlays solve this problem of synchronization by tying the structured audio narration to its corresponding text (or other media) in the EPUB Content Document using SMIL markup. Media Overlays are, in fact, a simplified subset of SMIL 3.0 that allow the playback sequence of these clips to be defined.

The SMIL elements primarily used for structuring Media Overlays are body (used for the main sequence), seq (sequence) and par (parallel). (Refer to Media Overlay Document Definition for more information on these and other SMIL elements.)

The par element is the basic building block of an Overlay and corresponds to a phrase in the EPUB Content Document. The element provides two key pieces of information for synchronizing content: 1) the audio clip containing the narration for the phrase; and 2) a pointer to the associated EPUB Content Document fragment. The par element uses two media element children to represent this information: an audio element and a text element. Since par elements render their children in parallel, the audio clip and EPUB Content Document fragment are played at the same time, resulting in a synchronized presentation.

The text element src attribute references the associated phrase, sentence, or other segment of the EPUB Content Document by its IRI reference. The audio element src attribute similarly references the location of the corresponding audio clip, and adds the optional clipBegin and clipEnd attributes to indicate a specific offset within the clip.

The following example shows the Media Overlays markup for a single phrase or sentence.

<par>
    <text src="chapter1.xhtml#sentence1"/>
    <audio src="chapter1_audio.mp3" clipBegin="23s" clipEnd="30s"/>
</par>

par elements are placed together sequentially to form a series of phrases or sentences. Not every element of the EPUB Content Document will have a corresponding par element in the Media Overlay, only those relevant to the audio narration.

The following example shows a basic Media Overlay Document containing a sequence of phrases. The body element acts as the main sequence for the whole document.

<smil xmlns="http://www.w3.org/ns/SMIL"
      version="3.0">
    <body>
        <par id="par1">
            <text src="chapter1.xhtml#sentence1"/>
            <audio src="chapter1_audio.mp3" clipBegin="0s" clipEnd="10s"/>
        </par>
        <par id="par2">
            <text src="chapter1.xhtml#sentence2"/>
            <audio src="chapter1_audio.mp3" clipBegin="10s" clipEnd="20s"/>
        </par>
        <par id="par3">
            <text src="chapter1.xhtml#sentence3"/>
            <audio src="chapter1_audio.mp3" clipBegin="20s" clipEnd="30s"/>
        </par>
    </body>
</smil>

par elements can also be added to seq elements to define more complex structures such as parts and chapters (see Structure ).

› 3.2 Relationship to the EPUB Content Document

note

In this section, the EPUB Content Document is assumed to be an XHTML Content Document. While Media Overlays can be used with SVG Content Documents, playback behavior might not be consistent and therefore interoperability is not guaranteed.

› 3.2.1 Structure

The ordering of the Media Overlay elements must match the default reading order of the EPUB Content Document. The par element represents phrases, and the seq element (sequence) represents nested EPUB Content Document containers such as sections, asides, headers, and footnotes. seq children must be other seq or par elements. Each seq element must contain an epub:textref attribute which references the corresponding EPUB Content Document element by IRI reference.

The following example shows a Media Overlay Document with nested seq elements, representing a chapter with both a section header and a sidebar, which itself has a nested figure.

<smil xmlns="http://www.w3.org/ns/SMIL"
      xmlns:epub="http://www.idpf.org/2007/ops"
      version="3.0">
    <body>

        <!-- a chapter -->
        <seq id="id1" epub:textref="chapter1.xhtml#sectionstart" epub:type="chapter">

            <!-- the section title -->
            <par id="id2">
                <text src="chapter1.xhtml#section1_title"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:23:23.84" clipEnd="0:23:34.221"/>
            </par>

            <!-- some sentences in the chapter -->
            <par id="id3">
                <text src="chapter1.xhtml#text1"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:23:34.221" clipEnd="0:23:59.003"/>
            </par>
            <par id="id4">
                <text src="chapter1.xhtml#text2"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:23:59.003" clipEnd="0:24:15.000"/>
            </par>

            <!-- an informational sidebar -->
            <seq id="id5" epub:textref="chapter1.xhtml#sidebar" epub:type="sidebar">
                <par id="id6">
                    <text src="chapter1.xhtml#sidebartitle"/>
                    <audio src="chapter1_audio.mp3" clipBegin="0:24:15.000" clipEnd="0:24:18.123"/>
                </par>

                <!-- a figure within the sidebar -->
                <seq id="id7" epub:textref="chapter1.xhtml#figure">
                    <par id="id8">
                        <text src="chapter1.xhtml#photo"/>
                        <audio src="chapter1_audio.mp3" clipBegin="0:24:18.123" clipEnd="0:24:28.764"/>
                    </par>
                    <par id="id9">
                        <text src="chapter1.xhtml#caption"/>
                        <audio src="chapter1_audio.mp3" clipBegin="0:24:28.764" clipEnd="0:24:50.010"/>
                    </par>
                </seq>

                <!-- some sentences in the sidebar -->
                <par id="id10">
                    <text src="chapter1.xhtml#sidebartext1"/>
                    <audio src="chapter1_audio.mp3" clipBegin="0:24:50.010" clipEnd="0:25:28.530"/>
                </par>
                <par id="id11">
                    <text src="chapter1.xhtml#sidebartext2"/>
                    <audio src="chapter1_audio.mp3" clipBegin="0:25:28.530" clipEnd="0:25:45.515"/>
                </par>
            </seq>

            <!-- more sentences in the chapter (outside the sidebar) -->
            <par id="id12">
                <text src="chapter1.xhtml#text3"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:25:45.515" clipEnd="0:26:30.203"/>
            </par>
            <par id="id13">
                <text src="chapter1.xhtml#text4"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:26:30.203" clipEnd="0:27:15.000"/>
            </par>

        </seq>
    </body>
</smil>

The reason for grouping structures like sidebars, section headers, figures, tables, and footnotes in a seq element is so that their start and end positions can be identified during playback. Reading Systems can then offer playback options tailored to the layout of the Publication, such as jumping past a long sidebar, turning off rendering of page break announcements (see Skippability and Escapability), or customizing the reading mode to suit structures such as tables.

The following example shows the EPUB Content Document that corresponds to the previous Media Overlay example.

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:epub="http://www.idpf.org/2007/ops"
      xml:lang="en"
      lang="en">
    <head>
        <title>Media Overlays Example of EPUB Content Document</title>
    </head>
    <body id="sec1">
        <section id="sectionstart" epub:type="chapter">
            <h1 id="section1_title">The Section Title</h1>
            <p id="text1">The first phrase of the main text body.</p>
            <p id="text2">The second phrase of the main text body.</p>
            <aside id="sidebar" epub:type="sidebar">
                <h2 id="sidebartitle">The Sidebar Title</h2>
                <figure id="figure">
                    <img id="photo"
                         src="photo.png"
                         alt="a photograph for which there is a caption" />
                    <figcaption id="caption">The photo caption</figcaption>
                </figure>
                <p id="sidebartext1">A phrase in the sidebar.</p>
                <p id="sidebartext2">Another phrase in the sidebar</p>
            </aside>
            <p id="text3">The third phrase of the main text body.</p>
            <p id="text4">The fourth phrase of the main text body.</p>
        </section>
    </body>
</html>

› 3.2.2 Granularity

This section is informative

Media Overlay text elements' src attributes refer to EPUB Content Document elements by their IDs [XML]. The granularity level of the Media Overlay therefore depends on how the EPUB Content Document is marked up. If the finest level of markup is at the paragraph level, then that is the finest possible level at which Media Overlay synchronization can be authored. Likewise, if sub-paragraph markup is available, such as [HTML5] span elements representing phrases or sentences, then finer granularity is possible in the Media Overlay. Finer granularity gives Users more precise results for synchronized playback when navigating by word or phrase and when searching the text, but increases the file size of the Media Overlay Documents.

› 3.2.3 Embedded Audio and Video

Any EPUB Content Document associated with a Media Overlay may contain embedded media such as video, audio, and images. The Media Overlay text element may be used in such instances to reference the embedded media by its ID [XML] value.

When a text element references embedded media that contains audio, no audio sibling element is required, though one is allowed.

Authors should avoid using scripts to control playback of referenced embedded EPUB Content Document media, as this may conflict with Media Overlays playback behavior.

› 3.2.4 Text-to-Speech

This specification allows the use of Text-to-Speech (TTS) in addition to pre-recorded audio clips. When a Media Overlay text element with no audio sibling element references an element within the target EPUB Content Document, the contents of that referenced element must be appropriate for rendering via TTS. For example, it could be a textual EPUB Content Document element or contain a text fallback.

› 3.3 Semantic Inflection

In order to express semantic inflections, the epub:type attribute [ContentDocs30] may be attached to Media Overlay par, seq, and body elements.

Values for the Media Overlay epub:type attribute are constrained identically to the epub:type attribute in EPUB Content Document. Refer to Semantic Inflection [ContentDocs30] for details.

The epub:type attribute facilitates Reading System behavior appropriate for the semantic type(s) indicated. Examples of these behaviors are Skippability and Escapability and Table Reading Mode.

The following example shows the semantic markup for a Media Overlay containing a sidebar.

<smil xmlns="http://www.w3.org/ns/SMIL"
      xmlns:epub="http://www.idpf.org/2007/ops"
      version="3.0">
    <body>
        <seq id="id1" epub:textref="chapter1.xhtml#sidebar" epub:type="sidebar">
            <par id="id2">
                <text src="chapter1.xhtml#sidebartitle"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:24:15.000" clipEnd="0:24:18.123"/>
            </par>
            <par id="id3">
                <text src="chapter1.xhtml#sidebartext1"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:24:18.123" clipEnd="0:24:38.530"/>
            </par>
            <par id="id4">
                <text src="chapter1.xhtml#sidebartext2"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:24:38.530" clipEnd="0:25:00.515"/>
            </par>
        </seq>
    </body>
</smil>

This specification adopts the vocabulary association mechanisms defined in Vocabulary Association [ContentDocs30] unmodified. Terms from the default vocabulary [ContentDocs30] must be used unprefixed in Overlay Documents.

› 3.4 Associating Style Information

Visual rendering information for the currently-playing EPUB Content Document element may be expressed in the EPUB Style Sheet using an author-defined class. This author-defined class name should be declared in the Package Document metadata, using the metadata property active-class. The class name is then discoverable by Reading Systems.

This example demonstrates how authors may associate style information with the currently-playing EPUB Content Document element.

note

Although this example uses the class name -epub-media-overlay-active, any class name is permitted.

The author-defined CSS class name, declared using the metadata property active-class in the Package Document:

<meta property="media:active-class">-epub-media-overlay-active</meta>

The EPUB Style Sheet containing the author-defined class name:

.-epub-media-overlay-active
{
    background-color: yellow;
}

The relevant EPUB Content Document excerpt:

<span id="txt1">This is the first phrase.</span>
<span id="txt2">This is the second phrase.</span>
<span id="txt3">This is the third phrase.</span>

In this example, the Reading System would apply the author-defined -epub-media-overlay-active class to each text element in the EPUB Content Document as it became active during playback. Conversely, the class name is removed when the element is no longer active. The User would see each EPUB Content Document element styled with a yellow background for the duration of that element's playback.

› 3.5 Packaging

› 3.5.1 Including Media Overlays

Manifest item elements [Publications30] in the Package Document may specify a Media Overlay via the media-overlay attribute. Media Overlays are themselves manifest items and must be referred to by their IDs [XML].

The following example shows how to include Media Overlays in the manifest of a Package Document.

<manifest>
    <item id="ch1"
          href="chapter1.xhtml"
          media-type="application/xhtml+xml"
          media-overlay="ch1_audio"/>
    <item id="ch1_audio"
          href="chapter1_audio.smil"
          media-type="application/smil+xml"/>
</manifest>

Manifest items which refer to Media Overlays must have the media-type application/smil+xml as specified in Core Media Types [Publications30].

The media-overlay attribute must be attached to manifest items that reference EPUB Content Documents only.

A single Media Overlay file may refer to more than one EPUB Content Document, but an EPUB Content Document must not be referenced by more than one Media Overlay file.

Not every EPUB Content Document manifest item is required to have a Media Overlay associated with it. If an EPUB Content Document is wholly or partially referenced by a Media Overlay, then its manifest item entry must indicate this via the media-overlay attribute.

This is a forwards-compatible addition: 2.0 Reading Systems may safely ignore the media-overlay attribute and process documents in their normal fashion.

› 3.5.2 Media Overlays Metadata Vocabulary

The following tables both define a set of properties for use in Package Document metadata and constitute a referenceable vocabulary.

The base IRI for referencing this vocabulary is http://www.idpf.org/epub/vocab/overlays/#.

note

The prefix media: is reserved by [Publications30] for the inclusion of these properties in package metadata.

› active-class
Description: | Author-defined CSS class name to apply to the currently-playing EPUB Content Document element.
Allowed value(s): | xsd:string
Cardinality: | zero or one
Example: | <meta property="media:active-class">-epub-media-overlay-active</meta>

› duration
Description: | The duration of the entire presentation or of a specific Media Overlay. The specified durations account for the audio clips known at authoring time, and so exclude live streaming from external resources and speech synthesis.
Allowed value(s): | A clock value. Clock values are a subset of SMIL clock values, defined in [SMIL]. See Appendix B, Examples of Clock Values.
Cardinality: | Exactly one for the Publication and for each Media Overlay.
Example: | <meta property="media:duration">1:36:20</meta>

› narrator
Description: | Name of the narrator.
Allowed value(s): | xsd:string
Cardinality: | zero or more
Example: | <meta property="media:narrator">Joe Speaker</meta>

The Package Document must include the duration of each Media Overlay as well as of the entire Publication. The Package Document may include narrator information, as well, in particular when each Media Overlay has its own narrator or there is one narrator specified for the entire Publication. The Package Document may also include an author-defined CSS class name to be applied to the currently-playing EPUB Content Document element.

When a meta element is specific to a single Media Overlay Document, the about attribute is used to reference which one. A meta element without an about attribute is considered to be about the entire Publication. The active-class property must not be used in conjunction with an about attribute, as it is always considered to apply to the entire Publication.

The following example shows a Package Document with metadata about Media Overlays.

<package>
    <metadata>
        …
        <meta property="media:duration" refines="#ch1_audio">0:32:29</meta>
        <meta property="media:duration" refines="#ch2_audio">0:34:02</meta>
        <meta property="media:duration" refines="#ch3_audio">0:29:49</meta>
        <meta property="media:duration">1:36:20</meta>
        <meta property="media:narrator">Joe Speaker</meta>
        <meta property="media:active-class">-epub-media-overlay-active</meta>
        …
    </metadata>
    …
</package>

› 4 Playback Behaviors

› 4.1 Loading the Media Overlay

When an EPUB Reading System loads a Package Document, it must refer to the manifest item elements' media-overlay attributes to discover the corresponding Media Overlays for EPUB Content Documents. Playback must start at the Media Overlay element which corresponds to the desired EPUB Content Document starting point. Note that the start of an EPUB Content Document may correspond to an element at the start or in the middle of a Media Overlay. When the Media Overlay Document has finished playing, the Reading System should load the next EPUB Content Document (as specified in the Package Document spine) and also load its corresponding Media Overlay Document, provided that one is given.

› 4.2 Basic Playback

› 4.2.1 Timing and Synchronization

Reading Systems must render immediate children of the body element in a sequence. A seq element's children must be rendered in sequence, and playback completes when the last child has finished playing. A par element's children must be rendered in parallel (with each starting at the same time), and playback completes when all the children have finished playing. When the body element's last child has finished playing, playback of the Media Overlay Document is done.

› 4.2.2 Rendering Audio

When presented with a Media Overlay audio element, Reading Systems must play the audio resource referenced by the src attribute, starting at the clip offset time given by the clipBegin attribute and ending at the clip offset time given by the clipEnd attribute. The following rules must be observed:

If clipBegin is not specified, its value is assumed to be 0.

If clipEnd is not specified, its value is assumed to be the full duration of the physical media.

If clipEnd exceeds the full duration of the physical media, then its value is assumed to be the full duration of the physical media.

User-controllable audio playback options should include timescale modification, in which the playback rate is altered without distorting the pitch. The suggested range is half-speed to double-speed.

› 4.2.3 Rendering EPUB Content Document Elements

When presented with a Media Overlay text element, Reading Systems should ensure the EPUB Content Document element referenced by the src attribute is visible in the Viewport. Reading Systems with a CSS Viewport should add the class name given by the metadata property active-class to the actively-playing EPUB Content Document element. Conversely, the class name should be removed when the element is no longer active.

The active-class metadata property is optional, and if omitted, Reading System behavior is implementation-specific.

› 4.3 Interacting with the EPUB Content Document

› 4.3.1 Navigation

Because the Media Overlay is closely linked to the EPUB Content Document, it is very easy for Reading Systems to locate a position in the EPUB Content Document based on the current position in the Media Overlay playback. If the User pauses synchronized playback and navigates to a different part of the Publication, synchronized playback must resume at that point. For example, if a specific page number in the EPUB Content Document is the desired location, then this same point is located in the Media Overlay and playback started there.

This same approach allows for synchronizing the Media Overlay playback with User selection of a navigation points in the EPUB Navigation Document. The Reading System loads the Media Overlay for that file and finds the correct point for starting playback based on the ID [XML] of the navigation point target.

note

A Media Overlay Document may also be associated directly with a Navigation Document in order to provide synchronized playback of its contents, regardless of whether the XHTML Content Document in which it resides is included in the spine. The Reading System should keep playback of the Navigation Document's Media Overlay synchronized with the User's current position in the EPUB Content Document.

› note

Media Overlay Document elements may be associated with EPUB Content Document structures such as tables. Reading Systems should ensure that Media Overlay playback remains synchronized with User navigation of table rows and cells. The Reading System may also play the corresponding table header preceding the contents of the cell.

› 4.3.2 Embedded Audio and Video

An EPUB Content Document with which a Media Overlay is associated may itself contain embedded video and audio media, which may be pointed to by Media Overlay elements. Unlike text and images, video and audio media has an intrinsic duration. Consequently, when a Reading System renders the synchronization described by a Media Overlay, the default playback behavior of audio and video media embedded within the associated EPUB Content Document must be overridden.

Note that the rules below apply only to referenced [HTML5] video or audio elements within the associated EPUB Content Document. That is to say, the rules apply to only those elements pointed to by text elements within the Media Overlay (i.e., via the src attribute). Embedded media that is not referenced by Media Overlay elements is not subject to these rules.

All referenced audio and video media embedded within an EPUB Content Document must have their public playback interface deactivated (typically: play/pause control, time slider, volume level, etc.). This behavior is required to avoid interference between the scheduled playback sequence defined by the Media Overlay, and the arbitrary playback behavior due to User interaction or script execution. As a result, when the Reading System is in playback mode, it should:

Hide the individual video/audio UI controls from the page, which overrides the default behavior defined by the [HTML5] controls attribute.

Prevent scripts embedded within the EPUB Content Document from invoking the JavaScript audio/video playback API (i.e., authored as part of the default Publication behavior). It is recommended that content producers should avoid publishing embedded scripts dedicated to controlling the playback of embedded audio/video media. The published Media Overlay can then retain full control of the synchronized presentation without any risk of interference from script-enabled custom behaviors.

All referenced audio and video media embedded within an EPUB Content Document must be initialized to their "stopped" state, and be ready to be played from the zero-position within their content stream (possibly displaying the image specified using the [HTML5] poster attribute). This requirement overrides the default behavior defined by the [HTML5] autoplay attribute.

When an EPUB Content Document element becomes active, the EPUB Style Sheet visual highlighting rules apply regardless of the content type referred to by that element's src attribute (e.g., the CSS class name defined by the active-class metadata property should be applied to visible video and audio player controls within the host EPUB Content Document).

In addition to the default behavior of Media Overlay activation for textual fragments and images, audio and video playback must be started and stopped according to the duration implied by the authored Media Overlay synchronization (as per the standard [SMIL] timing model). There are two possible scenarios:

When a Media Overlay text element has no audio sibling within its par parent container, the referenced EPUB Content Document audio or video media must play until it ends, at which point the text element's lifespan terminates. In this case, the implicit duration of the text element (and by inference, of the parent par container) is that of the referenced audio or video clip.

When a Media Overlay text element has an audio sibling within its par parent container, the playback duration of the referenced EPUB Content Document audio or video media must be constrained by the duration of the audio sibling. In this case, the actual duration of the parent par container is that of the child audio clip, regardless of the duration of the video or audio media pointed to by the text element. This behavior may result in embedded video or audio media ending playback prematurely (before reaching its full duration), or ending before the playback of the parallel Media Overlay audio is finished (in which case the last-played video frame should remain visible until the parent par container finally ends). This behavior is equivalent of the Media Overlay audio element implicitly carrying the behavior of the [SMIL] endsync attribute.

Furthermore, Reading Systems should expose User controls for the volume levels of each independent audio track (i.e., from the audio element of the Media Overlay, and from the embedded audio or video media within the EPUB Content Document), so that audio output can be adjusted to match listeners' requirements. Note that having overlapping audio tracks is typically an authoring-time concern: content producers usually add a layer of audio information over a video track for description purposes. It is recommended that overlapping audio situations are carefully examined and dealt with at production stage, as Reading Systems are not required to handle simultaneous volume levels in any particular way.

When a text element becomes inactive in the Media Overlay, and when it points to embedded video or audio media, that referenced media must be reset to its initial "stopped" state, ready to be played from the zero-position within their content stream (possibly displaying the poster image specified using the HTML5 markup).

› 4.3.3 Text-to-Speech

When a Media Overlay text element with no audio sibling element references text within the target EPUB Content Document, Reading Systems capable of Text-to-Speech (TTS) should render the referenced text using TTS.

As per Reading System conformance requirements, the speech-related information provided in the target EPUB Content Document should be used to play the audio stream as part of the Media Overlay rendering. See Reading System Text-to-Speech Conformance Requirements [Publications30].

The Media Overlay text element's lifespan corresponds to the rendering time of the associated speech synthesis. The implicit duration of the text element (and by inference, of the parent par element) is therefore determined by the execution of the Text-to-Speech engine, and cannot be known at authoring time (factors like speech rate, pauses and other prosody parameters influence the audio output).

› 4.4 Skippability and Escapability

› 4.4.1 Skippability

While reading, Users may want to turn on or off certain features of the Publication, such as sidebars, footnotes, page numbers, or other types of secondary content. This feature is called skippability. Reading Systems should use the semantic information provided by Media Overlay elements' epub:type attribute to determine when to offer Users the option of skippable features. In the following example, a Reading System should offer the User the option of turning on and off the page break/page number announcements, which are often cumbersome to listen to.

The following example shows a Media Overlay Document with a pagebreak.

<smil xmlns="http://www.w3.org/ns/SMIL"
      xmlns:epub="http://www.idpf.org/2007/ops"
      version="3.0">
    <body>
        <!-- a paragraph -->
        <par id="id1">
            <text src="chapter1.xhtml#para1"/>
            <audio src="chapter1_audio.mp3" clipBegin="0:23:22.000" clipEnd="0:24:15.000"/>
        </par>

        <!-- a page number -->
        <par id="id2" epub:type="pagebreak">
            <text src="chapter1.xhtml#pgbreak1"/>
            <audio src="chapter1_audio.mp3" clipBegin="0:24:15.000" clipEnd="0:24:18.123"/>
        </par>

        <!-- another paragraph -->
        <par id="id3">
            <text src="chapter1.xhtml#para2"/>
            <audio src="chapter1_audio.mp3" clipBegin="0:24:18.123" clipEnd="0:25:28.530"/>
        </par>
    </body>
</smil>

The following example shows an EPUB Content Document with a pagebreak.

<html … >
    …
    <body>
        <p id="para1">This is the paragraph before the pagebreak … </p>

        <br id="pgbreak1" epub:type="pagebreak" title="234"/>

        <p id="para2">This is the paragraph after the pagebreak …</p>
    </body>
</html>

The following selection of terms from the [StructureVocab] for which Reading Systems should offer Users the option of skippability is provided as an informative reference:

sidebar

practice

marginalia

annotation

help

note

footnote

rearnote

pagebreak

Media Overlays may use additional vocabularies by defining them in the epub:prefix attribute on the root smil element. Reading System support for skippability based on epub:type values should not be assumed.

› 4.4.2 Escapability

Escapable items are nested structures such as tables, lists, and sidebars that listeners may wish to skip over, continuing to read from the point immediately after the nested structure. The escapability feature differs from the skippability feature in that it does not enable or disable entire types of items, but provides an exit from them (e.g., a User can listen to some of the content before choosing to escape). Reading Systems should allow escaping of nested structures. Reading Systems must determine the start of nested structures by the value of the epub:type attribute (e.g., glossary) and should offer Users the option to skip playback of that structure and resume with whatever content comes after it.

The following example shows the Media Overlay Document for an EPUB Content Document containing a paragraph, a glossary, and another paragraph. A Reading System that supported escapability would give the User the option to interrupt playback of the glossary and continue playing the document paragraphs.

<smil xmlns="http://www.w3.org/ns/SMIL"
      xmlns:epub="http://www.idpf.org/2007/ops"
      version="3.0">
    <body>
        <!-- a paragraph, part of the regular document text -->
        <par id="id1">
            <text src="chapter1.xhtml#para1"/>
            <audio src="chapter1_audio.mp3" clipBegin="0:23:22.000" clipEnd="0:24:15.000"/>
        </par>

        <!-- a glossary, which is a nested structure -->
        <seq id="id2" epub:textref="chapter1.xhtml#g0" epub:type="glossary">
            <par id="id3" epub:type="glossterm">
                <text src="chapter1.xhtml#g1"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:24:15.000" clipEnd="0:24:18.123"/>
            </par>
            <par id="id4" epub:type="glossdef">
                <text src="chapter1.xhtml#g2"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:24:18.123" clipEnd="0:25:28.530"/>
            </par>
            <par id="id5" epub:type="glossterm">
                <text src="chapter1.xhtml#g3"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:25:28.530" clipEnd="0:25:45.515"/>
            </par>
            <par id="id6" epub:type="glossdef">
                <text src="chapter1.xhtml#g4"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:25:45.515" clipEnd="0:27:04.123"/>
            </par>
        </seq>

        <!-- another paragraph, part of the document text that comes after the glossary -->
        <par id="id7">
            <text src="chapter1.xhtml#para2"/>
            <audio src="chapter1_audio.mp3" clipBegin="0:27:04.123" clipEnd="0:27:59.000"/>
        </par>
    </body>
</smil>

› Appendix A. Media Overlays Schema

The schema for Media Overlays is available at ../schema/media-overlay-30.nvdl.

This schema is normative.

› A.1 Using the Media Overlays Schema

This section is informative

Validation of Media Overlays 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 two-pass validation using the embedded RELAX NG and ISO Schematron schemas alone.

› Appendix B. Examples of Clock Values

This appendix is informative

The following are examples of allowed clock values:

5:34:31.396 = 5 hours, 34 minutes, 31 seconds and 396 milliseconds

124:59:36 = 124 hours, 59 minutes and 36 seconds

0:05:01.2 = 5 minutes, 1 second and 200 milliseconds

0:00:04 = 4 minutes

09:58 = 9 minutes and 58 seconds

00:56.78 = 56 seconds and 780 milliseconds

76.2s = 76.2 seconds = 76 seconds and 200 milliseconds

7.75h = 7.75 hours = 7 hours and 45 minutes

13min = 13 minutes

2345ms = 2345 milliseconds

12.345 = 12 seconds and 345 milliseconds

EPUB Open Container Format (OCF) 3.0

Recommended Specification 11 October 2011

This version

http://www.idpf.org/epub/30/spec/epub30-ocf-20111011.html

Latest version

http://www.idpf.org/epub/30/spec/epub30-ocf.html

Previous version

http://www.idpf.org/epub/30/spec/epub30-ocf-20110908.html

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

Please refer to the errata for this document, which may include some normative corrections.

Copyright © 2010, 2011 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Editors

James Pritchett, Learning Ally (formerly Recording for the Blind & Dyslexic)

Markus Gylling, DAISY Consortium

Table of Contents

1. Overview

1.1. Purpose and Scope

1.3. Conformance Statements

1.4. Content Conformance

1.5. Reading System Conformance

2. OCF Abstract Container

2.1. Overview

2.2. File and Directory Structure

2.3. Relative IRIs for Referencing Other Components

2.4. File Names

2.5. META-INF

2.5.1. Container – META-INF/container.xml

2.5.2. Encryption – META-INF/encryption.xml

2.5.3. Manifest – META-INF/manifest.xml

2.5.4. Metadata – META-INF/metadata.xml

2.5.5. Rights Management – META-INF/rights.xml

2.5.6. Digital Signatures – META-INF/signatures.xml

3. OCF ZIP Container

3.1. Overview

3.2. ZIP File Requirements

3.3. OCF ZIP Container Media Type Identification

4. Font Obfuscation

4.1. Introduction

4.2. Obfuscation Algorithm

4.3. Generating the Obfuscation Key

4.4. Specifying Obfuscated Resources

A. Schemas

A.1. Schema for container.xml

A.2. Schema for encryption.xml

A.3. Schema for signatures.xml

B. Example

C. The application/epub+zip Media Type

› 1 Overview

› 1.1 Purpose and Scope

This section is informative

This specification, EPUB Open Container Format (OCF) 3.0, defines a file format and processing model for encapsulating the sets of related resources that comprise one or more EPUB® Publications into a single-file container.

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 provides an informative overview of EPUB and a roadmap to the rest of the EPUB 3 documents. The Overview should be read first.

EPUB Publications 3.0 [Publications30], which defines publication-level semantics and overarching conformance requirements for EPUB Publications.

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

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

OCF is the required container technology for EPUB Publications. OCF may play a role in the following workflows:

During the preparation steps in producing an electronic Publication, OCF may be used as the container format when exchanging in-progress Publications between different individuals and/or different organizations.

When providing an electronic Publication from publisher or conversion house to the distribution or sales channel, OCF is the recommended container format to be used as the transport format.

When delivering the final Publication to an EPUB Reading System or User, OCF is the required format for the container that holds all of the assets that make up the Publication.

The OCF specification defines the rules for structuring the file collection in the abstract: the "abstract container". It also defines the rules for the representation of this abstract container within a ZIP archive: the "physical container". The rules for ZIP physical containers build upon the ZIP technologies used by [ODF]. OCF also defines a standard method for obfuscating embedded fonts for those EPUB Publications that require this functionality.

This specification supersedes Open Container Format (OCF) 2.0.1 [OCF2]. Refer to [EPUB3Changes] for information on differences between this specification and its predecessor.

› 1.3 Conformance Statements

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "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.

› 1.4 Content Conformance

› An OCF Abstract Container must meet the conformance constraints defined in OCF Abstract Container.

› An OCF ZIP Container (also referred to as an EPUB Container) must meet the conformance constraints defined in OCF ZIP Container.

› 1.5 Reading System Conformance

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

› It must process the OCF ZIP Container in conformance with all Reading System conformance constraints expressed in OCF ZIP Container.

› If it has a Viewport, it must support deobfuscation of fonts as defined in Font Obfuscation.

› 2 OCF Abstract Container

› 2.1 Overview

This section is informative

An OCF Abstract Container defines a file system model for the contents of the container. The file system model uses a single common root directory for all of the contents of the container. All (non-remote) resources for embedded Publications are located within the directory tree headed by the container’s root directory, although no specific file system structure is mandated for this. The file system model also includes a mandatory directory named META-INF that is a direct child of the container's root directory and is used to store the following special files:

container.xml [required]

Identifies the file that is the point of entry for each embedded Publication.

signatures.xml [optional]

Contains digital signatures for various assets.

encryption.xml [optional]

Contains information about the encryption of Publication resources. (This file is required if font obfuscation is used.)

metadata.xml [optional]

Used to store metadata about the container.

rights.xml [optional]

Used to store information about digital rights.

manifest.xml [allowed]

A manifest of container contents as allowed by Open Document Format [ODF].

Complete conformance requirements for the various files in META-INF are found in META-INF.

› 2.2 File and Directory Structure

The virtual file system for the OCF Abstract Container must have a single common root directory for all of the contents of the container.

The OCF Abstract Container must include a directory named META-INF that is a direct child of the container's root directory. Requirements for the contents of this directory are described in META-INF.

The file name mimetype in the root directory is reserved for use by OCF ZIP Containers, as explained in OCF ZIP Container.

All other files within the OCF Abstract Container may be in any location descendant from the container's root directory except within the META-INF directory.

It is recommended that the contents of each of the individual Publications be stored within its own dedicated directory under the container's root.

› 2.3 Relative IRIs for Referencing Other Components

Files within the OCF Abstract Container must reference each other via Relative IRI References ([RFC3987] and [RFC3986]). For example, if a file named chapter1.html references an image file named image1.jpg that is located in the same directory, then chapter1.html might contain the following as part of its content:

<img src="image1.jpg" alt="…" />

For Relative IRI References, the Base IRI [RFC3986] is determined by the relevant language specifications for the given file formats. For example, the CSS specification defines how relative IRI references work in the context of CSS style sheets and property declarations. Note that some language specifications reference RFCs that preceded RFC3987, in which case the earlier RFC applies for content in that particular language.

Unlike most language specifications, the Base IRIs for all files within the META-INF directory use the root directory for the Abstract Container as the default Base IRI. For example, if META-INF/container.xml has the following content:

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="OEBPS/Great Expectations.opf"
            media-type="application/oebps-package+xml" />
    </rootfiles>
</container>

then the path OEBPS/Great Expectations.opf is relative to the root directory for the OCF Abstract Container and not relative to the META-INF directory.

› 2.4 File Names

The term File Name represents the name of any type of file, either a directory or an ordinary file within a directory within an OCF Abstract Container.

For a given directory within the OCF Abstract Container, the Path Name is a string holding all directory File Names in the full path concatenated together with a / (U+002F) character separating the directory File Names. For a given file within the Abstract Container, the Path Name is the string holding all directory File Names concatenated together with a / character separating the directory File Names, followed by a / character and then the File Name of the file.

The File Name restrictions described below are designed to allow Path Names and File Names to be used without modification on most commonly used operating systems. This specification does not specify how an OCF Processor that is unable to represent OCF File and Path Names would compensate for this incompatibility.

In the context of an OCF Abstract Container, File and Path Names must meet all of the following criteria:

› File Names must be UTF-8 [Unicode] encoded.

› File Names must not exceed 255 bytes.

› The Path Name for any directory or file within the Abstract Container must not exceed 65535 bytes.

› File Names must not use the following [Unicode] characters, as these characters might not be supported consistently across commonly-used operating systems:

SOLIDUS: / (U+002F)

QUOTATION MARK: " (U+0022)

ASTERISK: * (U+002A)

FULL STOP as the last character: . (U+002E)

COLON: : (U+003A)

LESS-THAN SIGN: < (U+003C)

GREATER-THAN SIGN: > (U+003E)

QUESTION MARK: ? (U+003F)

REVERSE SOLIDUS: \ (U+005C)

DEL (U+007F)

C0 range (U+0000 … U+001F)

C1 range (U+0080 … U+009F)

Private Use Area (U+E000 … U+F8FF)

Non characters in Arabic Presentation Forms-A (U+FDDO … U+FDEF)

Specials (U+FFF0 … U+FFFF)

Tags and Variation Selectors Supplement (U+E0000 … U+E0FFF)

Supplementary Private Use Area-A (U+F0000 … U+FFFFF)

Supplementary Private Use Area-B (U+100000 … U+10FFFF)

› File Names are case sensitive.

› All File Names within the same directory must be unique following case normalization as described in section 3.13 of [Unicode].

› All File Names within the same directory should be unique following NFC or NFD normalization [TR15].

note

Some commercial ZIP tools do not support the full Unicode range and may support only the ASCII range for File Names. Content creators who want to use ZIP tools that have these restrictions may find it is best to restrict their File Names to the ASCII range. If the names of files cannot be preserved during the unzipping process, it will be necessary to compensate for any name translation which took place when the files are referenced by URI from within the content.

› 2.5 META-INF

All OCF Abstract Containers must include a directory called META-INF. This directory contains the files specified below. Files other than the ones defined below may be included in the META-INF directory; OCF Processors must not fail when encountering such files.

› 2.5.1 Container – META-INF/container.xml

All OCF Containers must include a file called container.xml within the META-INF directory. The container.xml file must identify the media type of, and paths to, the root files for the EPUB Publications included within the container.

The container.xml file must not be encrypted.

The schema for container.xml files is available in Schema for container.xml; container.xml files must be valid according to this schema after removing all elements and attributes from other namespaces (including all attributes and contents of such elements).

The rootfiles element must contain one or more rootfile elements, each of which must uniquely reference a Package Document representing a single Publication. The Publications stored in an OCF should be different renditions of the same Manifestation.

An OCF Processor must consider the first rootfile element within the rootfiles element to represent the default rendition for the contained Publication. Reading Systems are not required to use any rendition except the default one.

The following example shows a sample container.xml for an EPUB Publication with the root file OEBPS/My Crazy Life.opf (the Package Document):

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="OEBPS/My Crazy Life.opf"
            media-type="application/oebps-package+xml" />
    </rootfiles>
</container>

The following example shows SVG and XHTML renditions of The Sandman bundled in the same container:

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="SVG/Sandman.opf"
            media-type="application/oebps-package+xml" />
        <rootfile full-path="XHTML/Sandman.opf"
            media-type="application/oebps-package+xml" />
    </rootfiles>
</container>

The manifest element contained within the Package Document specifies the one and only manifest used for EPUB processing. Ancillary manifest information contained in the ZIP archive or in the optional manifest.xml file must not be used for EPUB processing purposes. Any extra files in the ZIP archive must not be used in the processing of the EPUB Publication (i.e., files within the ZIP archive that are not listed within the Package Document's manifest element, such as META-INF files or alternate derived renditions of the Publication).

The value of the full-path attribute must contain a path component (as defined by RFC3986) which must take the form of a path-rootless only (also defined by RFC 3986). The path components are relative to the root of the container in which they are used.

OCF Processors must ignore foreign elements and attributes within a container.xml file.

› 2.5.2 Encryption – META-INF/encryption.xml

An optional encryption.xml file within the META-INF directory at the root level of the container file system holds all encryption information on the contents of the container. This file is an XML document whose root element is encryption. The encryption element contains child elements of type EncryptedKey and EncryptedData as defined by [XML ENC Core]. Each EncryptedData element describes how one or more files within the container are encrypted. Consequently, if any resource within the container is encrypted, encryption.xml must be present to indicate that the resource is encrypted and provide information on how it is encrypted.

An EncryptedKey element describes each encryption key used in the container, while an EncryptedData element describes each encrypted file. Each EncryptedData element refers to an EncryptedKey element, as described in XML Encryption.

The schema for encryption.xml files is available in Schema for encryption.xml; encryption.xml files must be valid according to this schema.

OCF encrypts individual files independently, trading off some security for improved performance, allowing the container contents to be incrementally decrypted. Encryption in this way exposes the directory structure and file naming of the whole package.

OCF uses XML Encryption [XML ENC Core] to provide a framework for encryption, allowing a variety of algorithms to be used. XML Encryption specifies a process for encrypting arbitrary data and representing the result in XML. Even though an OCF Abstract Container may contain non-XML data, XML Encryption can be used to encrypt all data in an OCF Abstract Container. OCF encryption supports only the encryption of entire files within the container, not parts of files. The encryption.xml file, if present, must not be encrypted.

Encrypted data replaces unencrypted data in an OCF Abstract Container. For example, if an image named photo.jpeg is encrypted, the contents of the photo.jpeg resource should be replaced by its encrypted contents. When stored in a ZIP container, streams of data must be compressed before they are encrypted and Deflate compression must be used. Within the ZIP directory, encrypted files should be stored rather than Deflate-compressed.

Some situations require obfuscating the storage of embedded fonts referenced by an EPUB Publication to tie them to the "parent" Publication and make them more difficult to extract for unrestricted use. In these cases, encryption.xml should be used to provide requisite font decoding information according to Font Obfuscation.

The following files must never be encrypted, regardless of whether default or specific encryption is requested:

mimetype

META-INF/container.xml

META-INF/encryption.xml

META-INF/manifest.xml

META-INF/metadata.xml

META-INF/rights.xml

META-INF/signatures.xml

EPUB rootfile (the Package Document)

Signed resources may subsequently be encrypted using the Decryption Transform for XML Signature [XML SIG Decrypt]. This feature enables an application such as an OCF agent to distinguish data that was encrypted before signing from data that was encrypted after signing. Only data that was encrypted after signing must be decrypted before computing the digest used to validate the signature.

In the following example, adapted from Section 2.2.1 of [XML ENC Core] the resource image.jpeg is encrypted using a symmetric key algorithm (AES) and the symmetric key is further encrypted using an asymmetric key algorithm (RSA) with a key of John Smith.

<encryption
    xmlns ="urn:oasis:names:tc:opendocument:xmlns:container"
    xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <enc:EncryptedKey Id="EK">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <ds:KeyInfo>
            <ds:KeyName>John Smith</ds:KeyName>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherValue>xyzabc</enc:CipherValue>
        </enc:CipherData>
    </enc:EncryptedKey>
    <enc:EncryptedData Id="ED1">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
        <ds:KeyInfo>
            <ds:RetrievalMethod URI="#EK"
                Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherReference URI="image.jpeg"/>
        </enc:CipherData>
    </enc:EncryptedData>
</encryption>

› 2.5.3 Manifest – META-INF/manifest.xml

An optional file with the reserved name manifest.xml may be included within the META-INF directory at the root level of the container file system.

The manifest.xml file, if present, must not be encrypted.

› 2.5.4 Metadata – META-INF/metadata.xml

An optional file with the reserved name metadata.xml may be included within the META-INF directory at the root level of the container file system. This file, if present, must be used for container-level metadata. This version of the OCF specification does not specify any container-level metadata.

If the META-INF/metadata.xml file is present, its contents should be only namespace-qualified elements [XMLNS] to avoid collision with future versions of OCF that may specify a particular format for this file.

The metadata.xml file, if present, must not be encrypted.

› 2.5.5 Rights Management – META-INF/rights.xml

An optional file with the reserved name rights.xml may be included within the META-INF directory at the root level of the container file system. This file is reserved for digital rights management (DRM) information for trusted exchange of Publications among rights holders, intermediaries, and users. This version of the OCF specification does not specify a required format for DRM information, but a future version may specify a particular format for DRM information.

If the META-INF/rights.xml file is present, its contents should be only namespace-qualified elements [XMLNS] to avoid collision with future versions of OCF that may specify a particular format for this file.

The rights.xml file must not be encrypted.

When the rights.xml file is not present, the OCF container provides no information indicating any part of the container is rights governed.

› 2.5.6 Digital Signatures – META-INF/signatures.xml

An optional signatures.xml within the META-INF directory at the root level of the container file system holds digital signatures of the container and its contents. This file is an XML document whose root element is signatures. The signatures element contains child elements of type Signature as defined by [XML DSIG Core]. Signatures can be applied to the Publication and any alternate renditions as a whole or to parts of the Publication and renditions. XML Signature can specify the signing of any kind of data, not just XML.

The signatures.xml file must not be encrypted.

When the signatures.xml file is not present, the OCF container provides no information indicating any part of the container is digitally signed at the container level. It is possible that digital signing exists within any optional alternate contained renditions, however.

The schema for signatures.xml files is available in Schema for signatures.xml; signatures.xml files must be valid according to this schema.

When an OCF agent creates a signature of data in a container, it should add the new signature as the last child Signature element of the signatures element in the signatures.xml file.

note

Each Signature in the signatures.xml file identifies by IRI the data to which the signature applies, using the XML Signature Manifest element and its Reference sub-elements. Individual contained files may be signed separately or together. Separately signing each file creates a digest value for the resource that can be validated independently. This approach may make a Signature element larger. If files are signed together, the set of signed files can be listed in a single XML Signature Manifest element and referenced by one or more Signature elements.

Any or all files in the container can be signed in their entirety with the exception of the signatures.xml file since that file will contain the computed signature information. Whether and how the signatures.xml file should be signed depends on the objective of the signer.

If the signer wants to allow signatures to be added or removed from the container without invalidating the signer’s signature, the signatures.xml file should not be signed.

If the signer wants any addition or removal of a signature to invalidate the signer’s signature, the Enveloped Signature transform (defined in Section 6.6.4 of [XML DSIG Core]) can be used to sign the entire preexisting signature file excluding the Signature being created. This transform would sign all previous signatures, and it would become invalid if a subsequent signature was added to the package.

If the signer wants the removal of an existing signature to invalidate the signer’s signature but also wants to allow the addition of signatures, an XPath transform can be used to sign just the existing signatures. (This is only a suggestion. The particular XPath transform is not a part of the OCF specification.)

XML-Signature does not associate any semantics with a signature; an agent may include semantic information, for example, by adding information to the Signature element that describes the signature. XML Signature describes how additional information can be added to a signature (for example, by using the SignatureProperties element).

The following XML expression shows the content of an example signatures.xml file, and is based on the examples found in Section 2 of [XML DSIG Core]. It contains one signature, and the signature applies to two resources, OEBFPS/book.html and OEBFPS/images/cover.jpeg, in the container.

<signatures xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <Signature Id="sig" xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
            <CanonicalizationMethod
                Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
            <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
            <Reference URI="#Manifest1">
                <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
            </Reference>
        </SignedInfo>
        <SignatureValue>…</SignatureValue>
        <KeyInfo>
            <KeyValue>
                <DSAKeyValue>
                    <P>…</P><Q>…</Q><G>…</G><Y>…</Y>
                </DSAKeyValue>
            </KeyValue>
        </KeyInfo>
        <Object>
            <Manifest Id="Manifest1">
                <Reference URI="OEBFPS/book.xml">
                    <Transforms>
                        <Transform
                            Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
                <Reference URI="OEBFPS/images/cover.jpeg">
                    <Transforms>
                        <Transform
                            Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
            </Manifest>
        </Object>
    </Signature>
</signatures>

› 3 OCF ZIP Container

› 3.1 Overview

This section is informative

An OCF ZIP Container is a physical single-file manifestation of an abstract container.

› 3.2 ZIP File Requirements

An OCF ZIP Container uses the ZIP format as specified by [ZIP APPNOTE], but with the following constraints and clarifications:

› The contents of the OCF ZIP Container must be a conforming abstract container.

› OCF ZIP Containers must not use the features in the ZIP application note that allow ZIP files to be split across multiple storage media. OCF Processors must treat any OCF files that specify that the ZIP file is split across multiple storage media as being in error.

› OCF ZIP Containers must include only uncompressed files or Deflate-compressed files within the ZIP archive. OCF Processors must treat any OCF Containers that use compression techniques other than Deflate as being in error.

› OCF ZIP Containers may use the ZIP64 extensions defined as "Version 1" in section V, subsection G of the application note at [ZIP APPNOTE] and should use only those extensions when the content requires them. OCF Processors must support the ZIP64 extensions defined as "Version 1".

› OCF ZIP Containers must not use the encryption features defined by the ZIP format; instead, encryption must be done using the features described in Encryption – META-INF/encryption.xml. OCF Processors must treat any other OCF ZIP Containers that use ZIP encryption features as being in error.

› It is not a requirement that OCF Processors preserve information from an OCF ZIP Container through load and save operations that is not defined within the OCF Abstract Container; in particular, an OCF Processor does not have to preserve CRC values, comment fields or fields that hold file system information corresponding to a particular operating system (e.g., External file attributes and Extra field).

› OCF ZIP Containers must encode File System Names using UTF-8 [Unicode].

The following constraints apply to particular fields in the OCF ZIP Container archive:

› In the local file header table, OCF ZIP Containers must set the version needed to extract fields to the values 10, 20 or 45 in order to match the maximum version level needed by the given file (e.g., 20 if Deflate is needed, 45 if ZIP64 is needed). OCF Processors must treat any other values as being in error.

› In the local file header table, OCF ZIP Containers must set the compression method field to the values 0 or 8. OCF Processors must treat any other values as being in error.

› OCF Processors must treat OCF ZIP Containers with an Archive decryption header or an Archive extra data record as being in error.

› 3.3 OCF ZIP Container Media Type Identification

OCF ZIP Containers must include a mimetype file as the first file in the Container, and the contents of this file must be the MIME type string application/epub+zip.

The contents of the mimetype file must not contain any leading padding or whitespace, must not begin with the Unicode signature (or Byte Order Mark), and the case of the MIME type string must be exactly as presented above. The mimetype file additionally must be neither compressed nor encrypted, and there must not be an extra field in its ZIP header.

note

Refer to Appendix C, The application/epub+zip Media Type for further information about the application/epub+zip media type.

› 4 Font Obfuscation

› 4.1 Introduction

This section is informative

Since an OCF Zip Container is fundamentally a ZIP file, commonly available ZIP tools can be used to extract any unencrypted content stream from the package. On some systems, the contents of the ZIP file may appear like any other native container (e.g., a folder). While the ability to do this is quite useful, it can pose a problem for an Author who wishes to include a third-party font.

Many commercial fonts allow embedding, but embedding a font implies making it an integral part of the Publication, not providing the original font file along with the content. Since integrated ZIP support is so ubiquitous in modern operating systems, simply placing the font in the ZIP archive is insufficient to signify that the font is not intended to be reused in other contexts. This uncertainty can undermine the otherwise very useful font embedding capability of EPUB Publications.

In order to discourage reuse of the font, some font vendors may allow use of their fonts in EPUB Publications if those fonts are bound in some way to the Publication. That is, if the font file cannot be installed directly for use on an operating system with the built-in tools of that computing device, and it cannot be directly used by other EPUB Publications.

It is beyond the scope of this document to provide a digital rights management or enforcement system for font files. It instead defines a method of obfuscation that will require additional work on the part of the final OCF recipient to gain general access to any included fonts. It is the hope of the IDPF that this will meet the requirements of most font vendors. No claim is made in this document or by the IDPF, that this constitutes encryption, nor does it guarantee that the font file will be secure from copyright infringement. The defined mechanism will simply provide a stumbling block for those who are unaware of the license details of the supplied font. It will not prevent a determined user from gaining full access to the font. Given an OCF Container, it is possible to apply the algorithms defined to extract the raw font file. Whether this satisfies the requirements of individual font licenses remains a question for the licensor and licensee.

› 4.2 Obfuscation Algorithm

The algorithm employed to obfuscate the font file consists of modifying the first 1040 bytes (~1KB) of the font file. In the unlikely event that the file is less than 1040 bytes, then the entire file will be modified. The key for the algorithm is generated using the instructions as given in the section Generating the Obfuscation Key. To obfuscate the original data, the result of performing a logical exclusive or (XOR) on the first byte of the raw file and the first byte of the key is stored as the first byte of the embedded font file. This process is repeated with the next byte of source and key, until all bytes in the key have been used. At this point, the process continues starting with the first byte of the key and 21st byte of the source. Once 1040 bytes have been encoded in this way (or the end of the source is reached), any remaining data in the source is directly copied to the destination. In pseudo-code, this is the algorithm:

set source to font file
set destination to obfuscated file
set keyData to key for font
set outer to 0
while outer < 52 and not (source at EOF)
    set inner to 0
    while inner < 20 and not (source at EOF)
        read 1 byte from source     //Assumes read advances file position
        set sourceByte to result of read
        set keyByte to byte inner of keyData
        set obfuscatedByte to (sourceByte XOR keyByte)
        write obfuscatedByte to destination
        increment inner
    end while
    increment outer
end while
if not (source at EOF) then
    read source to EOF
    write result of read to destination
end if

To get the original font data back, the process is simply reversed. That is, the source file becomes the obfuscated data and the destination file will contain the raw font data.

› 4.3 Generating the Obfuscation Key

The key used in the obfuscation algorithm is derived from unique identifer(s) of the Publication(s) in the Container, as required by the EPUB Publications 3.0 specification and detailed in Unique Identifier [Publications30]. In order to create the key, the unique identifiers of all Publications contained in the container must be concatenated in the order that the Publications appear in container.xml and a space (Unicode code point U+0020) inserted between each identifier. Before generating this string, all whitespace characters as defined by the XML 1.0 specification [XML], section 2.3 are removed from the individual identifiers. Specifically the Unicode code points U+0020, U+0009, U+000D and U+000A must be stripped from each identifier before it is added to the concanenated space-delimited string. An SHA-1 digest of the UTF-8 representation of this string should be generated as specified by the Secure Hash Standard [SHA-1]. This digest is then directly used as the key for the algorithm described in Obfuscation Algorithm.

› 4.4 Specifying Obfuscated Resources

All encrypted data in an OCF Abstract Container must have an entry in the encryption.xml file accompanying the Publication (see Encryption – META-INF/encryption.xml), which includes fonts obfuscated using the method described here. For such obfuscated fonts, in the encryption.xml file, the EncryptionMethod element child of the EncryptedData must have an Algorithm attribute with the value http://www.idpf.org/2008/embedding. The presence of this attribute signals the use of the algorithm described in this specification. All resources that have been obfuscated using this approach must be listed in the CipherData element.

An example encryption.xml file might look like this:

<encryption

    xmlns="urn:oasis:names:tc:opendocument:xmlns:container"

    xmlns:enc="http://www.w3.org/2001/04/xmlenc#">

    <enc:EncryptedData>

        <enc:EncryptionMethod Algorithm="http://www.idpf.org/2008/embedding"/>

        <enc:CipherData>

            <enc:CipherReference URI="OEBPS/Fonts/BKANT.TTF"/>

        </enc:CipherData>

    </enc:EncryptedData>

</encryption>

To prevent trivial copying of the embedded font to other Publications, the explicit key must not be provided in the encryption.xml file. Reading systems must derive the key from the package's Unique Identifier.

› Appendix A. Schemas

The schemas in this Appendix are normative.

› A.1 Schema for container.xml

The schema for container.xml files is available at http://www.idpf.org/epub/30/schema/ocf-container-30.rnc.

› A.2 Schema for encryption.xml

The schema for encryption.xml files is available at http://www.idpf.org/epub/30/schema/ocf-encryption-30.rnc. It is based on schemas in [XML Sec RNG Schemas].

› A.3 Schema for signatures.xml

The schema for signatures.xml files is available at http://www.idpf.org/epub/30/schema/ocf-signatures-30.rnc. It is based on schemas in [XML Sec RNG Schemas].

› Appendix B. Example

The following example demonstrates the use of this OCF format to contain a signed and encrypted EPUB Publication within a ZIP Container.

› 

Example B.1. Ordered list of files in the ZIP Container

mimetype
META-INF/container.xml
META-INF/signatures.xml
META-INF/encryption.xml
OEBPS/As You Like It.opf
OEBPS/book.html
OEBPS/nav.html
OEBPS/toc.ncx
OEBPS/images/cover.png

› 

Example B.2. The contents of the mimetype file

application/epub+zip

› 

Example B.3. The contents of the META-INF/container.xml file

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="OEBPS/As You Like It.opf"
            media-type="application/oebps-package+xml" />
    </rootfiles>
</container>

› 

Example B.4. The contents of the META-INF/signatures.xml file

<signatures xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <Signature Id="AsYouLikeItSignature" xmlns="http://www.w3.org/2000/09/xmldsig#">

        <!-- SignedInfo is the information that is actually signed. In this case -->
        <!-- the SHA1 algorithm is used to sign the canonical form of the XML    -->
        <!-- documents enumerated in the Object element below                    -->
        <SignedInfo>
            <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
            <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
            <Reference URI="#AsYouLikeIt">
                <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <DigestValue>…</DigestValue>
            </Reference>
        </SignedInfo>

        <!-- The signed value of the digest above using the DSA algorithm -->
        <SignatureValue>…</SignatureValue>

        <!-- The key to use to validate the signature -->
        <KeyInfo>
            <KeyValue>
                <DSAKeyValue>
                    <P>…</P>
                    <Q>…</Q>
                    <G>…</G>
                    <Y>…</Y>
                </DSAKeyValue>
            </KeyValue>
        </KeyInfo>

        <!-- The list documents to sign. Note that the canonical form of XML   -->
        <!-- documents is signed while the binary form of the other documents -->
        <!-- is used -->
        <Object>
            <Manifest Id="AsYouLikeIt">
                <Reference URI="OEBPS/As You Like It.opf">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
                <Reference URI="OEBPS/book.html">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
                <Reference URI="OEBPS/images/cover.png">
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
            </Manifest>
        </Object>
    </Signature>
</signatures>

› 

Example B.5. The contents of the META-INF/encryption.xml file

<?xml version="1.0"?>
<encryption xmlns="urn:oasis:names:tc:opendocument:xmlns:container"
    xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

    <!-- The RSA encrypted AES-128 symmetric key used to encrypt the data -->
    <enc:EncryptedKey Id="EK">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <ds:KeyInfo>
            <ds:KeyName>John Smith</ds:KeyName>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherValue>xyzabc…</enc:CipherValue>
        </enc:CipherData>
    </enc:EncryptedKey>

    <!-- Each EncryptedData block identifies a single document that has been    -->
    <!-- encrypted using the AES-128 algorithm. The data remains stored in it’s -->
    <!-- encrypted form in the original file within the container.              -->
    <enc:EncryptedData Id="ED1">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
        <ds:KeyInfo>
            <ds:RetrievalMethod URI="#EK" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherReference URI="OEBPS/book.html"/>
        </enc:CipherData>
    </enc:EncryptedData>

    <enc:EncryptedData Id="ED2">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
        <ds:KeyInfo>
            <ds:RetrievalMethod URI="#EK" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherReference URI="OEBPS/images/cover.png"/>
        </enc:CipherData>
    </enc:EncryptedData>

</encryption>

› 

Example B.6. The contents of the OEBPS/As You Like It.opf file

<?xml version="1.0"?>
<package version="3.0"
         xml:lang="en"
         xmlns="http://www.idpf.org/2007/opf"
         unique-identifier="pub-id">

    <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
        <dc:identifier
              id="pub-id">urn:uuid:B9B412F2-CAAD-4A44-B91F-A375068478A0</dc:identifier>
        <meta refines="#pub-id"
              property="identifier-type"
              scheme="xsd:string">uuid</meta>

        <dc:language>en</dc:language>

        <dc:title>As You Like It</dc:title>

        <dc:creator id="creator">William Shakespeare</dc:creator>
        <meta refines="#creator"
              property="role"
              scheme="marc:relators">aut</meta>

        <meta property="dcterms:modified">2000-03-24T00:00:00Z</meta>

        <dc:publisher>Project Gutenberg</dc:publisher>

        <dc:date>2000-03-24</dc:date>

        <meta property="dcterms:dateCopyrighted">9999-01-01</meta>

        <dc:identifier
              id="isbn13">urn:isbn:9780741014559</dc:identifier>
        <meta refines="#isbn13"
              property="identifier-type"
              scheme="onix:codelist5">15</meta>

        <dc:identifier id="isbn10">0-7410-1455-6</dc:identifier>
        <meta refines="#isbn10"
              property="identifier-type"
              scheme="onix:codelist5">2</meta>

        <link rel="xml-signature"
              href="../META-INF/signatures.xml#AsYouLikeItSignature"/>
    </metadata>

    <manifest>
        <item id="r4915"
              href="book.html"
              media-type="application/xhtml+xml"/>
        <item id="r7184"
              href="images/cover.png"
              media-type="image/png"/>
        <item id="nav"
              href="nav.html"
              media-type="application/xhtml+xml"
              properties="nav"/>
        <item id="ncx"
              href="toc.ncx"
              media-type="application/x-dtbncx+xml"/>
    </manifest>

    <spine toc="ncx">
        <itemref idref="r4915"/>
    </spine>
</package>

› Appendix C. The application/epub+zip Media Type

This appendix registers the media type application/epub+zip for the EPUB Open Container Format (OCF).

An OCF file is a container technology based on the ZIP archive format. It is used to encapsulate EPUB Publications and optional alternate renditions thereof. OCF and its related standards are maintained and defined by the International Digital Publishing Forum (IDPF).

MIME media type name:

application

MIME subtype name:

epub+zip

Required parameters:

None.

Optional parameters:

None.

Encoding considerations:

OCF files are binary files in ZIP (http://www.iana.org/assignments/media-types/application/zip) format.

Security considerations:

All processors that read OCF files should rigorously check the size and validity of data retrieved.

In addition, because of the various content types that can be embedded in OCF files, it is possible that application/epub+zip may describe content that has security implications beyond those described here. However, only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document.

Security considerations that apply to application/zip also apply to OCF files.

Interoperability considerations:

None.

Published specification:

This media type registration is for the EPUB Open Container Format (OCF), as described by the EPUB Open Container Format (OCF) 3.0 specification located at http://www.idpf.org/epub/30/spec/epub30-ocf.html.

The EPUB OCF 3.0 specification supersedes the Open Container Format 2.0.1 specification, which is located at http://www.idpf.org/doc_library/epub/OCF_2.0.1_draft.doc and which also uses the application/epub+zip media type.

Applications which use this media type:

This media type is in wide use for the distribution of ebooks in the EPUB format. The following list of applications is not exhaustive.

Adobe Digital Editions

Aldiko

Azardi

Apple iBooks

Barnes & Noble Nook

Calibre

Google Books

Ibis Reader

MobiPocket reader

Sony Reader

Stanza

Additional information:

Magic number(s):

0: PK 0x03 0x04, 30: mimetype, 38: application/epub+zip

File extension(s):

OCF files are most often identified with the extension .epub.

Macintosh File Type Code(s):

ZIP

Fragment Identifiers:

The IDPF maintains a registry of linking schemes at http://idpf.org/epub/linking/. Some of these schemes define custom fragment identifiers that resolve to application/epub+zip and application/oebps-package+xml documents.

Person & email address to contact for further information:

William McCoy, bmccoy@idpf.org

Intended usage:

COMMON

Author/Change controller:

International Digital Publishing Forum (http://www.idpf.org)

Acknowledgements and Contributors

This appendix is informative

› B.1 EPUB 3.0

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:

Gylling, Markus (DAISY Consortium) Chair

Conboy, Garth (Google Inc.) Vice-chair

Duga, Brady (Google Inc.) Vice-chair, Subgroup Lead

McCoy, Bill (International Digital Publishing Forum (IDPF)) Secretary

Kasdorf, Bill (Apex CoVantage) Subgroup Lead

MURATA, Makoto (JEPA EPUB Study Group) Subgroup Lead

Sorotokin, Peter (Adobe) Subgroup Lead

Active members of the working group at the time of publication of revision 3.0 were:

IDPF Members

Abrams, Willie (Ingram Digital)

Acton, Daniel (Google)

Allesi, Ana Maria (HarperCollins)

Amos, Dan (DNAML (DNL eBooks))

Arany, Steve (John Wiley & Sons)

Artin, Michael (Barnes & Noble)

Badger, Brandon (Google)

Ballard, Kevin (Apple Inc.)

Beard, Elliot (HarperCollins)

Belfanti, Paul (Pearson)

Bell, Graham (EDItEUR)

Bide, Mark (EDItEUR)

Bogaty, Nick (Adobe)

Bowers, Micah (Bluefire Productions)

Brantley, Peter (Internet Archive)

Breglio, Melissa (Apple Inc.)

Broome, Karen (Sony)

Brugge, John (Benetech)

Carbonell, Oliver (Sony)

Chang, Phobos (Chinese Foundation for Digitization Technology)

Chen, Mei-Li (Institute for Information Industry)

Chen, Peter (ITRI)

Choi, Soo (HarperCollins)

Chow, King-Wai (ASTRI (Hong Kong Applied Science & Technology Research Institute))

Clutter, Mat (Random House)

Conboy, Garth (Google)

Cramer, Dave (Hachette Book Group)

Cronin, Margot (Bowker)

Daly, Liza (Threepress)

De Meulemeester, Eric (Jouve/Publishing Dimensions)

DeMeglio, Marisa (DAISY Consortium)

Deltour, Romain (DAISY Consortium)

Dougherty, Casey (Apple Inc.)

Drake, Jama (Impelsys)

Duga, Brady (Google)

Elliott, Ray (Crossway)

Fahlgren, Keith (Threepress)

Fain, Guy (Crossway)

Freese, Eric (Aptara)

Gardeur, Hadrien (Feedbooks)

Gold, Eric (Digital Divide Data)

Goodwin, Jonathan (Appfoundry)

Gopinath, Anith (Impelsys)

Gosling, Andreas (Penguin)

Grazioli, Frank (John Wiley & Sons)

Gunn, Dave (RNIB)

Gylling, Markus (DAISY Consortium)

Haas, Matt (Pearson)

Hadfield, Tom (CourseSmart)

Hagino, Masaaki (Voyager Japan)

Hawkins, Kevin (University of Michigan Library)

Hayashi, Junichi (Voyager Japan)

Heiberger, Richard (HarperCollins)

Hepp, Mike (Dartmouth Journal Services)

Herren, Matthew (BlankPage)

Hisashi, Saiga (Sharp)

Hoda, Hisashi (Voyager Japan)

Howard, William (Easypress)

Hughes, Dan (Liguori Publications)

Hulse, Leslie (HarperCollins)

Imsieke, Gerrit (le-tex)

Jain, Anupam (Innodata Isogen)

Jie, Fan (Gansu DUZHE Digital Sci&Tech)

Johnson, Rick (Ingram Digital)

Jung, Kanghee (Incube Technologies)

Kakar, Samir (Aptara)

Kanai, Takeshi (Sony)

Kasdorf, Bill (Apex CoVantage)

Kasher, Bob (BookMasters and Newgen Imaging)

Kato, Kazuyuki (East Co.)

Keating, Patrick (Bluefire Productions)

Kerscher, George (DAISY Consortium)

Kida, Yasuo (Apple Inc.)

Kim, Jean (Barnes & Noble)

Kim, HyunYoung (Incube Technologies)

Kim, Terry (INKA Entworks)

Kitagawa, Masahiro (Impress Holdings)

Koike, Toshiaki (Voyager Japan)

Kok, Dan (Crossway)

Kotrch, Steve (Simon & Schuster)

Larroque, Benoit (Feedbooks)

Levantovsky, Vladimir (Monotype Imaging)

Lu, Cho-Chin (Institute for Information Industry)

Lynch, Ryan (Apple Inc.)

MacFarlane, James (Easypress)

Makower, Dave (Apple Inc.)

Mandelbaum, David (Barnes & Noble)

Manis, Will (Metaplates)

McCloy-Kelley, Liisa (Random House)

McCoy, Bill (IDPF)

Menzies, Tracey (HarperCollins)

Mitchell, Chris (Random House)

Moore, Helen (HarperCollins)

Muller, Eric (Adobe)

Murata, Makoto (JEPA EPUB Study Group)

Mussinelli, Christina (Associazione Italiana Editori)

Nagai, Yoshinori (Sharp)

Novelli, Joe (Sony)

O'Connor, Edward (Apple Inc.)

Ohmura, Yoshinori (Impress Holdings)

Olenick, Michael (Bowker)

Oshiyama, Taka (East Co.)

Pagano, Pat (Barnes & Noble)

Picco, Marty (AppFoundry)

Prabhu, John (HOV Services)

Pritchett, James (Learning Ally (formerly RFB&D))

Rao, Vishnu (Sharp Laboratories)

Rivlin, John (Google)

Rubino, Frank (Kaplan Publishing)

Ruffino, Daniel (Penguin)

Rui Hua, Wang (Gansu DUZHE Digital Sci&Tech)

Ruse, Tyler (LibreDigital)

Sanicola, Daniel (Penguin)

Schirmer, Lorenz (Monotype Imaging)

Shiohama, Daihei (Voyager Japan)

Shrivastava, Abhishek (CourseSmart)

Slavin, Wayne (Barnes & Noble)

Slye, Christopher (Adobe)

Smith, Michael (IDPF)

Soiffer, Neil (Design Science)

Sorotokin, Peter (Adobe)

Stevenson, Tobias (eBookArchitects)

Tahara, Kyoji (Toppan Printing)

Takase, Hiroshi (East Co.)

Tallent, Joshua (eBookArchitects)

Tanabe, Shu (Toppan Printing)

Thomas, Vinu (Impelsys)

Tsumagari, Koichiro (Voyager Japan)

Valentine, Chelsea (LibreDigital)

Vangage, Peter (Harlequin)

Vido, Ariel (Geografica Editora)

Wait, John (Pearson)

Walkley, George (Hachette Book Group)

Watters, Kevin (Harlequin)

Webster, Roger (Barnes & Noble)

Weck, Daniel (DAISY Consortium)

Wei, Selena (Chinese Foundation for Digitization Technology)

White, Russell (Random House)

Wiles, Alexis (Overdrive, Inc.)

Witwer, Adam (O'Reilly)

Wright, Rick (Adobe)

Young, Liz (Crossway)

Zu, Alex (ASTRI (Hong Kong Applied Science & Technology Research Institute))

Invited Experts/Observers

Bowes, Rick

Cazenove, Rhys

Collingridge, Peter

Cook, Mike

Etemad, Elika J. W3C CSS WG Liason

Forster, Karen

Freed, Geoff

Fujisawa, Jun

Garrish, Matt

Gould, Bryan

Görner, Martin

Hsieh, Michael

Ishii, Koji

Johar, Kenny

Karlsson, Mattias

Kennedy, Dianne

Kilborn, Peter

Koppel, Josh

Lee, Tommy

Lu, Kenny

Lubeck, Scott

Masanori, Kusunoki

McKinney, Steven

Murakami, Shinyu

Ning, Elliott

Noring, Jon

Norton, Paul

Oishi, Yasuharu

Passey, Lee

Rosmaita, Gregory

Seaman, David

Sevardia, Ron

Shan, Walter

Smith(tm), Michael (W3C) W3C Liason

Sperberg, Roger

Walsh, Norman

Zergaoui, Mohamed

› B.2 EPUB 2.0.1

Version 2.0.1 of this specification was prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group under the leadership of:

Conboy, Garth (eBook Technologies) Working Group Vice-chair

Kerscher, George (DAISY Consortium) Working Group Chair

Active members of the working group at the time of publication of revision 2.0.1 were:

Wiles, Alexis (OverDrive)

Wise, Alicia (Publishers Licensing Society)

Moghaddami, Amir (National Library and Archives of Iran)

Gosling, Andreas (Penguin UK)

Williams, Andy (Cambridge University Press)

Jain, Anupam (Innodata Isogen)

Trafford, Ben (Invited Expert)

Larroque, Benoit (Feedbooks)

McCoy, Bill (Invited Expert)

Kasdorf, Bill (Apex CoVantage)

Kasher, Bob (The BookMasters Group)

Duga, Brady (eBook Technologies)

Laws, Byron (PreMedia Global)

Zekri, Catherine (University of Montreal)

Kennedy, Chris (Pearson Education)

Podolsky, Corey (Entourage Systems Inc.)

Mussinelli, Cristina (AIE)

Daihei, Shiohama (Voyager Japan)

Amos, Dan (DNAML)

Galperin, Dan (Kobo)

Kok, Dan (Crossway Books and Bibles)

Cramer, Dave (Hachette Book Group USA)

Gunn, Dave (RNIB Centre for Accessible Information)

Mandelbaum, David (Barnes&Noble.com)

Roberts, Deidra (World Health Organization)

Goyette, Donald (McGraw-Hill Professional)

Freese, Eric (Aptara)

Gold, Eric (Digital Divide Data)

Muller, Eric (Adobe)

Shepherd, Gregory (Cengage Learning)

Fain, Guy (Crossway Books & Bibles)

Gardeur, Hadrien (Feedbooks)

Hoda, Hisashi (Voyager Japan)

Fernández Galván, Ignacio

Viente, Israel (Mendele He-Books)

Link, Jim (Macmillan Publishing Solutions)

MacFarlane, James (Easypress Technologies)

Rura, Jim (Educational Testing Service)

Crossman, John (Benetech)

Prabhu, John (HOV Services)

Rivlin, John (eBook Technologies)

Wait, John (Pearson Education)

Noring, Jon (Invited Expert)

Tallent, Joshua (eBook Architects)

Broome, Karen (Sony)

Fahlgren, Keith (Threepress Consulting)

Johar, Kenny (Vision Australia)

Casey, Laurie (Pearson)

Rzedzicki, Lech (Pearson UK)

McCloy-Kelley, Liisa (Random House)

Humphreys, Lindy (Wiley/ Blackwell Books)

Daly, Liza (Theepress Consulting)

Murata, Makoto (JEPA EPUB Study Group)

Croella, Marco (Simplicissimus Book Farm)

Gylling, Markus (DAISY Consortium)

Karlsson, Mattias (Dolphin Computer Access AB)

Smith, Michael (IDPF)

Soiffer, Neil (Design Science)

Genner, Noah (BookNet Canada)

Pagano, Pat (HarperCollins)

Payton, Patricia (Bowker)

Barry, Patrick (The Educational Company of Ireland)

Berube, Patrick (LEARN)

Durrant, Paul (Durrant Software Limited)

Norton, Paul (Invited Expert)

Reid, Penelope (EPUB User Group (UK))

Huang, Perce (Far EasTone Telecommunications)

Brantley, Peter (Internet Archive)

Sorotokin, Peter (Adobe)

Heiberger, Richard (HarperCollins Publishers)

Kwan, Richard (Invited Expert)

White, Russell (Random House)

Kakar, Samir (Aptara)

Pamarty, Satya (codeMantra)

Cook, Scott (codeMantra)

Ramsey, Sean (LibreDigital)

Padgett, Siobahn (Hachette BG USA)

Arany, Steve (John Wiley & Sons)

Kanai, Takeshi (Sony)

Swiderski, Thad (LibreDigital)

Middleton, Tim (BookNet Canada)

Conti, Trudy (Follett)

Ruse, Tyler (LibreDigital)

Howard, William (EasyPress Technologies)

› B.3 EPUB 1.0

Version 1.0 of this specification was prepared by the International Digital Publishing Forum’s Unified OEBPS Container Format Working Group under the leadership of:

Conboy, Garth (eBook Technologies) Working Group Co-Chair

Rivlin, John (eBook Technologies) Working Group Co-Chair

Ferraiolo, Jon (IBM) Working Group Vice-Chair

Bogaty, Nick (IDPF) Working Group Secretary

Active members of the working group at the time of publication of revision 1.0 were:

Allen, Kelley L. (Random House)

Ancin, Angel (iRex Technologies)

Bandy, Ryan (Random House)

Bellaver, Richard (Ball State University)

Brethes, Thierry (Mobipocket)

Carter, Janice (Benetech/Bookshare.org)

Cohn, Richard (Adobe Systems Inc.)

De Young, Neil (Hachette Book Group USA)

Do, Linh N. (Random House, Inc.)

Freed, Geoff (WGBH)

Gang, Liang (TriWorks Asia)

Ghali, Peter (Motricity, ereader.com)

Hakkinen, Markku T. (DAISY Consortium)

Harrison, Gillian (NetLibrary)

Hevenstone, Jonathan (Publishing Dimensions)

Horner, Theresa (HarperCollins)

Iannone, Karen (Houghton Mifflin)

Israel, Claire (Simon & Schuster)

Karlsson, Mattias (Dolphin Computer Access)

Kasdorf, Bill (Apex Publishing)

Kerscher, George (DAISY Consortium)

Kotrch, Steve (Simon & Schuster)

McCoy, Bill (Adobe Systems, Inc.)

McKenna, Bill (Follett)

Melton, Bonnie (Houghton Mifflin College Division)

Noring, Jon (OpenReader Consortium)

Osayande, Sayu (Motricity, ereader.com)

Passey, Lee

Potash, Steve (OverDrive)

Ruse, Tyler (Codemantra)

Smith, Mike (Harlequin)

Sugeno, Kimi (John Wiley & Sons)

Varnell, Gary (Osoft.com)

Wang, Xin (ContentGuard, Inc.)

Weinstein, Andrew (Lightning Source)

Whitcomb, Tom (NetLibrary)

Williams, Andy (Cambridge University Press)

Willner, Eli (Green Point Technology Services)

References

Normative References

[AAC LC] ISO/IEC 14496-3:2009 - Information technology -- Coding of audio-visual objects -- Part 3: Audio .

[WAI-ARIA] Accessible Rich Internet Applications (WAI-ARIA) 1.0 . James Craig, et al.

[AltStyleTags] Alternate Style Tags . Elika J. Etemad.

[CSS2.0] Cascading Style Sheets, level 2 - CSS2 Specification . Bert Bos, et al. 12 May 1998 (revised 11 April 2008).

[CSS2.1] Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification . Bert Bos, et al. 7 June 2011.

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

[CSS3Fonts-20110324] CSS Fonts Module Level 3 (20110324) . John Daggett. 24 March 2011.

[CSSMultiCol] CSS Multi-column Layout Module . Håkon Wium Lie.

[CSS3Ruby] CSS3 Ruby Annotation Module .

[CSS3Speech] CSS3 Speech Module . Dave Raggett, et al.

[CSS3Speech-20110818] CSS3 Speech Module (20110818) . Dave Raggett, et al. 19 April 2011.

[CSS3Text] CSS Text Level 3 . Elika J. Etemad, et al.

[CSS3Text-20110412] CSS Text Level 3 (20110412) . Elika J. Etemad, et al. 12 April 2011.

[CSS3WritingModes] CSS Writing Modes Module Level 3 . Elika J. Etemad, et al.

[CSS3WritingModes-20110428] CSS Writing Modes Module Level 3 (20110428) . Elika J. Etemad, et al. 28 April 2011.

[CSS Namespaces] CSS Namespaces Module . Elika J. Etemad, et al.

[ContentDocs30] EPUB Content Documents 3.0 .

[DCMES] Dublin Core Metadata Element Set, Version 1.1 .

[DCTERMS] DCMI Metadata Terms .

[EPUBCFI] EPUB Canonical Fragment Identifier (epubcfi) Specification .

[StructureVocab] EPUB 3 Structural Semantics Vocabulary .

[XML Events] XML Events . Shane McCarron, et al. 14 October 2003.

[GIF] GRAPHICS INTERCHANGE FORMAT(sm) Version 89a .

[HTML5] HTML5: A vocabulary and associated APIs for HTML and XHTML .

[ISOSchematron] ISO/IEC 19757-3: Rule-based validation — Schematron .

[JPEG] JPEG Standard (JPEG ISO/IEC 10918-1 ITU-T Recommendation T.81) .

[MARC21XML] MARC 21 XML Schema .

[MODS] Metadata Object Description Schema (MODS) .

[MP3] ISO/IEC 11172-3:1993 - Information technology -- Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s -- Part 3: Audio .

[MP4] Information technology -- Coding of audio-visual objects -- Part 14: MP4 file format .

[MATHML] Mathematical Markup Language (MathML) Version 3.0 . David Carlisle, et al. 21 October 2010.

[MediaQueries] Media Queries .

[NVDL] ISO/IEC 19757-4: NVDL (Namespace-based Validation Dispatching Language) .

[OCF2] Open Container Format 2.0.1 .

[OCF3] Open Container Format 3.0 .

[ONIX] ONIX for Books .

[OPF2] Open Packaging Format 2.0.1 .

[OPS2] Open Publication Structure 2.0.1 .

[OpenType] ISO/IEC 14496-22:2009 - Information technology -- Coding of audio-visual objects -- Part 22: Open Font Format .

[MediaOverlays30] EPUB Media Overlays 3.0 .

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

[PNG] Portable Network Graphics (PNG) Specification (Second Edition) . David Duce. 10 November 2003.

[Publications30] EPUB Publications 3.0 .

[RDFa10] RDFa in XHTML: Syntax and Processing . A collection of attributes and processing rules for extending XHTML to support RDF. Ben Adida, et al. 14 October 2008.

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

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.

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

[RFC4839] Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF) (RFC 4839) . G Conboy, et al. April 2007.

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

[RelaxNG] ISO/IEC 19757-2: Regular-grammar-based validation — RELAX NG. Second Edition . 2008-12-15.

[SHA-1] Federal Information Processing Standards Publication 180-3: Secure Hash Standard (SHS) . October 2008.

[SMIL] SMIL Version 3.0 . D. Bulterman, et al. 01 December 2008.

[SSML] Speech Synthesis Markup Language (SSML) Version 1.1 . Daniel C. Burnett, et al. 7 September 2010.

[SVG] Scalable Vector Graphics (SVG) 1.1 (Second Edition) . Erik Dahlström, et al. 09 June 2011.

[SVG Access] Accessibility Features of SVG . Charles McCathieNevile, et al. 7 August 2000.

[TR15] Unicode Normalization Forms . Mark Davis, et al. 17 September 2010.

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

[WCAG20] Web Content Accessibility Guidelines (WCAG) 2.0 . Ben Caldwel, et al. 11 December 2008.

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

[XML ENC Core] XML Encryption Syntax and Processing Version 1.1 . D. Eastlake, et al. 3 March 2011.

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

[XML SIG Decrypt] Decryption Transform for XML Signature . M. Hughes, et al. 10 December 2002.

[XML Sec RNG Schemas] XML Security RELAX NG Schemas .

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

[XMP] Extensible Metadata Platform .

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

[ZIP APPNOTE] ZIP File Format Specification . September 28, 2007. PKWARE, Inc..

Informative References

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

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

[H.264] H.264 : Advanced video coding for generic audiovisual services .

[ODF] ODF Open Document Format .

[Role] Role Attribute . An attribute to support the role classification of elements. McCarron, et al. 05 August 2010.

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

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

[XPTRSH] XPointer Shorthand Notation .

[Z3986-2005] ANSI/NISO Z39.86-2005: Specifications for the Digital Talking Book . M. Moodie, et al. 2005.

EPUB 3 Changes from EPUB 2.0.1

Recommended Specification 11 October 2011

This version

http://www.idpf.org/epub/30/spec/epub30-changes-20111011.html

Latest version

http://www.idpf.org/epub/30/spec/epub30-changes.html

Previous version

http://www.idpf.org/epub/30/spec/epub30-changes-20110908.html

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

Copyright © 2010, 2011 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Editors

William McCoy, International Digital Publishing Forum (IDPF)

Markus Gylling, DAISY Consortium

Table of Contents

1. Introduction

1.1. EPUB Revision History

2. Changes to EPUB Specification Documents

2.1. Changes in Document Organization

2.2. Changes in Terminology

3. New and Changed Functionality in EPUB 3

3.1. Content Documents

3.1.1. HTML5

3.1.2. SVG

3.1.3. MathML

3.1.4. Semantic Inflection

3.1.5. Content Switching

3.2. Navigation

3.3. Linking

3.4. Scripting and Interactivity

3.4.1. Scripting

3.4.2. Triggers

3.4.3. Bindings

3.5. Styling and Layout

3.5.1. CSS

3.5.2. Embedded Fonts

3.5.3. Font Obfuscation

3.6. Rich Media

3.6.1. Audio and Video

3.6.2. Media Overlays

3.7. Metadata

3.7.1. Publication Metadata and Identity

3.7.2. Resource Metadata

3.8. Speech

3.9. Manifest Fallbacks

3.10. Containment

3.10.1. Remote Resources

3.10.2. Whitespace in MIMETYPE file

3.10.3. Disallowed characters in OCF file names

3.11. XML and Unicode

4. EPUB 2.0.1 Features Replaced in EPUB 3

4.1. Features Removed from EPUB 3

4.1.1. DTBook

4.1.2. Out-of-Line XML Islands

4.1.3. Tours

4.1.4. Filesystem Container

4.2. Features Deprecated/Obsoleted in EPUB 3

4.2.1. Guide

4.2.2. NCX

4.2.3. 2.0.1 meta element

› 1 Introduction

EPUB® is an interchange and delivery format for digital publications, based on XML and Web Standards. An EPUB Publication can be thought of as a reliable packaging of Web content that represents a digital book, magazine, or other type of publication, and able to distributed for online and offline consumption.

This document, EPUB 3 Changes from EPUB 2.0.1, describes changes made in the third major revision of EPUB, including some rationale for the changes, and some guidance for content authors and Reading System developers regarding backwards compatibility considerations.

This document is non-normative. The EPUB specification documents should be consulted for definitive information on EPUB 3:

EPUB Publications 3.0 [Publications30], which defines publication-level semantics and overarching conformance requirements for EPUB Publications.

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

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

Unless otherwise specified, terms used herein have the meaning defined in these specifications.

› 1.1 EPUB Revision History

EPUB had its roots in the interchange format known as the Open EBook Publication Structure (OEBPS). OEBPS 1.0 was approved in 1999 by the Open eBook Forum, an organization that later became the International Digital Publishing Forum (IDPF). Subsequent revisions 1.1 and 1.2 were approved by the IDPF in 2001 and 2002 respectively.

It was realized that a need existed for a format standard that could be used for delivery as well as interchange, and work began in late 2005 on a single-file container format for OEPBS, which was approved by the IDPF as the OEBPS Container Format (OCF) in 2006. Work on a 2.0 revision of OEBPS began in parallel which was approved as the renamed EPUB 2.0 in October, 2007, consisting of a triumvirate of specifications: Open Package Format (OPF), Open Publication Format (OPF) together with OCF. EPUB 2.0.1, a maintenance update to the 2.0 specification set primarily intended clarify and correct errata in the specifications, was approved in September, 2010. [OPF2] [OPS2] [OCF2]

› 2 Changes to EPUB Specification Documents

In addition to significant changes in functionality, the EPUB 3 specifications are structured and named differently than EPUB 2.0.1, and certain terminology changes have been made to improve clarity. The following sections describe these changes.

› 2.1 Changes in Document Organization

In order to help those familiar with EPUB 2.0.1 to understand the mapping of information in EPUB 3, the following table shows where information in EPUB 3 is located relative to the EPUB 2.0.1 specifications.

› 

Specification Document Organization

Area | EPUB 3 Specification | EPUB 2.0.1 Specification
Overview | EPUB 3 Overview | (throughout)
Publication-level Specification & Package Docs | EPUB Publications 3.0 | Open Packaging Format 2.0.1
Content-level Specification | EPUB Content Documents 3.0 | Open Publication Structure 2.0.1
EPUB Navigation Documents | EPUB Content Documents 3.0 | N/A (NCX referenced as DAISY specification)
Media Overlays | EPUB Media Overlays 3.0 | N/A
Container packaging | EPUB Open Container Format 3.0 | Open Container Format 2.0.1
Changes from previous version | EPUB 3 Changes from EPUB 2.0.1 | (throughout)

› 2.2 Changes in Terminology

Maintaining consistent use of terminology from EPUB 2.0.1 to EPUB 3 was a consideration during development, but changes in document organization, feature set and conformance requirements inevitably resulted in a number of changes.

Each specification contains a Terminology section near the top that defines and explains the new terms (e.g., Terminology [Publications30]).

› 3 New and Changed Functionality in EPUB 3

This section describes the major new and changed functionality and constructs present in EPUB 3.

› 3.1 Content Documents

› 3.1.1 HTML5

EPUB 3's base content format is now based on the XML serialization of HTML5 (XHTML5) [ContentDocs30], whereas EPUB2 supported two basic content types: a profile of XHTML 1.1 and DTBook [OPS2] (a semantically-enhanced markup focused on accessibility concerns).

The EPUB 3 XHTML Content Document definition includes both extensions to and restrictions on its HTML5 base, many of which are discussed below. Refer to HTML5 Extensions and Enhancements [ContentDocs30] and HTML5 Deviations and Constraints [ContentDocs30] for complete information.

› 3.1.2 SVG

SVG documents can now appear in the spine in EPUB 3 (i.e., SVG no longer needs to be nested within an XHTML document).

› 3.1.3 MathML

Support for MathML [ContentDocs30] is new in EPUB 3.

› 3.1.4 Semantic Inflection

A method for inflecting domain-specific semantics in XHTML Content Documents using attributes has been added. Refer to Semantic Inflection [ContentDocs30] for more information.

› 3.1.5 Content Switching

The switch element, initially introduced in [OPS2], has been simplified by having its processing model defined so that it does not require document preprocessing, and by removing the requiredModules attribute. This simplification is backwards compatible with existing EPUB 2 Reading System implementations. Refer to Content Switching [ContentDocs30] for more information.

› 3.2 Navigation

EPUB 3 defines a new human- and machine-readable grammar for publication-wide navigation information via a specialized adaptation of the general EPUB XHTML Content Document. EPUB Navigation Documents [ContentDocs30] supersedes the NCX grammar used in EPUB 2.

While NCX support was optional for EPUB2 Reading Systems, inclusion of and support for EPUB Navigation Documents is required in EPUB 3.

As noted in NCX Superseded [Publications30], EPUB 3 Publications may include the EPUB 2 NCX for EPUB 2 Reading System forward compatibility purposes.

› 3.3 Linking

The IDPF has established a registry of linking schemes.

[EPUBCFI] is the first scheme added to the registry, and can be used for linking into, between and within Publications. Reading System support for this scheme is required.

› 3.4 Scripting and Interactivity

› 3.4.1 Scripting

EPUB 3 Reading Systems may optionally support scripting, which was explicitly discouraged in EPUB 2. Scripted content must be identified as such in the package manifest [Publications30] and is subject to other restrictions and limitations as further described in Scripted Content Documents [ContentDocs30].

The new custom epubReadingSystem JavaScript object [ContentDocs30], provides scripts a means of querying a Reading System to determine its capabilities.

› 3.4.2 Triggers

To facilitate content-specific user experiences for audio and video controls without requiring scripting, a new trigger element is defined in the EPUB profile of HTML5 [ContentDocs30] that allows declarative binding of activation events from image or textual elements to properties of audio and video players (e.g., play, stop, pause).

› 3.4.3 Bindings

The new bindings [Publications30] element provides a means to define script-based handlers for non-standard media types.

› 3.5 Styling and Layout

› 3.5.1 CSS

EPUB 3 defines a profile of CSS based on CSS 2.1 with added modules from CSS3, whereas EPUB 2 was based on a specific subset of CSS 2. Refer to EPUB Style Sheets [ContentDocs30] for more information.

Support for Alternate Style Tags [ContentDocs30] has been added, allowing Users to switch between predefined alternate viewing modes, such as day/night and horizontal/vertical modes.

› 3.5.2 Embedded Fonts

EPUB 3 requires Reading Systems to support the OpenType and WOFF font formats for embedded fonts in conjunction with the CSS @font-face rules. Refer to CSS Fonts Level 3 [ContentDocs30] for more information.

› 3.5.3 Font Obfuscation

A new normative section on Font Obfuscation [OCF3] has been added the Open Container Format specification. This issue was previously outlined in an IPDF informational document.

› 3.6 Rich Media

› 3.6.1 Audio and Video

EPUB 3 inherits support for the HTML5 audio and video elements.

EPUB 3 further specifies in its definition of support for Core Media Types [Publications30] that all Reading Systems that support audio playback must support MP3 audio and should support MP4 AAC LC audio. While no video Core Media Types are defined in this version of EPUB, an informative recommendation on codec support is provided as guidance to publishers and Reading System developers.

› 3.6.2 Media Overlays

The EPUB Media Overlays 3.0 [MediaOverlays30] specification defines a format and a processing model for publication-wide synchronization of text and audio.

› 3.7 Metadata

› 3.7.1 Publication Metadata and Identity

The minimally required Package metadata as defined in EPUB 2.0.1 remains fundamentally unchanged. Only one new required metadata property, dcterms:modified, has been added. This new property contributes to the new solution to persistence in Publication Identifiers, as further discussed in Publication Identifiers [Publications30].

The generic Package Document meta element has been enhanced [Publications30] with a declarative term vocabulary association mechanism, as well as the ability to describe not only the Publication as a whole, but also individual resources and/or fragments within it. A set of EPUB-specific metadata properties has been added, allowing for example the identification of the Publication cover image, and sorting of related titles in the bookshelf.

A new metadata link [Publications30] element has been added to the Package Document, allowing the association of external supplementary metadata resources with the publication (e.g., ONIX or XMP records).

› 3.7.2 Resource Metadata

The new properties attribute on the Package Document manifest item and spine itemref elements allows for the declaration of metadata about individual Publication Resources.

These declarations are required in EPUB 3 in certain defined circumstances (e.g., for declaring that a Content Document contains scripting). Refer to Manifest item Properties [Publications30] and Spine itemref Properties [Publications30] for more information.

› 3.8 Speech

Multiple features to assist Text-to-Speech (TTS) engines have been added. These include Package-level Pronunciation Lexicons, SSML attributes in XHTML Content Documents, and support for the CSS3 Speech Module. [ContentDocs30]

› 3.9 Manifest Fallbacks

The manifest fallback mechanism has been restricted to only apply to documents in the spine. Publication Resources referenced from XHTML and SVG Content Documents and CSS must now be Core Media Types unless referenced in a context that provides native intrinsic fallback capabilities.

› 3.10 Containment

› 3.10.1 Remote Resources

There are new restrictions on references [Publications30] to remote resources (i.e., Publication Resources not located in the OCF Container). The implications of this change are more fully described in Removal of Filesystem Container.

› 3.10.2 Whitespace in MIMETYPE file

[OCF2] restricted the required MIMETYPE file from having any leading or trailing spaces; in [OCF3] the restriction against trailing whitespace has been removed.

› 3.10.3 Disallowed characters in OCF file names

The list of characters disallowed in OCF file names has been extended.

› 3.11 XML and Unicode

Support for XML 1.1, which was deprecated in OPS 2.0.1, has been removed. All XML documents must now be conformant to XML 1.0.

The referenced version of XML 1.0 is the fifth edition, which means that Unicode version 5.0.0 is now supported (OPS 2.0.1, via its use of XML 1.0 fourth edition, supported Unicode 2.0).

› 4 EPUB 2.0.1 Features Replaced in EPUB 3

A number of features in EPUB 3 and its building-block Web Standards replace existing features in EPUB 2.0.1, and several features in EPUB 2.0.1 that were not widely adopted by content authors or Reading Systems are discontinued. Such features, from a content conformance perspective, are either removed (which means that conformant EPUB 3 content might not use the construct) or deprecated (which means that use of the construct in EPUB 3 is allowed but not recommended). Note that, in most cases, Reading Systems are still required to support these constructs for backwards compatibility reasons (as normatively stated in the relevant specifications).

The following sections list the EPUB 2.0.1 features removed and deprecated in EPUB 3.

› 4.1 Features Removed from EPUB 3

› 4.1.1 DTBook

DAISY DTBook [Z3986-2005] was an alternative syntax to XHTML 1.1 for Content Documents in OPS 2.0.1 [OPS2] in order to provide an option for more semantic, and thus more accessible, content. As HTML5 includes intrinsic semantic markup capabilities of a similar nature to DTBook, DTBook is no longer an alternative syntax in EPUB 3.

› 4.1.2 Out-of-Line XML Islands

OPF 2.0.1. specified an optional extension mechanism enabling a spine item to be a "custom module" XHTML or arbitrary XML styled with CSS. This feature was not widely adopted by content or Reading Systems, and has been removed from EPUB 3. As a result the item element no longer has the required-namespace and fallback-style attributes.

› 4.1.3 Tours

The Package Document schema no longer includes the tours element (which was deprecated in OPF 2.0.1).

› 4.1.4 Filesystem Container

OCF 3.0 [OCF3] only defines a single-file (ZIP-based) container, and no longer defines a "Filesystem Container" abstraction. This change was made in conjunction with new restrictions in Publications 3.0 restricting references to remote resources in EPUB Publications to specific media types and contexts. Taken together, these changes mean that the only instantiation of an EPUB Publication defined at this time is the EPUB ZIP Container, and that EPUB files must in general contain all constituent parts of the Publication, with certain well-defined exceptions.

These changes may seem counter-intuitive given that online consumption of content is increasingly prevalent, as are browser-based Reading System implementations. The Working Group recognizes this, and understands that in an online environment, particularly when browser-based, it will often be inefficient or even impractical to download an entire EPUB file to a client system before reading can occur. A number of significant issues exist for browser-based Reading Systems, however, including cross-domain resource loading restrictions in the browser security model and the potential for inadvertent interaction between script-based interactivity within EPUB 3 content and script-based Reading System implementations. Publishers and content distributors providing EPUB content are presently utilizing server-based software to manage these issues, in effect creating a distributed client-server Reading System in which a packaged EPUB file is ingested on a server and may be transformed en route to client software into whatever set of resources is convenient for that implementation. Consequently, there was no pressing requirement to define an interoperable distributed form of an EPUB Publication in order to meet the requirements of the Working Group charter.

EPUB 2.x (via the OCF Filesystem container and by being relatively vague in the OPF specification about where absolute URLs were legal) can be considered to have incompletely described distributed publications without specifying conformance requirements for them. This was a combination of historical (with respect to OPF which was a revision to a predecessor specification that pre-dated any ZIP-based container) and aspirational (with respect to OCF) factors.

Since the Working Group did have a goal to improve the interoperability of the EPUB ecosystem by increasing the clarity and rigor of our conformance requirements, it was decided that these partial definitions were unhelpful and should be removed from the EPUB 3 base specifications. The Working Group understands that networked Publications will be increasingly important, and expects future work to include development of robust interoperable conformance definitions for distributed EPUB Publications based on emerging content publisher and Reading System requirements.

› 4.2 Features Deprecated/Obsoleted in EPUB 3

› 4.2.1 Guide

Use of the optional guide element in the Package Document has been deprecated in favor of the EPUB Navigation Document landmarks feature. Refer to EPUB Navigation Documents [ContentDocs30] for more information.

› 4.2.2 NCX

As described in more detail in Navigation above, the NCX has been superseded in favor of EPUB Navigation Documents [ContentDocs30].

› 4.2.3 2.0.1 meta element

The meta element as defined in [OPF2] has been superseded by the new Package Document meta element.