EPUB 3.3

W3C Working Draft

This version:
https://www.w3.org/TR/2021/WD-epub-33-20210406/
Latest published version:
https://www.w3.org/TR/epub-33/
Latest editor's draft:
https://w3c.github.io/epub-specs/epub33/core/
Previous version:
https://www.w3.org/TR/2021/WD-epub-33-20210224/
Editors:
Matt Garrish (DAISY Consortium)
Ivan Herman (W3C)
Dave Cramer
Former editors:
Garth Conboy (Google)
Dave Cramer (Hachette Livre)
Marisa DeMeglio (DAISY Consortium)
Daniel Weck (DAISY Consortium)
Participate:
GitHub w3c/epub-specs
File a bug
Commit history
Pull requests

Copyright © 1999-2021 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.

Abstract

EPUB® 3 defines a distribution and interchange format for digital publications and documents. The EPUB format provides a means of representing, packaging, and encoding structured and semantically enhanced Web content — including HTML, CSS, SVG, and other resources — for distribution in a single-file container.

This specification defines the authoring requirements for EPUB Publications and represents the third major revision of the standard.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the EPUB 3 Working Group as a Working Draft. This document is intended to become a W3C Recommendation.

GitHub Issues are preferred for discussion of this specification. Alternatively, you can send comments to our mailing list. Please send them to public-epub-wg@w3.org (subscribe, archives).

Publication as a Working Draft does not imply endorsement by the W3C Membership.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 15 September 2020 W3C Process Document.

1. Introduction

1.1 Overview

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

This specification represents the core of EPUB 3 and includes the conformance requirements for EPUB Publications — the product of the standard. The other specifications that comprise EPUB 3 are as follows:

These specifications represent the formal list recognized as belonging to EPUB 3 and that contain functionality normatively referenced as part of the standard. New functionality is also added periodically through the development of extension specifications. Features and functionality defined outside of core revisions to the standard, while not formally recognized in this specification, are nonetheless available for use by EPUB Creators and Reading System developers.

The informative EPUB 3 Overview [EPUB-OVERVIEW-33] provides a general introduction to EPUB 3. A list of technical changes from the previous version is also available in the change log.

1.2 Organization

This section is non-normative.

This section reviews the organization of the EPUB specifications through the central product they define: the EPUB Publication.

An EPUB Publication is typically represented by a single Package Document. This document includes metadata used by Reading Systems to present the content to the user, such as the title and author for display in a bookshelf as well as rendering metadata (e.g., whether the content is reflowable or has a fixed layout). It also provides a manifest of resources and includes a spine that lists the default sequence in which to render documents as a user progresses through the content. The requirements for the Package Document are defined in § 2.3 Package Document.

An EPUB Publication also includes another key file called the EPUB Navigation Document. This document provides critical navigation capabilities, such as the table of contents, that allow users to navigate the content quickly and easily. This document is defined in § 4. EPUB Navigation Document.

The actual content of an EPUB Publication — what users are presented with when they begin reading — is built on the Open Web Platform and comes in two flavors: XHTML and SVG. Called EPUB Content Documents, these documents typically reference many additional resources required for their proper rendering, such as images, audio and video clips, scripts, and style sheets.

Detailed information about the rules and requirements to produce EPUB Content Documents is provided in § 3. EPUB Content Documents, and accessibility requirements are defined in [EPUB-A11Y-11].

Media Overlay Documents complement EPUB Content Documents. They provide declarative markup for synchronizing the text in EPUB Content Documents with prerecorded audio. The result is the ability to create a read-aloud experience where text is highlighted as it is narrated. Media Overlay Documents are defined in § 7. Media Overlays.

The EPUB Publication's resources are bundled for distribution in a ZIP-based archive with the file extension .epub. As conformant ZIP archives, EPUB Publications can be unzipped by many software programs, simplifying both their production and consumption.

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 resources is the container.xml file, which directs Reading Systems to the available Package Documents. The container format is defined in § 6. Open Container Format.

While conceptually simple, an EPUB Publication is more than just a collection of HTML pages and dependent assets in a ZIP package as presented here. Additional information about the primary features and functionality that EPUB Publications provide to enhance the reading experience is available from the referenced specifications, and a more general introduction to the features of EPUB 3 is provided in the informative [EPUB-OVERVIEW-33].

The processing requirements for Reading Systems are defined in [EPUB-RS-33]. Although it is not necessary that EPUB Creators read that document to create EPUB Publications, an understanding of how Reading Systems present the content can help craft publications for optimal presentation to users.

1.3 Relationship to Other Specifications

This section is non-normative.

1.3.1 Relationship to HTML

The [HTML] standard is continuously evolving — there are no longer versioned releases of it. That standard, in turn, references various technologies that continue to evolve, such as MathML, SVG, CSS, and JavaScript.

The benefit of this approach for EPUB is that EPUB Publications always keep pace with changes to the Web without the need for new revisions. EPUB Creators, however, will need to keep track of the various changes to HTML and the technologies it references, and ensure that their processes are kept up to date.

Warning

As HTML evolves, it is possible that features that were valid in previous versions could become obsolete or be removed. In general, however, features are typically only removed if serious issues with them arise (e.g., lack of support in browsers, security issues).

The XHTML profile defined by this specification inherits all definitions of semantics, structure and processing behaviors from HTML unless otherwise specified.

In addition, this specification defines a set of extensions to the [HTML] document model that EPUB Creators can include in XHTML Content Documents.

1.3.2 Relationship to SVG

This specification does not reference a specific version of [SVG], but instead uses an undated reference. Whenever there is any ambiguity in this reference, the latest recommended specification is the authoritative reference.

This approach ensures that EPUB will always keep pace with changes to the SVG standard. EPUB Creators will need to keep track of changes to the SVG standard and ensure that their processes are kept up to date.

As SVG evolves, it is possible that features that were valid in previous versions could become obsolete or be removed. It is anticipated that the W3C will make any such changes carefully to ensure minimal disruption for EPUB Creators, but in the case of a backwards-incompatible revision the use of an undated reference could be revisited.

1.3.3 Relationship to CSS

EPUB 3 supports CSS as defined by the CSS Working Group Snapshot [CSSSnapshot]. EPUB 3 also maintains some prefixed CSS properties, to ensure consistent support for global languages.

1.3.4 Relationship to SMIL

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

1.4 Terminology

The following terms are specific to EPUB 3. They are capitalized wherever used.

Only the first instance of a term in a section is linked to its definition.

Codec

Codec refers to content that has intrinsic binary format qualities, such as video and audio media types which are already designed for optimum compression, or which provide optimized streaming capabilities.

Content Display Area

The area within the Viewport dedicated to the display of EPUB Content Documents. The Content Display Area excludes any borders, margins, headers, footers, or other decoration a EPUB Reading System might inject into the Viewport.

In the case of synthetic spreads, the Viewport contains two Content Display Areas.

Core Media Type Resource

A Publication Resource that does not require the provision of a fallback (cf. Foreign Resource).

EPUB Container
OCF ZIP Container

The ZIP-based packaging and distribution format for EPUB Publications defined in § 6.2 OCF ZIP Container.

EPUB Container and OCF ZIP Container are synonymous.

EPUB Content Document

A Publication Resource with an XHTML or SVG media type that contains all or part of the content of an EPUB Publication (i.e., the textual, visual and/or audio content). These resources have to conform to their respective XHTML or SVG definitions to be used in the spine or be referenced from another EPUB Content Document.

An EPUB Content Document is a Core Media Type Resource, so can be included without the provision of fallbacks.

EPUB Creator

The person(s) or organization responsible for the creation of an EPUB Publication.

Depending on how EPUB Publications are produced, EPUB Creator may sometimes refer to responsibilities of the organization (e.g., the publisher) or the individuals preparing the publication (e.g., technical editors).

Note

Previous versions of this specification referred to the EPUB Creator as the Author.

EPUB Navigation Document

A specialization of the XHTML Content Document that contains human- and machine-readable global navigation information. The EPUB Navigation Document conforms to the constraints expressed in § 4. EPUB Navigation Document.

EPUB Publication

A logical document entity consisting of a set of interrelated resources packaged in an EPUB Container.

An EPUB Publication typically represents a single intellectual or artistic work, but this specification does not restrict the nature of the content.

EPUB Reading System (or Reading System)

A system that processes EPUB Publications for presentation to a user in a manner conformant with this specification.

File Name

The name of any type of file within an OCF Abstract Container, whether a directory or a file within a directory.

Fixed-Layout Document

An EPUB Content Document with fixed dimensions directly referenced from the spine. Fixed-Layout Documents are designated pre-paginated in the Package Document, as defined in § 5. Fixed Layouts.

Foreign Resource

A Publication Resource that is not a Core Media Type Resource. Foreign Resources are subject to the fallback requirements defined in § 2.2.1.3 Foreign Resources.

Local Resource

A resource that is located inside the EPUB Container.

Refer to § 2.2.2 Resource Locations for media type specific rules for resource locations.

Manifest

The section of the Package Document that lists the Publication Resources.

Refer to § 2.3.2.4.1 The manifest Element for more information.

Media Overlay Document

An XML document that associates the XHTML Content Document with pre-recorded audio narration to provide a synchronized playback experience, as defined in § 7. Media Overlays.

Non-Codec

Non-Codec refers to content types that benefit from compression due to the nature of their internal data structure, such as file formats based on character strings (for example, HTML, CSS, etc.).

OCF Abstract Container

The OCF Abstract Container defines a file system model for the contents of the OCF ZIP Container, as defined in § 6.1 OCF Abstract Container.

Package Document

A Publication Resource that describes the rendering of an EPUB Publication, as defined in § 2.3 Package Document. The Package Document carries meta information about the EPUB Publication, provides a manifest of resources and defines a default reading order.

Path Name

For a given directory within the OCF Abstract Container, the string holding all directory File Name in the full path concatenated together with a / (U+002F) character separating the directory File Names.

For a given file within the OCF 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.

Publication Resource

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

Publication Resources are typically listed in the Package Document manifest and bundled in the EPUB Container, with two exceptions:

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 to Remote Resources (e.g., referenced from the href attribute of an [HTML] a element).

Remote Resource

A resource that is located outside of the EPUB Container, typically, but not necessarily, online.

Refer to § 2.2.2 Resource Locations for media type specific rules for resource locations.

Root Directory

The root directory represents the base of the OCF Abstract Container file system. This directory is virtual in nature: a EPUB Reading System might or might not generate a physical root directory for the contents of the OCF Abstract Container if the contents are unzipped.

Scripted Content Document

An EPUB Content Document that includes scripting or an XHTML Content Document that contains [HTML] forms.

Refer to § 3.4 Scripting for more information.

Spine

An ordered list of Publication Resources in the Package Document, typically EPUB Content Documents, that represent the default reading order.

Refer to § 2.3.2.5.1 The spine Element for more information.

SVG Content Document

An EPUB Content Document that conforms to the constraints expressed in § 3.2 SVG Content Documents.

Synthetic Spread

The rendering of two adjacent pages simultaneously on a device screen.

Text-to-Speech (TTS)

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

Top-level Content Document

An EPUB Content Document referenced from the spine, whether directly or via a fallback chain.

Unique Identifier

The primary identifier for an EPUB Publication in the Package Document, as identified by the unique-identifier attribute.

Significant revision, abridgement, etc. of the content requires a new Unique Identifier.

Viewport

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

XHTML Content Document

An EPUB Content Document that conforms to the profile of [HTML] defined in § 3.1 XHTML Content Documents.

XHTML Content Documents use the XHTML syntax defined in [HTML].

1.5 Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.6 Authoring Shorthands

1.6.1 Prefixes

In Package Document metadata examples, reserved prefixes are used without declaration.

1.6.2 Namespaces

For convenience, the following namespace prefixes [XML-NAMES] are used in this specification without explicitly being declared. To use any of these prefixes in an EPUB Content Document, a declaration is REQUIRED.

prefix URI
epub http://www.idpf.org/2007/ops
ssml https://www.w3.org/2001/10/synthesis

2. EPUB Publications

2.1 Conformance Criteria

The minimal requirements for an EPUB Publication are that:

Specific conformance details are covered in the rest of this specification.

2.2 Publication Resources

2.2.1 Core Media Types

2.2.1.1 Introduction

An EPUB Publication typically consists of many Publication Resources. These resources are divided into two categories: those that can be included without fallbacks (Core Media Type Resources) and those that cannot (Foreign Resources).

Formats are typically only included as Core Media Type Resources when it can be shown that they have broad support in web browser cores — the rendering engines on which EPUB 3 Reading Systems are built. They are an agreement between Reading System developers and EPUB Creators to ensure the predictability of rendering of EPUB Publications.

Inclusion as a Core Media Type Resource does not mean that all Reading Systems will support the rendering of a resource, however. Only Reading Systems that can render the type of resource have to (e.g., a Reading System with a Viewport has to support image Core Media Type Resources, but a Reading System without a Viewport does not). Refer to Core Media Types [EPUB-RS-33] for more information about which Reading Systems rendering capabilities require support for which Core Media Type Resources.

Foreign Resources come with no guarantee of rendering support, which is why they require a fallback to a Core Media Type Resource. EPUB Publications are designed to be fully consumable on any conforming Reading System, so providing a fallback is necessary to ensure that the use of Foreign Resources does not impact on the ability of the user to consume the content.

This section lists the set of Core Media Type Resources and identifies fallback mechanisms that can be used to satisfy the consumability requirement.

Note

EPUB also exempts some [HTML] elements from support requirements (see § 3.1.4.5 Foreign Resource Restrictions). Resources referenced from these elements are neither Core Media Type Resources nor Foreign Resources — they do not require fallbacks, but they also have no support requirements.

2.2.1.2 Supported Media Types

Publication Resources that conform to the following MIME media type [RFC2046] specifications can be included in an EPUB Publication without fallbacks.

The columns in the following table represent the following information:

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

    If more than one media type is listed, the first one is the preferred media type. The preferred media type is strongly encouraged for all new EPUB Publications.

  • Content Type Definition—The specification to which the given Core Media Type Resource has to conform.
  • Applies to—The Publication Resource type(s) that the Media Type and Content Type Definition applies to.
Media Type Content Type Definition Applies to
Images
image/gif [GIF] GIF Images
image/jpeg [JPEG] JPEG Images
image/png [PNG] PNG Images
image/svg+xml SVG Content Documents SVG documents
image/webp [WebP-Container], [WebP-LB] WebP Images
Audio
audio/mpeg [MP3] MP3 audio
audio/mp4 [MPEG4-Audio], [MP4] AAC LC audio using MP4 container
audio/opus [RFC7845] OPUS audio using OGG container
Video
EPUB 3 allows any video codecs to be included without fallbacks, although none are technically considered Core Media Type Resources. Although Reading Systems are recommended to support at least one of the H.264 [H264] and VP8 [RFC6386] video codecs, it is not a conformance requirement — a Reading System might support other video codecs, or none at all. EPUB Creators and need to take into consideration factors such as breadth of adoption, video playback quality, and technology usage royalty requirements when making a choice to include video in either format, or both.
Style
text/css CSS Style Sheets CSS Style Sheets.
Fonts
EPUB 3 allows any font resource to be included without a fallback, as CSS already defines fallback rules for fonts. Refer to the Reading System support requirements for fonts [EPUB-RS-33] for more information.
font/ttf
application/font-sfnt 		[TrueType] TrueType fonts
font/otf
application/font-sfnt
application/vnd.ms-opentype 		[OpenType] OpenType fonts
font/woff
application/font-woff 		[WOFF] WOFF fonts
font/woff2 [WOFF2] WOFF2 fonts
Other
application/xhtml+xml XHTML Content Documents XHTML Content Documents that use the XHTML syntax [HTML].
application/javascript
text/javascript 		[RFC4329] Scripts.
application/x-dtbncx+xml [OPF-201] The legacy NCX.
application/smil+xml Media Overlays EPUB Media Overlay documents
application/pls+xml [PRONUNCIATION-LEXICON] Text-to-Speech (TTS) Pronunciation lexicons
Issue 645 : Add Opus codec as core media type EPUB33Spec-PublicationsStatus - Subject to Review

Although, OPUS/OGG has good support in Android, MacOS, Windows, and Linux, Apple, starting with iOS 11, only supports the OPUS codec in a CAF container. The working group will monitor support for OPUS in iOS and may remove OPUS as a core media type if the level of support is inadequate.

WebP is currently not defined in a stable specification and its media type has not been registered with IANA. Apple also only supports WebP on macOS 11. The working group will continue to monitor these issues.

2.2.1.3 Foreign Resources

Foreign Resources MAY be included in an EPUB Publication without a fallback provided they are not referenced from spine itemref elements or directly rendered in their native format in EPUB Content Documents (e.g., via [HTML] embedded content and [SVG] image and foreignObject elements).

Note

This exception allows EPUB Creators to include resources in the EPUB Container that are not for use by EPUB Reading Systems. The primary case for this exception is to allow data files to travel with an EPUB Publication, whether for use by scripts in its constituent EPUB Content Documents or for use by external applications (e.g., a scientific journal might include a data set with instructions on how to extract it from the EPUB Container).

When a Foreign Resource is included in the spine or directly rendered in its native format in an EPUB Content Document, a fallback Core Media Type Resource MUST be included. Fallbacks take one of the following forms:

  • intrinsic fallback mechanisms provided by the host format (e.g., [HTML] elements often provide the ability to reference more than one media type or to display an alternate embedded message when a media type cannot be rendered); or

  • manifest fallbacks.

Manifest fallbacks are a feature of the Package Document that create fallback chains to Core Media Type Resources. They are used to create fallbacks for Foreign Resources in the spine and when intrinsic fallback capabilities are not available (e.g., for the [HTML] img element).

Refer to the [HTML] and [SVG] specifications for the intrinsic fallback capabilities their elements provide.

2.2.2 Resource Locations

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

  •   Audio resources MAY be located outside the EPUB Container.

  •   Video resources MAY be located outside the EPUB Container.

  •   Resources retrieved by scripts MAY be located outside the EPUB Container.

  •   Font resources MAY be located outside the EPUB Container.

EPUB Creators are encouraged to locate these resources inside the EPUB Container whenever feasible to allow users access to the entire presentation regardless of connectivity status.

Note

The rules in this section 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 is indicated via the remote-resources property on the manifest item element.

2.2.3 Data URLs

The data: URL scheme [RFC2397] is used to encode resources directly into a URL string. The advantage of this scheme is that it allows a resource to be embedded within another, avoiding the need for an external file.

EPUB Creators MAY use data URLs in EPUB Publications provided their use does not result in a Top-level Content Document or top-level browsing context [HTML]. This restriction applies to data URLs used in the following scenarios:

  • in manifest item elements referenced from the spine;

  • in the href attribute on [HTML] or [SVG] a elements (except when inside an iframe element [HTML]);

  • in the href attribute on [HTML] area elements (except when inside an iframe element);

  • in calls to [ECMASCRIPT] window.open or document.open.

Note

The list of prohibited uses for data URLs is subject to change as the respective standards that allow their use evolve.

This restriction on their use is to prevent security issues and also to ensure that Reading Systems can determine where to take a user next (i.e., because these resources are not be listed in the spine).

Resources represented as data URLs are not Publication Resources so are exempt from the requirement to be listed in the manifest.

Data URLs MUST encode Core Media Types or be used where a fallback to one is provided (i.e., they are subject to the foreign resource restrictions).

2.2.4 XML Conformance

Any Publication Resource that is an XML-Based Media Type has to meet the following constraints:

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

Note

Although EPUB Reading Systems are required to support [EPUB-RS-33] the XML base attribute [XMLBase], [HTML] and [SVG] are removing support. EPUB Creators are advised to avoid using this feature.

2.3 Package Document

2.3.1 Introduction

This section is non-normative.

The Package Document is an XML document that consists of a set of elements that each encapsulate information about a particular aspect of an EPUB Publication. These elements serve to centralize metadata, detail the individual resources, and provide the reading order and other information necessary for its rendering.

The following list summarizes the information found in the Package Document:

  • Metadata — mechanisms to include and/or reference metadata.

  • A manifest — identifies via IRI [RFC3987], and describes via MIME media type [RFC4839], the set of Publication Resources.

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

  • Collections — a method of encapsulating and identifying subcomponents within the Package.

  • Manifest fallback chains — a mechanism that defines an ordered list of top-level resources as content equivalents. A Reading System can then choose between the resources based on which it is capable of rendering.

Note

An EPUB Publication can reference more than one Package Document, allowing for alternative representations of the content. For more information, refer to § 6.1.5.2.1 Container File (container.xml)

Note

Refer to § G.1 The application/oebps-package+xml Media Type for information about the file properties of Package Documents.

2.3.2 Package Document Definition

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

When an element defined in this section has mandatory text content, that content is referred to as the value of the element in the explanatory descriptions.

2.3.2.1 Shared Attributes

This section provides definitions for shared attributes (i.e., attributes that are allowed on two or more elements).

dir

Specifies the base direction [BIDI] of the carrying element and its descendants.

Allowed values are:

  • ltr — left-to-right base direction;
  • rtl — right-to-left base direction; and
  • auto — base direction is determined using the Unicode Bidi Algorithm [BIDI].

The value auto is assumed when the attribute is not specified or contains an invalid value.

Note

The base direction specified in the dir attribute does not affect the ordering of characters within directional runs, only the relative ordering of those runs and the placement of weak directional characters such as punctuation.

<package … dir="ltr">

Allowed on: collection, dc:contributor, dc:coverage, dc:creator, dc:description, dc:publisher, dc:relation, dc:rights, dc:subject, dc:title, meta and package.

href

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

<link rel="record"
      href="meta/9780000000001.xml" 
      media-type="application/marc"/>

Allowed on: item and link.

id

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

<dc:identifier id="pub-id">urn:isbn:97800000000001</dc:identifier>

Allowed on: collection, dc:contributor, dc:coverage, dc:creator, dc:date, dc:description, dc:format, dc:identifier, dc:language, dc:publisher, dc:relation, dc:rights, dc:source, dc:subject, dc:title, dc:type, item, itemref, link, manifest, meta, package and spine.

media-type

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

<link rel="record"
      href="http://example.org/meta/12389347?format=xmp"
      media-type="application/xml"
      properties="xmp"/>

Allowed on: item and link.

properties

A space-separated list of property values.

Refer to each element's definition for the reserved vocabulary that can be used with the attribute.

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

Allowed on: item, itemref and link.

refines

Establishes an association between the current expression and the element or resource identified by its value. The value of the attribute must be a relative IRI [RFC3987] that references the resource or element being described.

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

When creating expressions about a Publication Resource, the refines attribute SHOULD be a fragment identifier that references the ID of the resource's manifest entry.

Allowed on: link and meta.

xml:lang

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]. The value of each xml:lang attribute MUST be a well-formed language tag [BCP47].

<package … xml:lang="ja">
	…
</package>

Allowed on: collection, dc:contributor, dc:coverage, dc:creator, dc:description, dc:publisher, dc:relation, dc:rights, dc:subject, dc:title, meta and package.

2.3.2.2 The package Element

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

Element Name

package

Usage

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

Attributes
Content Model

In this order:

The version attribute specifies the EPUB specification version to which the given EPUB Publication conforms. The attribute MUST have the value "3.0" to indicate conformance with EPUB 3.

Note

Updates to this specification do not represent new versions of EPUB 3 (i.e., each new 3.X specification is a continuation of the EPUB 3 format). The Working Group is committed to minimizing any changes that would invalidate existing content, allowing the version attribute value to remain unchanged.

The unique-identifier attribute takes an IDREF [XML] that identifies the dc:identifier element that provides the preferred, or primary, identifier.

The prefix attribute provides a declaration mechanism for prefixes not reserved by this specification. Refer to § D.1.4 The prefix Attribute for more information.

2.3.2.3 Metadata Section
2.3.2.3.1 The metadata Element

The metadata element encapsulates meta information.

Element Name

metadata

Usage

REQUIRED first child of package.

Attributes

None

Content Model

In any order:

The Package Document metadata element has two primary functions:

  1. to provide a minimal set of meta information for Reading Systems to use to internally catalogue an EPUB Publication and make it available to a user (e.g., to present in a bookshelf).

  2. to provide access to all rendering metadata needed to control the layout and display of the content (e.g., fixed-layout properties).

The Package Document is not designed to provide complex metadata encoding capabilities. If more detailed information about an EPUB Publication is needed, metadata records (e.g., that conform to an international standard such as [ONIX] or are created for custom purposes) can be associated using the link element. This approach allows the metadata to be processed in its native form, avoiding the potential problems and information loss caused by translating to use the minimal Package Document structure.

In keeping with this philosophy, the Package Document only has the following minimal metadata requirements: it MUST contain the [DC11] title, identifier, and language elements together with the [DCTERMS] modified property. All other metadata is OPTIONAL.

The meta element provides a generic mechanism for including metadata properties from any vocabulary. It is typically used to include rendering metadata defined in EPUB specifications, but MAY be used for any metadata purposes.

Note

See [EPUB-A11Y-11] for accessibility metadata recommendations.

2.3.2.3.2 Metadata Values

The Dublin Core elements [DC11] and meta element have mandatory child text content [DOM]. That content is referred to as the value of the element in their descriptions.

These elements MUST have non-empty values after leading and trailing ASCII whitespace [Infra] is stripped (i.e., they must consist of at least one non-whitespace character).

Whitespace within these element values are not significant. Sequences of one or more whitespace characters are collapsed to a single space [Infra] during processing .

2.3.2.3.3 DCMES Required Elements
2.3.2.3.3.1 The identifier Element

The [DC11] identifier element contains an identifier such as a UUID, DOI or ISBN.

Element Name

dc:identifier

Namespace

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

Usage

REQUIRED child of metadata.

Attributes

  • id [conditionally required]

Content Model

Text

The EPUB Creator MUST provide an identifier that is unique to one and only one EPUB Publication — its Unique Identifier — in an identifier element. This identifier element MUST specify an id attribute whose value is referenced from the package element's unique-identifier attribute.

Although not static, changes to the Unique Identifier for an EPUB Publication SHOULD be made as infrequently as possible. Unique Identifiers are intended to have maximal persistence both for referencing and distribution purposes. New identifiers SHOULD NOT be issued when making minor revisions such as updating metadata, fixing errata, or making similar minor changes.

EPUB Creators MAY specify additional identifiers. It is strongly advised that identifiers be fully qualified URIs.

The identifier-type property is used to indicate that an identifier conforms to an established system or has been granted by an issuing authority.

2.3.2.3.3.2 The title Element

The [DC11] title element represents an instance of a name for the EPUB Publication.

Element Name

dc:title

Namespace

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

Usage

REQUIRED child of metadata.

Attributes
Content Model

Text

The metadata section MUST contain at least one title element containing the title for the EPUB Publication.

The first title element in document order is the main title of the EPUB Publication (i.e., the primary one Reading Systems present to users).

EPUB Creators are strongly advised to use only a single title element to ensure consistent rendering of the title in Reading Systems.

Note

Although it is possible to include more than one title element for multipart titles, Reading System support for additional title elements is inconsistent. Reading Systems may ignore the additional segments or combine them in unexpected ways.

For example, the following example shows a basic multipart title:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:title>THE LORD OF THE RINGS</dc:title>
    <dc:title>Part One: The Fellowship of the Ring</dc:title>
    …
</metadata>

The same title could instead be expressed using a single dc:title element as follows:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:title>
        THE LORD OF THE RINGS, Part One: The Fellowship of the Ring
    </dc:title>
    …
</metadata>

Previous versions of this specification recommended using the title-type and display-seq properties to identify and format the segments of multipart titles (see the Great Cookbooks example). It is still possible to add these semantics but they are also not well supported.

2.3.2.3.3.3 The language Element

The [DC11] language element specifies the language of the content of the EPUB Publication.

Element Name

dc:language

Namespace

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

Usage

REQUIRED child of metadata. Repeatable.

Attributes

id [optional]

Content Model

Text

The metadata section MUST contain at least one language element. The value of each language element MUST be a well-formed language tag [BCP47].

Although additional language elements MAY be specified for multilingual Publications, the first language element in document order is considered the primary language of the EPUB Publication.

Note

Publication Resources do not inherit their language from the dc:language element(s). The language of a resource has to be set using the intrinsic methods of the format.

2.3.2.3.4 DCMES Optional Elements
2.3.2.3.4.1 General Definition

All [DC11] elements except for identifier, language, and title are designated as OPTIONAL. These elements 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

  • dir [optional] – only allowed on contributor, coverage, creator, description, publisher, relation, rights, and subject.

  • id [optional] – allowed on any element.

  • xml:lang [optional] – only allowed on contributor, coverage, creator, description, publisher, relation, rights, and subject.

Content Model

Text

This specification does not modify the [DC11] element definitions except as noted in the following sections.

2.3.2.3.4.2 The contributor Element

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

The requirements for the contributor element are identical to those for the creator element in all other respects.

2.3.2.3.4.3 The creator Element

The [DC11] creator element represents the name of a person, organization, etc. responsible for the creation of the content. The role property can be associated with the element to indicate the function the creator played.

The creator element SHOULD contain the name of the creator as it is intended to be displayed to a user. The file-as property MAY be associated with the element to include a normalized form of the name, and the alternate-script property to represent a creator's name in another language or script.

If an EPUB Publication has more than one creator, each SHOULD be specified in a separate creator element.

The document order of creator elements in the metadata section determines the display priority, where the first creator element encountered is the primary creator.

Secondary contributors SHOULD be represented using the contributor element.

2.3.2.3.4.4 The date Element

The [DC11] 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 EPUB Publication was changed).

It is RECOMMENDED that the date string conform to [ISO8601], particularly the subset expressed in W3C Date and Time Formats [DateTime], as such strings are both human and machine readable.

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

Only one date element is allowed.

2.3.2.3.4.5 The subject Element

The [DC11] subject element identifies the subject of the EPUB Publication. The value of the element SHOULD be the human-readable heading or label, but MAY be the code value if the subject taxonomy does not provide a separate descriptive label.

EPUB Creators MAY identify the system or scheme the element's value is drawn from using the authority property.

When a scheme is identified, a subject code MUST be associated with the element using the term property.

The term property MUST NOT be associated with a subject element that does not specify a scheme.

The values of the subject element and term property are case sensitive only when the designated scheme requires.

2.3.2.3.4.6 The type Element

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

An informative registry of specialized EPUB Publication types for use with this element is maintained in the [TypesRegistry], but EPUB Creators MAY use any text string as a value.

2.3.2.3.5 The meta Element

The meta element provides a generic means of including package metadata.

Element Name

meta

Usage

As child of the metadata element. Repeatable.

Attributes
Content Model

Text

Each meta element defines a metadata expression. The property attribute takes a property data type value that defines the statement being made in the expression, and the text content of the element represents the assertion. (Refer to § D.1 Vocabulary Association Mechanisms for more information.)

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 is associated with another expression or resource using the refines attribute to enhance its meaning. A subexpression might refine a media clip, for example, by expressing its duration, or refine a creator or contributor expression by defining the role of the person.

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 the DCMES [DC11] elements represent primary expressions, and permit refinement by meta element subexpressions.

The Meta Properties Vocabulary is the default vocabulary for use with the property attribute. If the attribute's value does not include a prefix, the following IRI [RFC3987] stem MUST be used to generate the resulting IRI: http://idpf.org/epub/vocab/package/meta/#

EPUB Creators MAY add terms from other vocabularies as defined in § D.1 Vocabulary Association Mechanisms.

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

2.3.2.3.6 Last Modified Date

The metadata section MUST contain exactly one [DCTERMS] modified property containing the last modification date. The value of this property MUST be an [XMLSCHEMA-2] dateTime conformant date of the form: CCYY-MM-DDThh:mm:ssZ

The last modification date MUST be expressed in Coordinated Universal Time (UTC) and MUST be terminated by the "Z" (Zulu) time zone indicator.

EPUB Creators MUST update the last modified date whenever changes are made to the EPUB Publication.

Additional modified properties MAY be specified in the Package Document metadata, but they MUST have a different subject (i.e., they require a refines attribute that references an element or resource).

Note

The requirements for the last modification date are to ensure compatibility with earlier versions of EPUB 3 that defined a release identifier [EPUBPackages-32] for EPUB Publications.

2.3.2.4 Manifest Section
2.3.2.4.1 The manifest Element

The manifest element provides an exhaustive list of Publication Resources used in the rendering of the content.

Element name

manifest

Usage

REQUIRED second child of package, following metadata.

Attributes

id [optional]

Content Model

item [1 or more]

All Publication Resources MUST be listed in the manifest, regardless of whether they are Local or Remote Resources. Each is represented by an item element.

Note that the manifest is not self-referencing: it MUST NOT specify an item element that refers to the Package Document itself.

Note

Failure to provide a complete manifest of resources may lead to rendering issues. Reading Systems might not unzip such resources or could prevent access to them for security reasons.

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 need to be restricted to the ASCII character set.

2.3.2.4.2 The item Element

The item element represents a Publication Resource.

Element Name

item

Usage

As a child of manifest. Repeatable.

Attributes
Content Model

Empty

Each item element identifies a Publication Resource by the IRI [RFC3987] provided in its href attribute. The IRI MAY be absolute or relative, but each IRI MUST be unique within the manifest scope after resolution to an absolute IRI [EPUB-RS-33].

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 § 2.2.1.2 Supported Media Types.

The fallback attribute takes an IDREF [XML] that identifies a fallback for the Publication Resource referenced from the item element. Fallbacks MAY be provided for Core Media Type Resources (e.g., to provide a static alternative to a Scripted Content Document). Fallback requirements for Foreign Resources are defined in § 2.3.2.4.3 Manifest Fallbacks.

The Manifest Properties Vocabulary is the default vocabulary for the properties attribute. If any of the attribute's values do not include a prefix, the following IRI [RFC3987] stem MUST be used to generate the resulting IRI for them: http://idpf.org/epub/vocab/package/item/#

EPUB Creators MAY add terms from other vocabularies as defined in § D.1 Vocabulary Association Mechanisms.

EPUB Creators MUST declare all applicable descriptive metadata properties for each Publication Resource in this attribute.

Exactly one item MUST be declared as the EPUB Navigation Document using the nav property.

The media-overlay attribute takes an IDREF [XML] that identifies the Media Overlay Document for the resource described by this item. Refer to § 7.3.5 Media Overlays Packaging for more information.

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 contains only 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>
2.3.2.4.3 Manifest Fallbacks

Foreign Resources MAY be referenced in contexts in which an intrinsic fallback cannot be provided (e.g., directly from spine itemref elements; from [HTML] img, iframe and link elements in XHTML Content Documents; and from @import rules in CSS Style Sheets). Manifest fallbacks MUST be provided in such cases.

Manifest 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 EPUB Creator's preferred fallback order.

Fallback chains MUST conform to one of the following requirements, as appropriate:

Fallback chains MUST NOT contain circular or self-references to item elements in the chain. User agents MUST terminate the fallback chain at the first reference to a manifest item that has already been encountered.

Fallbacks MAY also be provided for Top-Level Content Documents that are EPUB Content Documents. An example of when this feature can be utilized is when providing fallbacks for scripted content.

Note

As it is not possible to use manifest fallbacks for resources represented in data URLs, Foreign Resources can only be represented as data URLs where an intrinsic fallback mechanism is available.

2.3.2.4.4 The bindings Element (Deprecated)

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

Refer to [EPUBPublications-301] for more information about this element.

2.3.2.5 Spine Section
2.3.2.5.1 The spine Element

The spine element defines an ordered list of manifest item references that represent the default reading order.

Element name

spine

Usage

REQUIRED third child of package, following manifest.

Attributes
Content Model

itemref [1 or more]

The spine MUST specify at least one Publication Resource.

All Publication Resources that are hyperlinked to from Publication Resources in the spine MUST themselves be listed in the spine, where hyperlinking is defined to be any linking mechanism that requires the user to navigate away from the current resource. Common hyperlinking mechanisms include the href attribute of the [HTML] a and area elements and scripted links (e.g., using DOM Events and/or form elements). The requirement to list hyperlinked resources applies recursively (i.e., all Publication Resources hyperlinked from hyperlinked Publication Resources also have to be listed, and so on.).

All Publication Resources hyperlinked to from the EPUB Navigation Document also MUST be listed in the spine, regardless of whether the Navigation Document is itself listed in the spine.

Note

As Remote Resources referenced from hyperlinks are not Publication Resources, they are not subject to the requirement to include in the spine (e.g., Web pages and resources).

Embedded Publication Resources (e.g., via the [HTML] iframe element) do not have to be listed in the spine.

The page-progression-direction attribute sets the global direction in which the content flows. Allowed values are ltr (left-to-right), rtl (right-to-left) and default. When the default value is specified, the EPUB Creator is expressing no preference and the Reading System can choose the rendering direction.

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

The legacy toc attribute takes an IDREF [XML] that identifies the manifest item that represents the NCX.

2.3.2.5.2 The itemref Element

The itemref element identifies a Publication Resource in the default reading order.

Element Name

itemref

Usage

As a child of spine. Repeatable.

Attributes
Content Model

Empty

Each itemref element MUST reference the ID [XML] of a unique item in the manifest via the IDREF [XML] in its idref attribute (i.e., two or more itemref elements cannot reference the same item).

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 EPUB Publications require an EPUB Navigation Document, it is not mandatory to include it in the spine.

The linear attribute indicates whether the referenced item contains content that contributes to the primary reading order and has to be read sequentially ("yes") or auxiliary content that enhances or augments the primary content and can be accessed out of sequence ("no"). Examples of auxiliary content include notes, descriptions, and answer keys.

The linear attribute allows Reading Systems to distinguish content that a user needs to access as part of the default reading order from supplementary content which might, for example, be presented in a popup window or omitted from an aural rendering.

Specifying that content is non-linear does not require Reading Systems to present it in a specific way, however; it is only a hint to the purpose. Reading Systems may present non-linear content where it occurs in the spine, for example, or may skip it until users reach the end of the spine.

Note

EPUB Creators should list non-linear content at the end of the spine except when it makes sense for users to encounter it between linear spine items.

The spine MUST contain at least one linear itemref element — whose linear attribute value is either explicitly or implicitly set to "yes". An itemref that omits the linear attribute is assumed to have the value "yes".

EPUB Creators MUST provide a means of accessing all non-linear content (e.g., hyperlinks in the content or from the EPUB Navigation Document).

The Spine Properties Vocabulary is the default vocabulary for the properties attribute. If any of the attribute's values do not include a prefix, the following IRI [RFC3987] stem MUST be used to generate the resulting IRI for them: http://idpf.org/epub/vocab/package/itemref/#

EPUB Creators MAY add terms from other vocabularies as defined in § D.1 Vocabulary Association Mechanisms.

Examples
2.3.2.6 Collections
2.3.2.6.1 The collection Element

The collection element defines a related group of resources.

Element Name

collection

Usage

OPTIONAL sixth element of package. Repeatable.

Attributes
Content Model

In this order: metadata [0 or 1], ( collection [1 or more] or ( collection [0 or more], link [1 or more] ))

The collection element allows resources to be assembled into logical groups for a variety of potential uses: enabling content that has been split across multiple EPUB Content Documents to be reassembled back into a meaningful unit (e.g., an index split across multiple documents), identifying resources for specialized purposes (e.g., preview content), or collecting together resources that present additional information about the EPUB Publication.

The collection element, as defined in this section, represents a generic framework from which specializations are intended to be derived (e.g., through EPUB sub-specifications). Such specializations MUST define the purpose of the collection element, as well as all requirements for its valid production and use (specifically any requirements that differ from the general framework presented below).

Each specialization MUST define a role value that uniquely identifies all conformant collection elements. The role of each collection element in the Package Document MUST be identified in its role attribute, whose value MUST be one or more NMTOKENs [XMLSCHEMA-2] and/or absolute IRIs [RFC3987]. The use of NMTOKEN values is reserved for roles not defined in EPUB, which are maintained in the [RoleRegistry]. NMTOKEN values not defined in the registry are not valid. No roles are defined in this section.

Third parties MAY define custom roles for the collection element, but such roles MUST be identified using absolute IRIs. Custom roles MUST NOT incorporate the string "idpf.org" in the host component of their identifying IRI.

Note

To facilitate interoperability of custom roles across Reading Systems, implementers are strongly encouraged to document their use of the collection element in [RoleExtensions].

The OPTIONAL metadata element child of collection is an adaptation of the package metadata element, with the following differences in syntax and semantics:

A collection MAY define sub-collections through the inclusion of one or more child collection elements.

  • The rel attribute is OPTIONAL.

  • The properties attribute also accepts manifest item properties without a prefix (e.g., so that a collection can declare its own Navigation Document or cover image).

  • The refines attribute MUST NOT be specified.

Each link element MUST reference a resource that is a member of the group. The order of link elements is not significant.

Specializations of the collection element MAY tailor the requirements defined above to better reflect their needs (e.g., requiring metadata, imposing further restrictions on the use of elements and attributes, or making the order of link elements significant). However, the resulting content model MUST represent a valid subset of the one defined in this section (e.g., specializations cannot introduce new elements or attributes, or re-introduce those expressly forbidden above). Specializations MUST NOT define collections in a way that overrides the requirements of the manifest and spine.

The rendering of an EPUB Publication MUST NOT be dependent on the recognition of collection elements. The content MUST remain consumable by a user without any information loss or other significant deterioration.

Examples
2.3.2.7 Legacy Content
2.3.2.7.1 The meta Element

The meta element [OPF-201] is a legacy feature that previously provided a means of including generic metadata. It is replaced in EPUB 3 by the updated meta element, which uses different attributes and requires text content.

For more information about the meta element, refer to its definition in [OPF-201].

2.3.2.7.2 The guide Element

The guide element [OPF-201] is a legacy feature that previously provided machine-processable navigation to key structures. It is replaced in EPUB 3 by landmarks in the EPUB Navigation Document.

For more information about the guide element, refer to its definition in [OPF-201].

2.3.2.7.3 NCX

The NCX [OPF-201] is a legacy feature that previously provided the table of contents. It is replaced in EPUB 3 by the EPUB Navigation Document.

For more information about the NCX, refer to its definition in [OPF-201].

3. EPUB Content Documents

3.1 XHTML Content Documents

3.1.1 Introduction

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

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

3.1.2 XHTML Requirements

An XHTML Content Document has to meet the following basic requirements:

Note

The recommendation that EPUB Publications follow the accessibility requirements in [EPUB-A11Y-11] applies to XHTML Content Documents. See Accessibility.

3.1.3 HTML Extensions

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

Note

Although [HTML] allows user agents to support vendor-neutral extensions, unless such extensions are listed in this section, they are not supported features of EPUB 3.

3.1.3.1 Structural Semantics

The epub:type attribute MAY be used in XHTML Content Documents to express structural semantics.

As the [HTML] head element contains metadata for the document, structural semantics expressed on this element or any descendant of it have no meaning.

3.1.3.2 RDFa

The [HTML-RDFA] specification defines a set of attributes that MAY be used in XHTML Content Documents to semantically enrich the content. The use of these attributes MUST conform to the requirements defined in [HTML-RDFA].

The [HTML-RDFA] specification defines changes to the [HTML] content model when RDFa attributes are used. This modified content model is valid in XHTML Content Documents.

Note

The listing of RDFa is does not express a preference on the part of the Working Group, only that these attributes represent an extension of the HTML grammar. EPUB Creators can also specify microdata attributes [HTML] and linked data [JSON-LD11] in XHTML Content Documents as both are natively supported.

3.1.3.3 SSML Attributes
3.1.3.3.1 Introduction

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

This specification recasts the [SSML] phoneme element as two attributes — ssml:ph and ssml:alphabet — and makes them available within 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 [EPUB-OVERVIEW-33].

3.1.3.3.2 The ssml:ph attribute

The ssml:ph attribute specifies a phonemic/phonetic pronunciation of the text represented by the element the attribute is specified on.

Attribute Name

ph

Namespace

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

Usage

Global attribute. 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] 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).

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

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

Usage

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

Note

Although the [SSML] specification refers to a registry of alphabets, one has not been published. As the charter of the W3C Voice Browser Working Group has expired, the publication of such a registry is not anticipated. EPUB Creators therefore need to reference Reading System support documentation to determine what alphabet values are supported. Some common alphabets include x-JEITA (also x-JEITA-IT-4002 and x-JEITA-IT-4006) and x-sampa.

3.1.3.4 Content Switching (Deprecated)

The switch element provides a simple mechanism through which EPUB Creators can tailor the content displayed to users, one that is not dependent on the scripting capabilities of the EPUB Reading System.

Use of the switch element is deprecated. Refer to its definition in [EPUBContentDocs-301] for usage information.

3.1.3.5 The epub:trigger Element (Deprecated)

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.

Use of the trigger element is deprecated. Refer to its definition in [EPUBContentDocs-301] for usage information.

3.1.3.6 Custom Attributes

EPUB Creators MAY specify custom attributes [EPUB-RS-33] in XHTML Content Documents to take advantage of Reading System-specific functionality not defined in this specification.

Custom attributes MAY be specified on any element in an XHTML Content Document.

When using custom attributes, the content MUST remain consumable by a user without any information loss or other significant deterioration, regardless of the Reading System it is rendered on.

Note

Refer to [AttributeExtensions] for a registry of custom attributes.

3.1.4 HTML Deviations and Constraints

This section defines deviations from, and constraints on, the underlying [HTML] document model applicable to EPUB 3 XHTML Content Documents.

3.1.4.1 Embedded MathML

XHTML Content Documents support embedded [MATHML3]. Occurrences of MathML markup MUST conform to the constraints expressed in the MathML specification [MATHML3], with the following additional restrictions:

Presentation MathML

The math element MUST contain only Presentation MathML, except within the annotation-xml element.

Content MathML

Content MathML MAY be included within MathML markup in XHTML Content Documents, and, when present, MUST occur within an annotation-xml child element of a semantics element.

When Content MathML is included as per the previous condition, the given 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 [MATHML3] MUST NOT be included within MathML markup in XHTML Content Documents.

This subset is designed to ease the implementation burden on Reading Systems and to promote accessibility, while retaining compatibility with [HTML] user agents.

Note

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

3.1.4.2 Embedded SVG

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

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

Note

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

3.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 [CSS-Fonts-3] that contains an appropriate glyph for that code point.

3.1.4.4 Discouraged Constructs

This section is non-normative.

3.1.4.4.1 The rp Element

The [HTML] rp element is intended to provide a fallback for older Reading Systems that do not recognize ruby markup (i.e., a parenthesis display around ruby markup). As EPUB 3 Reading Systems are ruby-aware, and can provide fallbacks, the use of rp elements is discouraged.

3.1.4.4.2 The embed Element

Since the [HTML] embed element does not include intrinsic facilities to provide fallback content for Reading Systems that do not support scripting, EPUB Creators are discouraged from using the element when the referenced resource includes scripting. The [HTML] object element can be used instead, as it includes intrinsic fallback capabilities.

3.1.4.5 Foreign Resource Restrictions

Foreign Resources MAY be referenced from elements that have intrinsic fallback mechanisms, where an intrinsic fallback method is the capability to offer an alternative presentation if the foreign resource is not supported. For example, most [HTML] embedded content elements provide options for alternative rendering, such as allowing multiple sources to be specified or allowing embedded HTML content for when a resource cannot be rendered. A Core Media Type Resource or embedded HTML content MUST be provided via the given element's intrinsic fallback mechanism when a Foreign Resource is referenced.

[HTML] flow content MAY be embedded within the audio and video elements for rendering in older Reading Systems that do not recognize these elements (e.g., EPUB 2 Reading Systems), but it does not represent a fallback Core Media Type Resource.

Due to the variety of sources that can be associated with to the [HTML] img element, the following fallback conditions apply to its use:

  • If it is the child of a picture element:

    • it MUST reference Core Media Type Resources from its src and srcset attributes, when those attributes are specified; and
    • each sibling source element MUST reference a Core Media Type Resource from its src and srcset attributes unless it specifies a media type in its type attribute that is not a Core Media Type.
  • Otherwise, it MAY reference Foreign Resources in its src and srcset attributes provided manifest fallbacks are defined.

The following [HTML] elements can refer to Foreign Resources without having to provide a fallback Core Media Type Resource:

Foreign Resources MAY be referenced from the preceding three elements without the provision of a fallback Core Media Type Resource.

Note

Refer to manifest fallbacks for the provision of fallbacks for elements without intrinsic mechanisms, such as the [HTML] iframe.

3.2 SVG Content Documents

Some features of [SVG] are not fully supported in Reading Systems or supported across all platforms on which Reading Systems run. When utilizing such features, EPUB Creators need to consider the inherent risks in terms of the potential impact on interoperability and document longevity.

3.2.1 Introduction

This section is non-normative.

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

Although EPUB Creators typically use 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 (e.g., for cover art or 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 Resource and is referred to in this specification as an SVG Content Document.

Note

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

3.2.2 SVG Requirements

An SVG Content Document has to meet the following requirements:

Note

The recommendation that EPUB Publications follow the accessibility requirements in [EPUB-A11Y-11] applies to SVG Content Documents. See Accessibility.

3.2.3 Restrictions on SVG

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

3.3 CSS Style Sheets

3.3.1 Introduction

This section is non-normative.

CSS is an integral part of the Open Web Platform. Readers, publishers, and document authors expect CSS to "just work," as they expect HTML to just work.

In the past, EPUB defined a profile of CSS that mandated support for certain properties and provided prefixed versions of numerous other properties. Although the CSS Working Group no longer recommends the use of prefixed properties, this specification has to maintain some prefixed properties to avoid breaking existing content. But with the minor exceptions defined in this section, EPUB defers to the W3C to define CSS.

Note

Keep in mind that some Reading Systems will not support all desired features of CSS. In particular, the following are known to be problematic:

  • Reading System-induced pagination can interact poorly with style sheets. Pagination is sometimes done using columns, which can result in incorrect values for viewport sizes. Fixed and absolute positioning are particularly problematic.

  • Some types of screens will render animations and transitions poorly (e.g., those with high latency).

3.3.2 CSS Requirements

A CSS style sheets has to meet the following requirements:

3.3.3 Prefixed Properties

EPUB Creators are strongly encouraged to use unprefixed properties and Reading Systems to support current CSS specifications. The widely-used prefixed properties from [EPUBContentDocs-301] have been retained, but support for the other properties has been removed. EPUB Creators are advised to use CSS-native solutions for the removed properties where and when they are available.

EPUB Creators currently using these prefixed properties are advised to move to unprefixed versions as soon as support allows, as these properties are not anticipated to be supported in the next major version of EPUB.

3.3.3.1 CSS Writing Modes

The following table lists the -epub- prefixed properties for [CSS-Writing-Modes-3]. The Value column indicates the value the property accepts. The Prior EPUB Mapping column indicates values/properties that were used in previous versions of EPUB 3. An asterisk (*) denotes that the older property or value is now deprecated. The final column describes how to implement the prefixed property based on [CSS-Writing-Modes-3-20151215].

Property Value Prior EPUB Mapping Mapping to [CSS-Writing-Modes-3-20151215]
-epub-text-orientation upright upright upright
-epub-text-orientation mixed vertical-right * mixed
-epub-text-orientation sideways-right sideways-right sideways
-epub-text-orientation sideways-right rotate-right * sideways
-epub-text-orientation sideways rotate-normal * sideways
-epub-text-orientation sideways sideways sideways
-epub-text-orientation mixed mixed mixed
-epub-writing-mode horizontal-tb horizontal-tb horizontal-tb
-epub-writing-mode vertical-rl vertical-rl vertical-rl
-epub-writing-mode vertical-lr vertical-lr vertical-lr
-epub-text-combine * -epub-text-combine-horizontal: none none text-combine-upright: none
-epub-text-combine * -epub-text-combine-horizontal: all horizontal text-combine-upright: all
-epub-text-combine * Error horizontal <number> text-combine-upright: digits <number>
3.3.3.2 CSS Text Level 3
Property Value Mapping to [CSS-Text-3-20160119]
-epub-hyphens none | manual | auto No Change
-epub-hyphens all Not Supported
-epub-line-break auto | loose | normal | strict No Change
-epub-text-align-last auto | start | end | left | right | center | justify No Change
-epub-word-break normal | keep-all | break-all No Change
text-transform -epub-fullwidth text-transform: full-width
3.3.3.3 CSS Text Decoration Level 3
Property Value Mapping to [CSS-Text-Decor-3]
-epub-text-emphasis-color <color> No Change
-epub-text-emphasis-position [ over | under ] && [ right | left ] No Change
-epub-text-emphasis-style none | [ [ filled | open ] || [ dot | circle | double-circle | triangle | sesame ] ] | <string> No Change
-epub-text-underline-position auto | [ under || [ left | right ] ] No Change
-epub-text-underline-position alphabetic text-underline-position: auto

Property value syntax defined in Component value combinators [CSS-Values-3].

3.4 Scripting

3.4.1 Script Inclusion

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

The scripted property of the manifest item element is used to indicate that an EPUB Content Document is a Scripted Content Document.

When an [HTML] script element contains a data block [HTML], it does not represent scripted content.

Note

[SVG] does not define data blocks as of publication, but the same exclusion would apply if a future update adds the concept.

EPUB Creators should note that Reading Systems are required to behave as though a unique origin [URL] has been assigned to each EPUB Publication. In practice, this means that it is not possible for scripts to share data between EPUB Publications.

Which context a script is used in also determines the rights and restrictions that a Reading System places on it (refer to Scripting Conformance [EPUB-RS-33] for more information).

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

3.4.2 Scripting Contexts

EPUB 3 defines two contexts for script execution:

Whether the code is embedded directly in the script element or referenced via its src attribute makes no difference to its executing context.

Which context EPUB Creators use for their scripts affects both what actions the scripts can perform and the likelihood of support in Reading Systems, as described in the following subsections.

Note

Refer to § F.1 Scripting Contexts for an example of the difference between the two contexts.

3.4.2.1 Container-Constrained Scripts

A container-constrained script is either of the following:

A container-constrained script MUST NOT contain instructions for modifying the DOM of the EPUB Content Document that embeds it (i.e., the one that contains the iframe element). It also MUST NOT contain instructions for manipulating the size of its containing rectangle.

EPUB Creators should note that support for container-constrained scripting in Reading Systems is only recommended in reflowable documents [EPUB-RS-33]. Furthermore, Reading System support in fixed-layouts EPUBs is optional.

Ensuring container-constrained scripts degrade gracefully in Reading Systems without scripting support is advised (see § 3.4.5 Scripting Fallbacks).

Note

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

3.4.2.2 Spine-Level Scripts

A spine-level script is an instance of the [HTML] script or [SVG] script element contained in a Top-level Content Document.

EPUB Creators should note that support for spine-level scripting in Reading Systems is only recommended in fixed-layout documents and reflowable documents set to scroll [EPUB-RS-33]. Furthermore, Reading System support in all other contexts is optional.

Top-level Content Documents that include spine-level scripting SHOULD remain consumable by the user without any information loss or other significant deterioration when scripting is disabled or not available (e.g., by employing progressive enhancement techniques or fallbacks). Failing to account for non-scripted environments in Top-level Content Documents can result in EPUB Publications being unreadable.

3.4.3 Event Model

This section is non-normative.

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

3.4.4 Scripting Accessibility

EPUB Content Documents that contain scripting SHOULD employ relevant [WAI-ARIA] accessibility techniques to ensure that the content remains consumable by all users.

3.4.5 Scripting Fallbacks

EPUB Content Documents that contain scripting MAY provide fallbacks for such content, either by using intrinsic fallback mechanisms (such as those available for the [HTML] object and canvas elements) or, when an intrinsic fallback is not applicable, by using a manifest-level fallback.

EPUB Creators MUST ensure that scripts only generate Core Media Type Resources or fragments thereof.

3.5 Pronunciation Lexicons

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

A PLS Document MAY be associated with XHTML Content Documents. Each XHTML Content Document MAY contain zero or more PLS document associations.

A PLS Document MUST be associated with the XHTML Content Document to which it applies using the [HTML] link element with its rel attribute set to "pronunciation" and its type attribute set to the media type "application/pls+xml".

The link element hreflang attribute SHOULD be specified on each link, and its value MUST match the language for which the pronunciation lexicon is relevant [PRONUNCIATION-LEXICON] when specified.

PLS Documents MUST be valid to the RELAX NG schema available at the URI https://www.w3.org/TR/2008/REC-pronunciation-lexicon-20081014/pls.rng [PRONUNCIATION-LEXICON].

PLS Documents SHOULD use the file extension .pls.

Note

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

4. EPUB Navigation Document

4.1 Introduction

This section is non-normative.

The EPUB Navigation Document is a mandatory component of an EPUB Publication. It allows EPUB Creators to include a human- and machine-readable global navigation layer, thereby ensuring increased usability and accessibility for the user.

The EPUB Navigation Document is a special type of XHTML Content Document that defines the table of contents for Reading Systems. It may also include other specialized navigation elements, such as a page list and a list of key landmarks. These navigation elements have additional restrictions on their content in order to facilitate their processing.

The EPUB Navigation Document is not exclusively for machine processing, however. There are no restrictions on the structure or content of the EPUB Navigation Document outside of the specialized navigation elements (i.e., EPUB Creators can mark the rest of the document up like any other XHTML Content Document). As a result, it can also be part of the linear reading order, avoiding the need for duplicate tables of contents. Navigation elements that are only destined for machine processing, such as the page list, can be hidden from visual rendering with the hidden attribute.

Note that Reading Systems might strip scripting, styling, and HTML formatting as they generate navigational interfaces from information found in the EPUB Navigation Document. If such formatting and functionality is needed, then the EPUB Navigation Document also needs to be included in the spine. The use of progressive enhancement techniques for scripting and styling of the navigation document will help ensure the content will retain its integrity when rendered in a non-browser context.

4.2 EPUB Navigation Document Definition

4.2.1 The nav Element: Restrictions

When a nav element carries the epub:type attribute in an EPUB Navigation Document, this specification restricts the content model of the element and its descendants as follows:

Content Model
nav

In this order:

ol

In this order:

  • li [1 or more]

li

In this order:

  • (span or a) [exactly 1]

  • ol [conditionally required]

span and a

In any order:

Note that there are no restrictions on the attributes allowed on these elements.

Refer the definition below for additional requirements.

The content model of the nav element is interpreted as follows:

  •   The ol child of the nav element represents the primary level of content navigation.

  •   Each list item of the ordered list represents a heading, structure, or other item of interest. A child a element describes the target that the link points to, while a 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).

  •   The child a or span element MUST provide a non-zero-length text label after concatenation of all child content and application of white space normalization rules. Although non-textual descendant elements MAY be rendered directly to users, text content contained in title or alt attributes MUST be used when determining compliance with this requirement.

  •   If an a or span element contains instances of HTML embedded content that do not provide intrinsic text alternatives, the element MUST also contain a title attribute with an alternate text rendering of the link label.

  •   The IRI reference provided in the href attribute of the a element MUST adhere to the following requirements:

  •   An a element MAY be followed by an ol ordered list representing a subsidiary content level below that heading (e.g., all the subsection headings of a section).

  •   A 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, every sublist MUST adhere to the content requirements defined in this section for constructing the primary navigation list.

As a conforming XHTML Content Document, the EPUB Navigation Document MAY be included in the spine.

In the context of this specification, the default display style of list items within nav elements is equivalent to the list-style: none property [CSSSnapshot]. EPUB Creators MAY specify alternative list styling using CSS for rendering of the document in the spine.

4.2.2 The nav Element: Types

4.2.2.1 Introduction

This section is non-normative.

The nav elements defined in an EPUB Navigation Document are distinguished semantically by the value of their epub:type attribute.

This specification defines three types of navigation aid:

toc

Identifies the nav element that contains the table of contents. The toc nav is the only navigation aid that must be included in the EPUB Navigation Document.

page-list

Identifies the nav element that contains a list of pages for a print or other statically paginated source.

landmarks

Identifies the nav element that contains a list of points of interest.

An EPUB Navigation Document can contain at most one navigation aid for each of these types.

Additional navigation types can be included in the EPUB Navigation Document. See § 4.2.2.5 Other nav Elements for more information.

4.2.2.2 The toc nav Element

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

The references in the toc nav element SHOULD be ordered such that they reflect both:

The toc nav element MUST occur exactly once in an EPUB Navigation Document.

4.2.2.3 The page-list nav Element

The page-list nav element provides navigation to positions in the content that correspond to the locations of page boundaries present in a print source.

The page-list nav element is OPTIONAL in EPUB Navigation Documents and MUST NOT occur more than once.

The page-list nav element SHOULD contain only a single ol descendant (i.e., no nested sublists).

The destinations of the page-list references MAY be identified in their respective EPUB Content Documents using the pagebreak term.

4.2.2.4 The landmarks nav Element

The landmarks nav element identifies fundamental structural components in the content to enable Reading Systems to provide the user efficient access to them.

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

The landmarks nav MUST NOT include multiple entries with the same epub:type value that reference the same resource, or fragment thereof.

The landmarks nav element is OPTIONAL in EPUB Navigation Documents and MUST NOT occur more than once.

4.2.2.5 Other nav Elements

EPUB Navigation Documents MAY contain one or more nav elements in addition to the toc, page-list, and landmarks nav elements defined in the preceding sections. If these nav elements are intended for Reading System processing, they MUST have an epub:type attribute and are subject to the content model restrictions defined in § 4.2.1 The nav Element: Restrictions.

This specification imposes no restrictions on the semantics of any 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.

4.2.3 The hidden attribute

In some cases, EPUB Creators might 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 is not rendered as part of the content flow but is instead exposed to the user separately in a dedicated navigation user interface.

While the display property [CSSSnapshot] can be used to control the visual rendering of EPUB Navigation Documents in Reading Systems with Viewports, not all Reading Systems provide such an interface. To control rendering across all Reading Systems, EPUB Creators MUST use the [HTML] 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).

5. Fixed Layouts

5.1 Introduction

This section is non-normative.

EPUB documents, unlike print books or PDF files, are designed to change. The content flows, or reflows, to fit the screen and to fit the needs of the user. As noted in Rendering and CSS "content presentation adapts to the user, rather than the user having to adapt to a particular presentation of content." [EPUB-OVERVIEW-33]

But this principle does not work for all types of documents. Sometimes content and design are so intertwined they cannot be separated. Any change in appearance risks changing the meaning or losing all meaning. Fixed-Layout Documents give EPUB Creators greater control over presentation when a reflowable EPUB is not suitable for the content.

Fixed layouts are defined using a set of Package Document properties to control the rendering in Reading Systems. In addition, the dimensions of each Fixed-Layout Document is set in its respective EPUB Content Document.

Note

EPUB 3 affords multiple mechanisms for representing fixed-layout content. When fixed-layout content is necessary, the EPUB Creator's choice of mechanism will depend on many factors including desired degree of precision, file size, accessibility, etc. This section does not attempt to dictate the EPUB Creator's choice of mechanism.

5.2 Fixed-Layout Package Settings

5.2.1 Layout

The rendition:layout property specifies whether the content is reflowable or pre-paginated.

When the rendition:layout property is specified on a meta element, it indicates that the paginated or reflowable layout style applies globally (i.e., for all spine items).

The following values are defined for use with the rendition:layout property:

reflowable

The content is not pre-paginated (i.e., Reading Systems apply dynamic pagination when rendering). Default value.

pre-paginated

The content is pre-paginated (i.e., Reading Systems produce exactly one page per spine itemref when rendering).

Note

Reading Systems typically restrict or deny the application of user or user agent style sheets to pre-paginated documents because dynamic style changes are likely to have unintended consequence on the intrinsic properties of such documents. EPUB Creators need to consider the negative impact on usability and accessibility that these restrictions have when choosing to use pre-paginated instead of reflowable content. Refer to Guideline 1.4 - Provide text configuration [UAAG20] for related information.

When the property is set to pre-paginated for a spine item, its content dimensions MUST be set as defined in § 5. Fixed Layouts.

The rendition:layout property MUST NOT be declared more than once.

5.2.1.1 Layout Overrides

EPUB Creators MAY specify the following properties locally on spine itemref elements to override the global value for the given spine item:

layout-pre-paginated
Specifies that the given spine item is pre-paginated.
layout-reflowable
Specifies that the given spine item is reflowable.

Only one of these overrides is allowed on any given spine item.

5.2.2 Orientation

The rendition:orientation property specifies which orientation the EPUB Creator intends the content to be rendered in.

When the rendition:orientation property is specified on a meta element, it indicates that the intended orientation applies globally (i.e., for all spine items).

The following values are defined for use with the rendition:orientation property:

landscape

The content is intended for landscape rendering.

portrait

The content is intended for portrait rendering.

auto

The content is not orientation constrained. Default value.

The rendition:orientation property MUST NOT be declared more than once.

5.2.2.1 Orientation Overrides

EPUB Creators MAY specify the following properties locally on spine itemref elements to override the global value for the given spine item:

orientation-auto
Specifies that the Reading System determines the orientation to render the spine item in.
orientation-landscape
Specifies that the given spine item is to be rendered in landscape orientation.
orientation-portrait
Specifies that the given spine item is to be rendered in portrait orientation.

Only one of these overrides is allowed on any given spine item.

5.2.3 Synthetic Spreads

The rendition:spread property specifies the intended Reading System synthetic spread behavior.

When the rendition:spread property is specified on a meta element, it indicates that the intended Synthetic Spread behavior applies globally (i.e., for all spine items).

The following values are defined for use with the rendition:spread property:

none

Do not incorporate spine items in a Synthetic Spread.

landscape

Render a Synthetic Spread for spine items only when the device is in landscape orientation.

portrait (deprecated)

The use of spreads only in portrait orientation is deprecated.

EPUB Creators are advised to use the value "both" instead, as spreads that are readable in portrait orientation are also readable in landscape.

both

Render a Synthetic Spread regardless of device orientation.

auto

No explicit Synthetic Spread behavior is defined. Default value.

The rendition:spread property MUST NOT be declared more than once.

Note

When Synthetic Spreads are used in the context of HTML and SVG Content Documents, the dimensions given via the viewport meta element and viewBox attribute represents the size of one page in the spread, respectively.

Note

Refer to spine for information about declaration of global flow directionality using the page-progression-direction attribute and that of local page-progression-direction within content documents.

5.2.3.1 Synthetic Spread Overrides

EPUB Creators MAY specify the following properties locally on spine itemref elements to override the global value for the given spine item:

spread-auto
Specifies the Reading System determines when to render a synthetic spread for the spine item.
spread-both
Specifies the Reading System should render a synthetic spread for the spine item in both portrait and landscape orientations.
spread-landscape
Specifies the Reading System should render a synthetic spread for the spine item only when in landscape orientation.
spread-none
Specifies the Reading System should not render a synthetic spread for the spine item.
spread-portrait
The spread-portrait property is deprecated. Refer to its definition in [EPUBPublications-301] for more information.

Only one of these overrides is allowed on any given spine item.

5.2.4 Spread Placement

When a Reading System renders a Synthetic Spread, the default behavior is to populate the spread by rendering the next EPUB Content Document in the next available unpopulated viewport, where the next available viewport is determined by the given page progression direction or by local declarations within Content Documents. An EPUB Creator MAY override this automatic population behavior and force a document to be placed in a particular viewport by specifying one of the following properties on its spine itemref element:

rendition:page-spread-center
The rendition:page-spread-center property specifies the forced placement of a Content Document in a Synthetic Spread.
rendition:page-spread-left
The rendition:page-spread-left property is an alias for the page-spread-left property.
rendition:page-spread-right
The rendition:page-spread-right property is an alias for the page-spread-right property.

The rendition:page-spread-left property indicates that the given spine item is to be rendered in the left-hand slot in the spread, and rendition:page-spread-right that it be rendered in the right-hand slot. The rendition:page-spread-center property indicates to override the synthetic spread mode and render a single viewport positioned at the center of the screen.

The rendition:page-spread-left, rendition:page-spread-right and rendition:page-spread-center properties apply to both pre-paginated and reflowable content, and they only apply when the Reading System is creating Synthetic Spreads.

Although EPUB Creators often indicate to use a spread in certain device orientations, the content itself does not represent true spreads (i.e., two consecutive pages that have to be rendered side-by-side for readability, such as a two-page map). To indicate that two consecutive pages represent a true spread, EPUB Creators SHOULD use the rendition:page-spread-left and rendition:page-spread-right properties on the spine items for the two adjacent EPUB Content Documents, and omit the properties on spine items where one-up or two-up presentation is equally acceptable.

Only one page-spread-* property can be declared on any given spine item.

Note

The rendition:page-spread-left and rendition:page-spread-right properties are aliases for the page-spread-left and spread-right properties. They allow the use of a single vocabulary for all fixed-layout properties. EPUB Creators can use either property set, but older Reading Systems might only recognize the unprefixed versions. The EPUB Spine Properties Vocabulary is no longer being extended for package rendering metadata, so an unprefixed page-spread-center is not available.

5.2.5 Viewport Dimensions (Deprecated)

The rendition:viewport property allows EPUB Creators to express the CSS initial containing block (ICB) [CSS2] for XHTML and SVG Content Documents whose rendition:layout property has been set to pre-paginated.

Use of the property is deprecated. Refer to its definition in [EPUBPublications-301] for more information.

5.3 Content Document Dimensions

This section defines rules for the expression and interpretation of dimensional properties of Fixed-Layout Documents.

Fixed-Layout Documents specify their initial containing block [CSS2] in the manner applicable to their format:

Expressing in XHTML

For XHTML Fixed-Layout Documents, the initial containing block [CSS2] dimensions MUST be expressed in a viewport meta tag using the syntax defined in [CSS-Device-Adapt-1].

Expressing in SVG

For SVG Fixed-Layout Documents, the initial containing block [CSS2] dimensions MUST be expressed using the viewBox attribute [SVG].

6. Open Container Format

6.1 OCF Abstract Container

6.1.1 Introduction

This section is non-normative.

The OCF Abstract Container file system model uses a single common Root Directory for all the contents. All Local Resources for the EPUB Publication are located within the directory tree headed by the Root Directory, but no specific file system structure for them is mandated by this specification.

The file system model also includes a mandatory directory named META-INF that is a direct child of the Root Directory and is used to store the following special files:

container.xml [required]

Identifies the Package Document(s) that define the EPUB Publication.

signatures.xml [optional]

Contains digital signatures for various assets.

encryption.xml [optional]

Contains information about the encryption of Publication Resources. This file is mandatory when obfuscation is used.

metadata.xml [optional]

Used to store metadata about the OCF ZIP Container.

rights.xml [optional]

Used to store information about digital rights.

manifest.xml [optional]

A manifest of container contents as allowed by Open Document Format [ODF].

Conformance requirements for the various files in the META-INF directory are defined in § 6.1.5 META-INF Directory.

6.1.2 File and Directory Structure

The virtual file system for the OCF Abstract Container MUST have a single common Root Directory for all the contents of the container.

The OCF Abstract Container MUST include a directory for configuration files named META-INF that is a direct child of the container's Root Directory. Requirements for the contents of this directory are described in § 6.1.5 META-INF Directory.

The file name mimetype in the Root Directory is reserved for use by OCF ZIP Containers, as explained in § 6.2 OCF ZIP Container.

All other files within the OCF Abstract Container MAY be in any location descendant from the Root Directory, provided they are not within the META-INF directory. In particular, files referenced from an EPUB Publication MUST NOT be in META-INF.

6.1.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 relative IRI references, the Base IRI [RFC3986] is determined by the relevant language specifications for the given file formats. For example, CSS defines how relative IRI references work in the context of CSS style sheets and property declarations [CSSSnapshot].

Note

Some language specifications reference Requests For Comments [RFC] that preceded [RFC3987], in which case the earlier RFC applies for content in that language.

Unlike most language specifications, the Base IRIs for all files within the META-INF directory use the Root Directory of the OCF Abstract Container as the default Base IRI.

For example, if META-INF/container.xml has the following content:

Example 45 
<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="EPUB/Great_Expectations.opf"
            media-type="application/oebps-package+xml" />	
    </rootfiles>
</container>

then the path EPUB/Great_Expectations.opf is relative to the root directory for the OCF Abstract Container and not relative to the META-INF directory.

All relative IRI references MUST resolve to resources within the OCF Abstract Container (i.e., at or below the Root Directory).

6.1.4 File Names

The File Name restrictions described in this section are designed to allow Path Names and File Names to be used without modification on most commonly used operating systems.

In the context of an OCF Abstract Container, File and Path Names are case sensitive and have to meet 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 OCF 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)

    • VERTICAL LINE: | (U+007C)

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

    • Non characters at the end of the Supplementary Planes (U+1FFFE, U+1FFFFF … U+EFFFE, U+EFFFF)

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

  •   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 might support only the [US-ASCII] range for File Names. EPUB Creators who want to use ZIP tools that have these restrictions might find it is best to restrict their File Names to the [US-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.

6.1.5 META-INF Directory

6.1.5.1 Inclusion

All OCF Abstract Containers MUST include a directory called META-INF in their Root Directory.

This directory is reserved for configuration files, in particular those specified in § 6.1.5.2 Reserved Files.

6.1.5.2 Reserved Files
6.1.5.2.1 Container File (container.xml)

The REQUIRED container.xml file in the META-INF directory identifies the Package Documents available in the OCF Abstract Container.

All [XML] elements defined in this section are in the urn:oasis:names:tc:opendocument:xmlns:container namespace [XML-NAMES] unless specified otherwise.

The contents of this file MUST be valid to the definition in this section after removing all elements and attributes from other namespaces (including all attributes and contents of such elements).

Note

The content of this file is also defined informally through an XML schema. See § E.2.1 Schema for container.xml for further details.

6.1.5.2.1.1 The container Element

The container element is the root element of the container.xml file.

Element Name

container

Usage

Root element of the container.xml file.

Attributes
version [required]
This attribute MUST have the value "1.0".
Content Model

In this order:

6.1.5.2.1.2 The rootfiles Element

The rootfiles element contains a list of Package Documents available in the EPUB Container.

Element Name

rootfiles

Usage

REQUIRED first child of container.

Attributes

None

Content Model
6.1.5.2.1.3 The rootfile Element

Each rootfile element identifies the location of one Package Document in the EPUB Container.

Element Name

rootfile

Usage

As child of the rootfiles element. Repeatable.

Attributes
full-path [required]

Identifies the location of a Package Document.

The value of the attribute MUST contain a path component [RFC3986] which MUST take the form of a path-rootless [RFC3986] only. The path components are relative to the Root Directory.

media-type [required]

Identifies the media type of the Package Document.

The value of the attribute MUST be "application/oebps-package+xml".

Content Model

Empty

If more than one rootfile element is defined, each MUST reference a Package Document that conforms to the same version of EPUB. Each Package Document represents one rendering of the EPUB Publication.

Note

Although the EPUB Container provides the ability to reference more than one Package Document, this specification does not define how to interpret, or select from, the available options. Refer to [EPUB-MULTI-REND-11] for more information on how to bundle more than one rendering of the content.

6.1.5.2.1.6 Container Example

This section is non-normative.

The following example shows a sample container.xml file for an EPUB Publication with the root file EPUB/My Crazy Life.opf (the Package Document):

Example 46 
<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="EPUB/My_Crazy_Life.opf"
            media-type="application/oebps-package+xml" />
    </rootfiles>
</container>
6.1.5.2.2 Encryption File (encryption.xml)

The OPTIONAL encryption.xml file in the META-INF directory holds all encryption information on the contents of the container. 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.

6.1.5.2.2.1 The encryption element
Element Name

encryption

Namespace

urn:oasis:names:tc:opendocument:xmlns:container

Usage

Root element of the encryption.xml file.

Attributes

None

Content Model

In any order:

  • EncryptedKey [1 or more]
  • EncryptedData [1 or more]

The encryption element contains child elements of type EncryptedKey and EncryptedData as defined by [XMLENC-CORE1].

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.

Note

The content of the encryption.xml file is also defined informally through an XML schema. See § E.2.2 Schema for encryption.xml for further details.

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 [XMLENC-CORE1] 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 might 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. Within the ZIP directory, encrypted files SHOULD be stored rather than Deflate-compressed.

Note that some situations require obfuscating the storage of embedded resources referenced by an EPUB Publication to make them more difficult to extract for unrestricted use (e.g., fonts). Although obfuscation is not encryption, the encryption.xml file is used in conjunction with the resource obfuscation algorithm to identify resources that need to be de-obfuscated before they can be used.

The following files MUST NOT 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
  • Package Document

Signed resources MAY subsequently be encrypted using the Decryption Transform for XML Signature [XMLENC-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.

6.1.5.2.2.2 Order of Compression and Encryption

When stored in a ZIP container, streams of data with Non-Codec content types SHOULD be compressed before they are encrypted. Deflate compression MUST be used. This practice ensures that file entries stored in the ZIP container have a smaller size.

Streams of data with Codec content types SHOULD NOT be compressed before they are encrypted. In such cases, additional compression would introduce unnecessary processing overhead at production time (especially with large resource files) and would impact audio/video playback performance at consumption time. In some cases, the combination of compression with some encryption schemes might even compromise the ability of Reading Systems to handle partial content requests (e.g. HTTP byte ranges), due to the technical impossibility to determine the length of the full resource ahead of media playback (e.g. HTTP Content-Length header).

Streams of data that are compressed before they are encrypted SHOULD provide additional EncryptionProperties metadata to specify the size of the initial resource (i.e., before compression and encryption), as per the Compression XML element defined below. Streams of data that are not compressed before they are encrypted MAY provide the additional EncryptionProperties metadata to specify the size of the initial resource (i.e., before encryption).

Element Name

Compression

Namespace

http://www.idpf.org/2016/encryption#compression

Usage

OPTIONAL child of EncryptionProperty.

Attributes
Method [required]

Identifies the compression method used.

Value is either "0" (no compression) or "8" (Deflate algorithm).

OriginalLength [required]

Represents the size of the initial resource (number of bytes).

Value is a positive integer.

Content Model

Empty

6.1.5.2.3 Manifest File (manifest.xml)

The OPTIONAL manifest.xml file in the META-INF directory provides a manifest of files in the Container.

The OCF specification does not mandate a format for the manifest.

Note that Package Documents specify the only manifests used for processing EPUB Publications. Ancillary manifest information contained in the ZIP archive or in the OPTIONAL manifest.xml file MUST NOT be used for processing an EPUB Publication.

Note
This feature exists only for compatibility with [ODF].
6.1.5.2.4 Metadata File (metadata.xml)

The OPTIONAL META-INF/metadata.xml file in the META-INF directory, if present, MUST be used for container-level metadata.

If the metadata.xml file is present, its contents SHOULD be only namespace-qualified elements [XML-NAMES]. The file SHOULD contain the root element metadata in the namespace http://www.idpf.org/2013/metadata, but other root elements are allowed for backwards compatibility. Reading Systems SHOULD ignore metadata.xml files with unrecognized root elements.

This version of the OCF specification does not define metadata for use in the metadata.xml file. Container-level metadata MAY be defined in future versions of this specification and in EPUB extension specifications.

6.1.5.2.5 Rights Management File (rights.xml)

The OPTIONAL rights.xml file in the META-INF directory is reserved for digital rights management (DRM) information for trusted exchange of EPUB Publications among rights holders, intermediaries, and users.

This version of the OCF specification does not require a specific format for DRM information, but a future version might. The contents of the rights.xml SHOULD be only namespace-qualified elements [XML-NAMES] to avoid collision with a future format.

When the rights.xml file is not present, no part of the container is rights governed at the container level. Rights expressions might exist within the EPUB Publications.

If the rights.xml file is not present, no part of the OCF Abstract Container is rights governed.

6.1.5.2.6 Digital Signatures File (signatures.xml)
Note

Adding a digital signature is not a guarantee that an EPUB cannot be tampered with, since Reading Systems are not required to check signatures.

The OPTIONAL signatures.xml file in the META-INF directory holds digital signatures for the container and its contents.

6.1.5.2.6.1 The signatures element
Element Name

signatures

Namespace

urn:oasis:names:tc:opendocument:xmlns:container

Usage

Root element of the signature.xml file.

Attributes

None

Content Model
  • Signature [1 or more]

The signature element contains child elements of type Signature, as defined by [XMLDSIG-CORE1]. Signatures can be applied to an EPUB Publication as a whole or to its parts and can specify the signing of any kind of data (i.e., not just XML).

Note

The content of the signatures.xml file is also defined informally through an XML schema. See § E.2.3 Schema for signatures.xml for further details.

When the signatures.xml file is not present, no part of the container is digitally signed at the container level. Digital signing might exist within the EPUB Publication.

When a data signature is created for the container, the signature SHOULD be added as the last child Signature element of the signatures element.

Note

Each Signature in the signatures.xml file identifies by IRI the data to which the signature applies, using the [XMLDSIG-CORE1] Manifest element and its Reference sub-elements. Individual contained files might be signed separately or together. Separately signing each file creates a digest value for the resource that can be validated independently. This approach might 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, except for the signatures.xml file since that file will contain the computed signature information. Whether and how the signatures.xml file is 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 [XMLDSIG-CORE1] 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 were added to the package.

Note

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 could be used to sign just the existing signatures. The details of such a transform are outside the scope of this specification, however.

The [XMLDSIG-CORE1] specification does not associate any semantics with a signature; an agent might include semantic information, for example, by adding information to the Signature element that describes the signature. The [XMLDSIG-CORE1] specification describes how additional information can be added to a signature, such as by use the SignatureProperties element.

6.2 OCF ZIP Container

6.2.1 Introduction

This section is non-normative.

An OCF ZIP Container is a physical single-file manifestation of an OCF Abstract Container. The Container is used:

  • to exchange in-progress EPUB Publication between different individuals and/or different organizations;

  • to provide EPUB Publications from a publisher or conversion house to the distribution or sales channel; and

  • to deliver EPUB Publications to EPUB Reading Systems or users.

6.2.2 ZIP File Requirements

An OCF ZIP Container uses the ZIP format as specified by [ZIP], but with the following constraints and clarifications:

  •   The contents of the OCF ZIP Container MUST be a conforming OCF Abstract Container.

  •   OCF ZIP Containers MUST NOT use the features in the ZIP application note [ZIP] that allow ZIP files to be spanned across multiple storage media or be split into multiple files.

  •   OCF ZIP Containers MUST include only stored (uncompressed) and Deflate-compressed ZIP entries within the ZIP archive.

  •   OCF ZIP Containers MAY use the ZIP64 extensions defined as "Version 1" in section V, subsection G of the application note [ZIP] and SHOULD use only those extensions when the content requires them.

  •   OCF ZIP Containers MUST NOT use the encryption features defined by the ZIP format; instead, encryption MUST be done using the features described in § 6.1.5.2.2 Encryption File (encryption.xml).

  •   OCF ZIP Containers MUST encode File System Names using UTF-8 [Unicode].

The following constraints apply to specific 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 to match the maximum version level needed by the given file (e.g., 20 if Deflate is needed, 45 if ZIP64 is needed).

  •   In the local file header table, OCF ZIP Containers MUST set the compression method field to the values 0 or 8.

6.2.3 OCF ZIP Container Media Type Identification

The first file in the OCF ZIP Container MUST be the mimetype file, which meets the following requirements:

  • The contents of the mimetype file MUST be the MIME media type [RFC2046] string application/epub+zip encoded in US-ASCII [US-ASCII].
  • The mimetype file MUST NOT contain any leading or trailing padding or white space.
  • The mimetype file MUST NOT begin with the Unicode byte order mark U+FEFF.
  • The mimetype file MUST NOT be compressed or encrypted, and there MUST NOT be an extra field in its ZIP header.
Note

Refer to § G.2 The application/epub+zip Media Type for further information about the application/epub+zip media type.

6.3 Resource Obfuscation

6.3.1 Introduction

This section is non-normative.

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. Moreover, the nature of ZIP files means that their contents might appear like any other native container on some systems (e.g., a folder).

While this simplicity of ZIP files is quite useful, it also poses a problem when ease of extraction of resources is not a desired side-effect of not encrypting them. An EPUB Creator who wishes to include a third-party font, for example, typically does not want that font extracted and re-used by others. More critically, many commercial fonts allow embedding, but embedding a font implies making it an integral part of the EPUB Publication, not just providing the original font file along with the content.

Since integrated ZIP support is so ubiquitous in modern operating systems, simply placing a font in the ZIP archive is insufficient to signify that it is not intended to be reused in other contexts. This uncertainty can undermine the otherwise useful font embedding capability of EPUB Publications.

To discourage reuse of the font, some font vendors might only allow use of their fonts in EPUB Publications if those fonts are bound in some way to the EPUB 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 specification to provide a digital rights management or enforcement system for such resources. This section 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 obfuscated resources.

Note that no claim is made in this specification that this constitutes encryption, nor does it guarantee that the resource will be secure from copyright infringement. It is hoped, however, that this algorithm will meet the requirements of most vendors who require some assurance that their resources cannot simply be extracted by unzipping the Container.

In the case of fonts, the primary use case for obfuscation, the defined mechanism will simply provide a stumbling block for those who are unaware of the license details. 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 method of obfuscation satisfies the requirements of individual font licenses remains a question for the licensor and licensee.

6.3.2 Obfuscation Key

The key used in the obfuscation algorithm is derived from the Unique Identifier.

All white space characters, as defined in section 2.3 of the XML 1.0 specification [XML], MUST be removed from this identifier — specifically, the Unicode code points U+0020, U+0009, U+000D and U+000A.

A SHA-1 digest of the UTF-8 representation of the resulting string SHOULD be generated as specified by the Secure Hash Standard [FIPS-180-4]. This digest is then directly used as the key for the algorithm.

6.3.3 Obfuscation Algorithm

The algorithm employed to obfuscate resource consists of modifying the first 1040 bytes (~1KB) of the file. In the unlikely event that the file is less than 1040 bytes, then the entire file will be modified.

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 obfuscation key is stored as the first byte of the embedded resource.

This process is repeated with the next byte of source and key and continues 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.

Obfuscation of resources MUST occur before they are compressed and added to the OCF Container. Note that as obfuscation is not encryption, this requirement is not a violation of the one in § 6.1.5.2.2 Encryption File (encryption.xml) to compress resources before encrypting them.

To get the original font data back, the process is simply reversed: the source file becomes the obfuscated data, and the destination file will contain the raw data.

Note

The obfuscation of fonts was allowed prior to EPUB 3.0.1, but the order of obfuscation and compression was not specified. As a result, invalid fonts might be encountered after decompression and de-obfuscation. In such instances, de-obfuscating the data before inflating it might return a valid font. This specification does not require support for this method of retrieval, as it is not conforming with this version of this specification, but it needs to be considered when supporting EPUB 3 content generally.

6.3.4 Specifying Obfuscated Resources

Although not technically encrypted data, all obfuscated resources MUST have an entry in the encryption.xml file accompanying the EPUB Publication (see § 6.1.5.2.2 Encryption File (encryption.xml)).

An EncryptedData element MUST be specified for each obfuscated resource. Each EncryptedData element MUST contain a child EncryptionMethod element whose Algorithm attribute is set to the value http://www.idpf.org/2008/embedding. The presence of this attribute signals the use of the algorithm described in this specification. The path to the obfuscated resource MUST be listed in the CipherReference child of the CipherData element.

To prevent trivial copying of the embedded resource to other EPUB Publications, the obfuscation key MUST NOT be provided in the encryption.xml file.

7. Media Overlays

7.1 Introduction

This section is non-normative.

Synchronized audio narration is found in mainstream ebooks, educational tools and ebooks formatted for persons with print disabilities. In EPUB 3, these types of books are created 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 [SMIL3], a W3C recommendation for representing synchronized multimedia information in XML.

The text and audio synchronization enabled by Media Overlays provides enhanced accessibility for any user who has difficulty following the text of a traditional book. Media Overlays also provide a continuous listening experience for readers who are unable to read the text for any reason, something that traditional audio embedding techniques cannot offer. They are even useful for purposes not traditionally considered accessibility concerns (e.g., for language learning).

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 the EPUB Publication as though the Media Overlays are not present.

Media Overlays in EPUB are not an equivalent to audiobooks, as audiobooks are primarily audio-based with text occasionally provided as an alternate format. The W3C [Audiobooks] recommendation is designed for building audio publications.

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

7.2 Media Overlay Documents

7.2.1 Media Overlay Document Requirements

A Media Overlay Document has to meet the following requirements:

7.2.2 Media Overlay Document Definition

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

7.2.2.1 The smil Element

The smil element is 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 [SMIL3] specification to which the Media Overlay adheres.

This attribute MUST have the value "3.0".

id [optional]

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

epub:prefix [optional]

Declares additional metadata vocabulary prefixes.

Refer to § 7.3.3 Structural Semantics in Overlays for more information.

Content Model

In this order:

7.2.2.2 The head Element

The head element is the container for metadata in the Media Overlay Document.

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 does not define any metadata properties that have to occur in the Media Overlay Document, the head element is OPTIONAL.

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

7.2.2.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 white space separated list of property types. Refer to § 7.3.3 Structural Semantics in Overlays for more information.

id [optional]

The ID [XML] of the 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:

At least one par or seq is REQUIRED.

7.2.2.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 white space separated list of property types. Refer to § 7.3.3 Structural Semantics in Overlays for more information.

id [optional]

The ID [XML] of the 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].

Refer to § 7.3.2.1 Overlay Structure for more information.

Content Model

In any order:

At least one par or seq is REQUIRED.

7.2.2.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 white space separated list of property types. Refer to § 7.3.3 Structural Semantics in Overlays for more information.

id [optional]

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

Content Model

In any order:

The audio element is OPTIONAL only if its sibling text element refers to audio or video media (see § 7.3.2.3 Embedded Media), or to textual content intended for rendering via Text-to-Speech (TTS).

7.2.2.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 § 7.3.2.3 Embedded Media).

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 the element, which MUST be unique within the document scope.

Content Model

Empty

7.2.2.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, or to textual content intended for rendering via Text-to-Speech (TTS), in which case it is OPTIONAL (see § 7.3.2.3 Embedded Media).

Attributes
id [optional]

The ID [XML] of the 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 Type Resources table.

clipBegin [optional]

A clock value that specifies the offset into the physical media corresponding to the start point of an audio clip.

MUST be a [SMIL3] clock value.

See § F.3 Clock Values.

clipEnd [optional]

A clock value that specifies the offset into the physical media corresponding to the end point of an audio clip.

MUST be a [SMIL3] clock value.

See § F.3 Clock Values.

The chronological offset of the terminating position MUST be after the starting offset specified in the clipBegin attribute.

Content Model

Empty

7.3 Creating Media Overlays

7.3.1 Introduction

This section is non-normative.

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 [SMIL3] 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 § 7.2.2 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.

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.

par elements can also be added to seq elements to define more complex structures such as parts and chapters (see § 7.3.2.1 Overlay Structure).

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

7.3.2.1 Overlay Structure

The body of a Media Overlay Document consists of two elements: the par element and the seq element. The ordering of these elements represents how the content in the corresponding EPUB Content Documents is rendered during playback.

The par element represents phrases. Each element identifies a text and audio component to synchronize during playback.

The seq element represents sequences. It is used to represent nested containers such as sections, asides, headers, and footnotes. It allows the structure inherent in these containers to be retained in the Media Overlay Document.

The seq element MUST contain an epub:textref attribute. The IRI [RFC3987] value of this attribute MUST reference the corresponding structural element in an EPUB Content Document. As seq elements do not provide synchronization instructions, this attribute allows a Reading System to still match the element to a location in the text.

The following example shows a Media Overlay Document with nested seq elements, representing a chapter with both a section header and a 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>

            <!-- a figure -->
            <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>

            <!-- more sentences in the chapter (outside the figure) -->
            <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>
Note

The reason for grouping structures like sections, 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 content, such as jumping past a long figure, turning off rendering of page break announcements (see § 7.4 Skippability and Escapability), or customizing the reading mode to suit structures such as tables.

7.3.2.2 Overlay Granularity

This section is non-normative.

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

7.3.2.3 Embedded Media

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, the audio sibling element is OPTIONAL.

EPUB Creators SHOULD avoid using scripts to control playback of referenced embedded EPUB Content Document media, as this might conflict with Media Overlays playback behavior.

7.3.2.4 Text-to-Speech Rendering

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

7.3.3 Structural Semantics in Overlays

To express structural semantics in Media Overlay Documents, the epub:type attribute MAY be specified on par, seq, and body elements.

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 [EPUB-RS-33].

Media Overlays MAY use the applicable vocabulary association mechanisms for the epub:type attribute to define additional semantics.

7.3.4 Associating Style Information

Visual rendering information for the currently playing EPUB Content Document element MAY be expressed in the CSS Style Sheet using author-defined classes.

When used, the author-defined class names MUST be declared in the Package Document using the active-class and playback-active-class properties.

EPUB Creators MUST define exactly one CSS class name in each property they define. Each property MUST define a valid CSS class name not including any selectors [CSS2]. This specification does not reserve names for use with these properties.

EPUB Creators MAY define any CSS properties for the specified CSS classes. EPUB Creators only need to ensure that each EPUB Content Document with an associated Media Overlay Document includes a link to the CSS style sheet that contains the class definitions. Reading Systems might provide their own styling, or no styling at all, in the absence of a linked definition.

The active-class and playback-active-class properties MUST NOT be used in conjunction with a refines attribute as they are always considered to apply to the entire EPUB Publication.

7.3.5 Media Overlays Packaging

7.3.5.1 Including Media Overlays

If an EPUB Content Document is wholly or partially referenced by a Media Overlay, then its manifest item element MUST specify a media-overlay attribute. The attribute MUST reference the ID [XML] of the manifest item for the corresponding Media Overlay Document.

The media-overlay attribute MUST only be specified on manifest item elements that reference EPUB Content Documents.

Manifest items for Media Overlay Documents MUST have the media type application/smil+xml.

7.3.5.2 Overlays Package Metadata

The Package Document MUST specify the duration of the entire EPUB Publication in a meta element with the duration property.

In addition, the duration of each Media Overlay Document MUST be provided. The refines attribute is used to associate each duration declaration to the corresponding manifest item.

The sum of the durations for each Media Overlay Document SHOULD equal the total duration.

EPUB Creators also MAY specify narrator information in the Package Document, as well as author-defined CSS class names to be applied to the currently playing EPUB Content Document element.

Note

The prefix media: is reserved by for the inclusion of these properties in package metadata.

7.4 Skippability and Escapability

7.4.1 Skippability

While reading, users might want to turn on or off certain features of the content, such as footnotes, page numbers, or other types of secondary content. This feature is called skippability. Reading Systems use the semantic information provided by Media Overlay elements' epub:type attribute to determine when to offer users the option of skippable features.

The following non-exhaustive list represents terms from the Structural Semantics Vocabulary for which Reading Systems might offer the option of skippability:

  • footnote

  • endnote

  • pagebreak

Note

Reading System are not required to support for skippability based on epub:type values.

7.4.2 Escapability

Escapable items are nested structures, such as tables and lists, that users might 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).

The following non-exhaustive list represents terms from the Structural Semantics Vocabulary for which Reading Systems might offer the option of escapability:

  • table

  • table-row

  • table-cell

  • list

  • list-item

  • figure

7.5 Navigation Document Overlays

The EPUB Navigation Document is an XHTML Content Document and can therefore be associated with an audio Media Overlay. Unlike traditional XHTML Content Documents, however, Reading Systems have to present the EPUB Navigation Document to users even when it is not included in the spine (see Navigation Document Processing [EPUB-RS-33]). As a result, the method in which an associated Media Overlay behaves can change depending on the context:

Note

Specific implementation details are beyond the scope of this specification. The DAISY Media Overlays Playback Requirements document describes best practices for EPUB Creators and provides recommendations for Reading System developers.

8. Security and Privacy

Editor's note

This is a very initial draft intended only as a starting point. It is inspired by the relevant section of the Publication Manifest specification. It will require more work.

The particularity of an EPUB Publication is its structure. The EPUB format provides a means of representing, packaging, and encoding structured and semantically enhanced Web content — including HTML, CSS, SVG, and other resources — for distribution in a single-file container. This specification does not add any new features, APIs, etc. This also means that, essentially, the security and privacy issues are reliant on the features of those formats. In particular:

Editor's note

The Working Group will have to address the particularity of cross-origin by addressing the question of what the "origin" is for an EPUB Publication.

A. Unsupported Features

This specification and its siblings contain certain features that are no longer recommended for use or that are only retained for legacy support reasons. This section defines the meanings of the designations attached to these features and the support expectations for such features.

A.1 Deprecated Features

A deprecated feature is one that is no longer recommended for use in this version of the specification. Deprecated features typically have had limited or no support in Reading Systems and/or usage in EPUB Publications. If a feature is marked as deprecated, the following hold true:

Validation tools SHOULD alert EPUB Creators that inclusion of the feature is deprecated when encountered in an EPUB Publication.

A.2 Legacy Features

A legacy feature is one that is retained only for authoring content that is compatible with versions of EPUB prior to 3.0. If a feature is marked as legacy, the following hold true:

Validation tools SHOULD NOT alert EPUB Creators about the presence of legacy features in an EPUB Publication, as their inclusion is valid for backwards compatibility. Validation tools MUST alert EPUB Creators if a legacy feature does not conform to its definition or otherwise breaks a usage requirement.

B. Allowed External Identifiers

The following table lists the public and system identifiers [XML] allowed in document type declarations. [XML]

These external identifiers MAY be used only in Publication Resources with the listed media types specified in their manifest declarations. (Refer to § 2.2.4 XML Conformance for more information.)

Media Type(s) Public Identifier System Identifier
  • application/mathml+xml
  • application/mathml-presentation+xml
  • application/mathml-content+xml
-//W3C//DTD MathML 3.0//EN http://www.w3.org/Math/DTD/mathml3/mathml3.dtd
application/svg+xml -//W3C//DTD SVG 1.1//EN http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd

C. Expressing Structural Semantics

C.1 Introduction

Structural semantics add additional meaning about the specific structural purpose an element plays. The epub:type attribute is used to express domain-specific semantics in EPUB Content Documents and Media Overlay Documents, with the structural information it carries complementing the underlying vocabulary.

The applied semantics are intended to refine the meaning of their containing elements; they are not provided to override their nature (e.g., the attribute can be used to indicate a [HTML] section is a chapter in a work, but is not designed to turn p elements into list items to avoid proper list structures).

Semantic metadata is intended to enrich content for use in publishing workflows and for author-defined purposes. It also allows Reading Systems to learn more about the structure and content of a document (e.g., to enable skippability and escapability in Media Overlays).

This specification defines a method for adding structural semantics using the attribute axis: instead of adding new elements, the epub:type attribute can be appended to existing elements to add the desired semantics.

C.2 The epub:type Attribute

Attribute Name

type

Namespace

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

Usage

Global attribute. MAY be specified on all elements.

Value

A white space-separated list of property values, with restrictions as defined in § D.1 Vocabulary Association Mechanisms.

White space is the set of characters as defined in [XML].

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

The inflected semantic MUST express a subclass of the semantic of the carrying element. In the case of semantically neutral elements, such as the [HTML] div and span elements, 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).

Note

Although the epub:type attribute is similar in nature to the role attribute [HTML], the attributes serve different purposes. The values of the epub:type attribute do not enhance the accessibility of EPUB Publications, for example, they do not map to accessibility APIs used by assistive technologies. The epub:type attribute is only intended for publishing semantics and Reading System enhancements. Refer to Digital Publishing WAI-ARIA Module 1.0 [DPUB-ARIA-1.0] for more information about accessible publishing roles.

The default vocabulary for the epub:type attribute is the Structural Semantics Vocabulary. Unprefixed terms that are not part of this vocabulary MAY be included, but their use is discouraged. The use of prefixes is the preferred method for adding custom semantics. Refer to § D.1 Vocabulary Association Mechanisms for more information.

D. Vocabularies

This appendix defines a general set of mechanisms by which attributes in this specification can reference terms from vocabularies, as well as EPUB-specific vocabularies that are used with the attributes.

D.1 Vocabulary Association Mechanisms

D.1.1 Introduction

EPUB defines a formal method of referencing terms and properties defined in metadata and semantic vocabularies using the property data type. The epub:type attribute uses this data type in EPUB Content Documents and Media Overlay Documents to add structural semantics, for example, while the property and rel attributes use the data type to define properties and relationships in the Package Document.

A property value is like a CURIE [RDFA-CORE] — it represents an IRI [RFC3987] in compact form. The expression 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 reduce the complexity for authoring, each attribute that takes a property data type also defines a default vocabulary. Terms and properties referenced from the default vocabularies do not include a prefix as the mapping Reading Systems use to map to a IRI is predefined.

The power of the property data type lies in its easy extensibility. To incorporate new terms and properties, EPUB Creators only need to declare a prefix. In another authoring convenience, this specification also reserves prefixes for many commonly used publishing vocabularies (i.e., they do not have to be declared).

Additional details on the property data type and vocabulary association mechanism are provided in the following sections.

D.1.2 The property Data Type

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)
All terminal symbols are in the Unicode Block 'Basic Latin' (U+0000 to U+007F).
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 [RDFA-CORE] and represents a subset of CURIEs.

After processing [EPUB-RS-33], 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 a property value, the expressed reference represents a term from the default vocabulary for that attribute.

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

D.1.3 Default Vocabularies

A default vocabulary is one that does not require a prefix to be declared to use its terms and properties where a property value is expected. Terms and properties from a default vocabulary MUST always be unprefixed.

The IRIs associated with these vocabularies MUST NOT be assigned a prefix using the prefix attribute.

Note

Refer to the definition of each attribute that takes a property data type for more information about its default vocabulary.

D.1.4 The prefix Attribute

The prefix attribute defines prefix mappings for use in property values.

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

(EBNF productions ISO/IEC 14977)
All terminal symbols are in the Unicode Block 'Basic Latin' (U+0000 to U+007F).
prefixes = mapping , { whitespace, { whitespace } , mapping } ;  
mapping = prefix , ":" , space , { space } , ? xsd:anyURI ? ;  
prefix = ? xsd:NCName ? ;  
space = #x20 ;  
whitespace = (#x20 | #x9 | #xD | #xA) ;  

The prefix attribute MUST only be specified on the root element of the respective format.

The attribute is not namespaced when used in the Package Document.

The attribute MUST be declared in the namespace http://www.idpf.org/2007/ops when declared in EPUB Content Documents and Media Overlay Documents.

Note

Although the prefix attribute is modeled on the identically named prefix attribute in [RDFA-CORE], EPUB Creators cannot use the attributes interchangeably. The prefix attribute without a namespace in EPUB Content Documents is the RDFa attribute.

It is common for both attributes to appear in EPUB Content Documents that also specify RDFa expressions.

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

Note that for embedded SVG, prefixes MUST be declared on the [HTML] root html element.

To avoid conflicts, the prefix attribute MUST NOT be used to declare a prefix that maps to the default vocabulary.

The prefix '_' MUST NOT be declared as it is reserved for future compatibility with RDFa [RDFA-CORE] processing.

For future compatibility with alternative serializations of the Package Document, a prefix for the Dublin Core /elements/1.1/ namespace [DCTERMS] MUST NOT be declared in the prefix attribute. EPUB Creators MUST use only the [DC11] elements allowed in the Package Document metadata.

D.1.5 Reserved Prefixes

Warning

Although reserved prefixes are an authoring convenience, reliance on them can lead to interoperability issues. Validation tools will often reject new prefixes until the tools are updated, for example. EPUB Creators are strongly encouraged to declare all prefixes they use to avoid such issues.

EPUB Creators MAY use reserved prefixes in attributes that expect a property value without declaring them in a prefix attribute.

Reserved prefixes SHOULD NOT be overridden in the prefix attribute.

The reserved prefixes available for use is context dependent:

Package Document

EPUB Creators MAY use the following prefixes in Package Document attributes without having to declare them.

Prefix IRI
a11y http://www.idpf.org/epub/vocab/package/a11y/#
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#
rendition http://www.idpf.org/vocab/rendition/#
schema http://schema.org/
xsd http://www.w3.org/2001/XMLSchema#
Structural Semantics

EPUB Creators MAY use the following reserved prefixes in the epub:type attribute without having to declare them.

Prefix IRI
msv http://www.idpf.org/epub/vocab/structure/magazine/#
prism http://www.prismstandard.org/specifications/3.0/PRISM_CV_Spec_3.0.htm#

D.2 Meta Properties Vocabulary

The properties in this vocabulary are usable in the meta element's property attribute.

Unless indicated otherwise in its "Extends" field, the properties defined in this section are used to define subexpressions: in other words, a meta element carrying a property defined in this section MUST have a refines attribute referencing a resource or expression being augmented.

In each property definition, the Allowed values field indicates the expected type of value (using [XMLSCHEMA-2] datatypes), the Cardinality field indicates the number of times the property MAY be attached to another property, and the Extends field identifies the properties it MAY be attached to.

Properties without a prefix are referenceable using the base IRI http://idpf.org/epub/vocab/package/meta/#.

D.2.1 alternate-script

Name: 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: zero or more
Extends: All properties.

D.2.2 authority

Name: authority
Description:

The authority property identifies the system or scheme the referenced element's value is drawn from.
Allowed value(s):
Cardinality: zero or one
Extends: subject

D.2.3 belongs-to-collection

Name: belongs-to-collection
Description:

The belongs-to-collection property identifies the name of a collection to which the EPUB Publication belongs. An EPUB Publication MAY belong to one or more collections.

It is also possible chain these properties using the refines attribute to indicate that one collection is itself a member of another collection.

To allow Reading System to organize collections and avoid naming collisions (e.g., unrelated collections might share a similar name, or different editions of a collection could be released), an identifier SHOULD be provided that uniquely identifies the instance of the collection. The dcterms:identifier property must carry this identifier.

The collection MAY more precisely define its nature by attaching a collection-type property.

The position of the EPUB Publication within the collection MAY be provided by attaching a group-position property.
Allowed value(s): xsd:string
Cardinality: zero or more
Extends: Applies to the EPUB Publication and can refine other instances of itself.

D.2.4 collection-type

Name: collection-type
Description:

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

When the collection-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 collection type values:

series

A sequence of related works that are formally identified as a group, typically open-ended with works issued individually over time.

set

A finite collection of works that together constitute a single intellectual unit, typically issued together and able to be sold as a unit.
Allowed value(s): xsd:string
Cardinality: zero or one
Extends: belongs-to-collection

D.2.5 display-seq

Name: display-seq
Description:

The display-seq property indicates the numeric position in which to display the current property relative to identical metadata properties.

This property only applies where precedence rules have not already been defined (e.g., precedence is given to creators based on their appearance in document order).
Allowed value(s): xsd:unsignedInt
Cardinality: zero or one
Extends: All properties.

D.2.6 file-as

Name: file-as
Description: The file-as property provides the normalized form of the associated property for sorting.
Allowed value(s): xsd:string
Cardinality: zero or one
Extends: All properties.

D.2.7 group-position

Name: group-position
Description:

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

The group-position property can be attached to any metadata property that establishes the group but is typically associated with the belongs-to-collection property.

An EPUB 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: zero or one
Extends: All properties.

D.2.8 identifier-type

Name: 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
Cardinality: zero or one
Extends: identifier, source

D.2.9 meta-auth (Deprecated)

Use of the meta-auth property is deprecated.

For more information about this property, refer its definition in [EPUBPublications-30].

D.2.10 role

Name: role
Description:

The role property describes the role of a creator, contributor or publisher in the creation of an EPUB Publication.

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

When attaching multiple roles to an individual or organization, the importance of the roles should match the document order of their containing meta elements (i.e., the first meta element encountered should contain the most important role).
Allowed value(s): xsd:string
Cardinality: zero or more
Extends: contributor, creator, publisher

D.2.11 source-of

Name: source-of
Description:

The source-of property indicates a unique aspect of an adapted source resource that has been retained in the EPUB Publication.

This specification defines the pagination value to indicate that the referenced dc:source element is the source of the pagebreak properties defined in the content.
Allowed value(s): pagination
Cardinality: zero or one
Extends: dc:source
Note

See [EPUB-A11Y-TECH-11] for information on how to provide accessible page navigation.

D.2.12 term

Name: term
Description:

The term property provides a subject code.
Allowed value(s): xsd:string
Cardinality: zero or one
Extends: subject

D.2.13 title-type

Name: 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
Cardinality: zero or one
Extends: title

D.2.14 Examples

D.4 Package Rendering Vocabulary

Not all rendering information can be expressed through the underlying technologies that EPUB is built upon. For example, although HTML with CSS provides powerful layout capabilities, those capabilities are limited to the scope of the document being rendered.

This section defines general-purpose properties that allow EPUB Creators to express package-level rendering intentions (i.e., functionality that can only be implemented by the EPUB Reading System). If a Reading System supports the desired rendering, these properties enable the user to be presented the content as the EPUB Creator optimally designed it.

The base IRI for referencing these properties is http://www.idpf.org/vocab/rendition/#.

The "rendition:" prefix is reserved for use with the package rendering properties and does not have to be declared in the Package Document.

D.4.1 General Properties

D.4.1.1 The rendition:flow Property

The rendition:flow property specifies the EPUB Creator preference for how Reading Systems should handle content overflow.

When the rendition:flow property is specified on a meta element, it indicates the EPUB Creator's global preference for overflow content handling (i.e., for all spine items). EPUB Creators MAY indicate a preference for dynamic pagination or scrolling. For scrolled content, it is also possible to specify whether consecutive EPUB Content Documents are to be rendered as a continuous scrolling view or whether each is to be rendered separately (i.e., with a dynamic page break between each).

The following values are defined for use with the rendition:flow property:

paginated

Dynamically paginate all overflow content.

scrolled-continuous

Render all Content Documents such that overflow content is scrollable, and the EPUB Publication is presented as one continuous scroll from spine item to spine item (except where locally overridden).

Note that EPUB Creators SHOULD NOT create publications in which different resources have different block flow directions, as continuous scrolled rendition in EPUB Reading Systems would be problematic.

scrolled-doc

Render all Content Documents such that overflow content is scrollable, and each spine item is presented as a separate scrollable document.

auto

Render overflow content using the Reading System default method or a user preference, whichever is applicable. Default value.

Note that when two reflowable EPUB Content Documents occur sequentially in the spine, the default rendering for their [HTML] body elements is consistent with the page-break-before property [CSSSnapshot] having been set to always. In addition to using the rendition:flow property, EPUB Creators MAY override this behavior through an appropriate style sheet declaration, if the Reading System supports such overrides.

The rendition:flow property MUST NOT be declared more than once.

D.4.1.1.1 Spine Overrides

EPUB Creators MAY specify the following properties locally on spine itemref elements to override the global value for the given spine item:

flow-auto
Indicates no preference for overflow content handling by the EPUB Creator.
flow-paginated
Indicates the EPUB Creator preference is to dynamically paginate content overflow.
flow-scrolled-continuous
Indicates the EPUB Creator preference is to provide a scrolled view for overflow content, and that consecutive spine items with this property are to be rendered as a continuous scroll.
flow-scrolled-doc
Indicates the EPUB Creator preference is to provide a scrolled view for overflow content, and each spine item with this property is to be rendered as a separate scrollable document.

Only one of these overrides is allowed on any given spine item.

D.4.1.2 The rendition:align-x-center Property

The rendition:align-x-center property specifies that the given spine item should be centered horizontally in the viewport or spread.

The property cannot be set globally for all EPUB Content Documents. It is only available as a spine override for individual EPUB Content Documents via the itemref element's properties attribute.

Note

This property was developed primarily to handle "Naka-Tobira (中扉)" (sectional title pages), in the absence of reliable centering control within the content rendering. As support for paged media evolves in CSS, however, this property is expected to be deprecated. EPUB Creators are encouraged to use CSS solutions when effective.

D.4.2 Fixed-Layout Properties

The following properties belong to the Package Rendering Vocabulary. Refer to their respective definitions in § 5. Fixed Layouts for the details of their use.

Properties Defined in
  • rendition:layout
  • rendition:layout-pre-paginated
  • rendition:layout-reflowable
 § 5.2.1 Layout
  • rendition:orientation
  • rendition:orientation-auto
  • rendition:orientation-landscape
  • rendition:orientation-portrait
 § 5.2.2 Orientation
  • rendition:spread
  • rendition:spread-auto
  • rendition:spread-both
  • rendition:spread-landscape
  • rendition:spread-none
  • rendition:spread-portrait
 § 5.2.3 Synthetic Spreads
  • rendition:page-spread-center
  • rendition:page-spread-left
  • rendition:page-spread-right
 § 5.2.4 Spread Placement
  • rendition:viewport
 § 5.2.5 Viewport Dimensions (Deprecated)

D.5 Manifest Properties Vocabulary

The properties in this vocabulary are usable in the manifest item element's 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.

Properties without a prefix are referenceable using the base IRI http://idpf.org/epub/vocab/package/item/#.

D.5.1 cover-image

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

D.5.2 mathml

Name: 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 the description is met.

D.5.3 nav

D.5.4 remote-resources

Name: 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 § 2.2.2 Resource Locations for more information.
Applies to: All Publication Resources with the capability of internal referencing (e.g., XHTML Content Documents, SVG Content Documents, CSS Style Sheets and Media Overlay Documents).
Cardinality: Zero or more
Usage: MUST be set if and only if the criterion specified in the description is met.

D.5.5 scripted

Name: scripted
Description: The scripted property indicates that the described Publication Resource is a Scripted Content Document (i.e., contains scripted content and/or HTML form elements).
Applies to: EPUB Content Documents
Cardinality: Zero or more
Usage: MUST be set if and only if the criterion specified in the description is met.

D.5.6 svg

Name: svg
Description:

The svg property indicates that the described Publication Resource embeds one or more instances of SVG markup.

This property MUST be set when SVG markup is included directly in the resource and MAY be set when the SVG is referenced from the resource (e.g., from an [HTML] img, object or iframe element).
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 the description is met.

D.5.7 switch

Name: 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 the description is met.

D.5.8 Usage

The mathml, remote-resources, scripted 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 HTML 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.

D.5.9 Examples

Figure 1 The following example shows a manifest item element that represents the EPUB Navigation Document.
<item properties="nav" id="c1" href="c1.xhtml" media-type="application/xhtml+xml" />
Figure 2 The following example shows a manifest item element that represents the cover image.
<item properties="cover-image" id="ci" href="cover.svg" media-type="image/svg+xml" />
Figure 3 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" />

D.6 Spine Properties Vocabulary

The properties in this vocabulary are usable in the spine itemref element's properties attribute.

Properties are referenceable using the base IRI http://idpf.org/epub/vocab/package/itemref/#.

D.6.1 page-spread-left

Name: page-spread-left
Description: The page-spread-left property indicates that the first page of the associated item element's EPUB Content Document represents the left-hand side of a two-page spread.

D.6.2 page-spread-right

Name: page-spread-right
Description: The page-spread-right property indicates that the first page of the associated item element's EPUB Content Document represents the right-hand side of a two-page spread.

D.6.3 Examples

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

D.7 Media Overlays Vocabulary

The properties in this vocabulary are usable in the meta element's property attribute.

The base IRI for referencing this vocabulary is http://www.idpf.org/epub/vocab/overlays/#.

The prefix "media:" is reserved for use with properties in this vocabulary and does not have to be declared in the Package Document.

D.7.1 active-class

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

D.7.2 duration

Name: 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):

MUST be a [SMIL3] clock value.
Cardinality: Exactly one for the EPUB Publication and for each Media Overlay.
Example: <meta property="media:duration">1:36:20</meta>

D.7.3 narrator

Name: narrator
Description: Name of the narrator.
Allowed value(s): xsd:string
Cardinality: Zero or more
Example: <meta property="media:narrator">Joe Speaker</meta>

D.7.4 playback-active-class

Name: playback-active-class
Description: Author-defined CSS class name to apply to the EPUB Content Document's document element when playback is active.
Allowed value(s): xsd:string
Cardinality: Zero or one
Example: <meta property="media:playback-active-class">-epub-media-overlay-playing</meta>

D.8 Structural Semantics Vocabulary

D.8.1 About this Vocabulary

This section is non-normative.

While the EPUB Structural Semantics vocabulary is generally host language agnostic, it has been constructed primarily to enable semantic inflection of elements in the HTML vocabulary.

The HTML usage context fields indicate contexts in HTML documents where the given property is considered relevant. EPUB Creators may use the properties on HTML markup elements not specifically listed, but must ensure that the semantics they express represent a subset of the carrying element's semantics and do not attach an existing element's meaning to a semantically neutral element.

The DPUB-ARIA role fields indicate the [DPUB-ARIA-1.0] roles that can alternatively be used with the [HTML] role attribute to improve accessibility. These roles may have more restrictive usage contexts, however, so may not be valid wherever the epub:type attribute is used. Refer to [HTML-ARIA] for more information about where the roles are allowed.

When processing HTML documents, Reading Systems may ignore such non-compliant properties, unless their usage context is explicitly overridden or extended by the host specification.

The Usage Details sections identify IDPF specifications that define or utilize the specified properties.

D.8.2 Document Partitions

cover

A section that introduces the work, often consisting of a marketing image, the title, author, and publisher, and select quotes and reviews.

HTML usage context: section, body

DPUB-ARIA role: doc-cover (only allowed on cover image tag)

frontmatter

Preliminary material to the main content of a publication, such as tables of contents, dedications, etc.

HTML usage context: section, body

bodymatter

The main content of a publication.

HTML usage context: section, body

backmatter

Ancillary material occurring after the main content of a publication, such as indices, appendices, etc.

HTML usage context: section, body

D.8.3 Document Divisions

volume

A component of a collection.

HTML usage context: section, body

part

A major structural division in a work that contains a set of related sections dealing with a particular subject, narrative arc, or similar encapsulated theme.

HTML usage context: section, body

DPUB-ARIA role: doc-part

chapter

A major thematic section of content in a work.

HTML usage context: section, body

DPUB-ARIA role: doc-chapter

subchapter [deprecated]

A major sub-division of a chapter.

HTML usage context: section, body

division

A major structural division that may also appear as a substructure of a part (esp. in legislation).

HTML usage context: section, body

D.8.4 Document Sections and Components

Sections and components that typically occur in the publication bodymatter.

abstract [draft]

A short summary of the principle ideas, concepts, and conclusions of the work, or of a section or excerpt within it.

HTML usage context: section, grouping content

DPUB-ARIA role: doc-abstract

foreword

An introductory section that precedes the work, typically not written by the author of the work.

HTML usage context: section, grouping content

DPUB-ARIA role: doc-foreword

preface

An introductory section that precedes the work, typically written by the author of the work.

HTML usage context: section, grouping content

DPUB-ARIA role: doc-preface

prologue

An introductory section that sets the background to a work, typically part of the narrative.

HTML usage context: section, grouping content

DPUB-ARIA role: doc-prologue

introduction

A preliminary section that typically introduces the scope or nature of the work.

HTML usage context: section, grouping content

DPUB-ARIA role: doc-introduction

preamble

A section in the beginning of the work, typically containing introductory and/or explanatory prose regarding the scope or nature of the work's content

HTML usage context: section, grouping content

conclusion

A concluding section or statement that summarizes the work or wraps up the narrative.

HTML usage context: section, grouping content

DPUB-ARIA role: doc-conclusion

epilogue

A concluding section of narrative that wraps up or comments on the actions and events of the work, typically from a future perspective.

HTML usage context: section, grouping content

DPUB-ARIA role: doc-epilogue

afterword

A closing statement from the author or a person of importance, typically providing insight into how the content came to be written, its significance, or related events that have transpired since its timeline.

HTML usage context: section, grouping content

DPUB-ARIA role: doc-afterword

epigraph

A quotation set at the start of the work or a section that establishes the theme or sets the mood.

HTML usage context: section, grouping content

DPUB-ARIA role: doc-epigraph

D.8.6 Document Reference Sections

appendix

A section of supplemental information located after the primary content that informs the content but is not central to it.

HTML usage context: sectioning content

DPUB-ARIA role: doc-appendix

colophon

A short section of production notes particular to the edition (e.g., describing the typeface used), often located at the end of a work.

HTML usage context: sectioning content, grouping content

DPUB-ARIA role: doc-colophon

credits [draft]

A collection of credits.

HTML usage context: sectioning content, grouping content

DPUB-ARIA role: doc-credits

keywords [draft]

A collection of keywords.

HTML usage context: sectioning content, grouping content

Indexes

index

A navigational aid that provides a detailed list of links to key subjects, names and other important topics covered in the work.

HTML usage context: sectioning content, body

Usage details: EPUB Indexes – index property

DPUB-ARIA role: doc-index

index-headnotes

Narrative or other content to assist users in using the index.

Required parent context: index

HTML usage context: sectioning content, header

Usage details: EPUB Indexes – index-headnotes property

index-legend

List of symbols, abbreviations or special formatting used in the index, and their meanings.

Required parent context: index-headnotes

HTML usage context: sectioning content, dl

Usage details: EPUB Indexes – index-legend property

index-group

Collection of consecutive main entries that share a common characteristic, for example the starting letter of the main entries.

Required parent context: index

HTML usage context: sectioning content

Usage details: EPUB Indexes – index-group property

index-entry-list

Collection of consecutive main entries or subentries.

Required parent context: index-entry , index-group, and index

HTML usage context: ul; this property is implied when the ul has an ancestor of index except within index-headnotes

Usage details: EPUB Indexes – index-entry-list property

index-entry

One term with any attendant subentries, locators, cross references, and/or editorial note.

Required parent context: index-entry-list

HTML usage context: li; this property is implied when parent ul is of type index-entry-list (implicit or explicit)

Usage details: EPUB Indexes – index-entry property

index-term

Word, phrase, string, glyph, or image representing the indexable content.

Required parent context: index-xref-related , index-entry and index-xref-preferred

HTML usage context: phrasing content; typically span

Usage details: EPUB Indexes – index-term property

index-editor-note

Editorial note pertaining to a single entry.

Required parent context: index-entry

HTML usage context: flow content

Usage details: EPUB Indexes – index-editor-note property

index-locator

A reference to an occurrence of the indexed content in the publication.

Required parent context: index-entry , index-locator-list , and index-locator-range

HTML usage context: a; this property is implied when parent context is index-locator-list or index-locator-range

Usage details: EPUB Indexes – index-locator property

index-locator-list

Collection of sequential locators or locator ranges.

Required parent context: index-entry

HTML usage context: ul

Usage details: EPUB Indexes – index-locator-list property

index-locator-range

A pair of locators that connects a term to a range of content rather than a single point.

Required parent context: index-locator-list and index-entry

HTML usage context: flow content

Usage details: EPUB Indexes – index-locator-range property

index-xref-preferred

Reference from one term to one or more preferred terms or term categories in an index (analogous to "See xxx").

Required parent context: index-entry

HTML usage context: flow content

Usage details: EPUB Indexes – index-xref-preferred property

Reference from one term to one or more related terms or term categories in an index (analogous to "See also xxx").

Required parent context: index-entry

HTML usage context: flow content

Usage details: EPUB Indexes – index-xref-related property

index-term-category

Word, phrase, string, glyph, or image representing a category of terms in the index.

Required parent context: index-xref-related and index-xref-preferred

HTML usage context: a

Usage details: EPUB Indexes – index-term-category property

index-term-categories

Wrapper for a list of the term categories belonging to an index.

Required parent context: index-xref-related and index-xref-preferred

HTML usage context: a

Usage details: EPUB Indexes – index-term-categories property

Glossaries

glossary

A brief dictionary of new, uncommon, or specialized terms used in the content.

HTML usage context: dl, sectioning content

DPUB-ARIA role: doc-glossary

glossterm

A glossary term.

Required parent context: glossary

HTML usage context: The glossterm property is implied on dt elements within a dl element marked with the glossary property.

glossdef

The definition of a term in a glossary.

Required parent context: glossary

HTML usage context: The glossdef property is implied on dd elements within a dl element marked with the glossary property.

Bibliographies

bibliography

A list of external references cited in the work, which may be to print or digital sources.

HTML usage context: sectioning content

DPUB-ARIA role: doc-bibliography

biblioentry

A single reference to an external source in a bibliography. A biblioentry typically provides more detailed information than its reference(s) in the content (e.g., full title, author(s), publisher, publication date, etc.).

Required parent context: bibliography

HTML usage context: grouping content

DPUB-ARIA role: doc-biblioentry (Deprecated)

D.8.7 Preliminary Sections and Components

Preliminary sections and components, typically occurring in the publication frontmatter.

titlepage

The title page of the work.

HTML usage context: section, grouping content

halftitlepage

The half title page of the work.

HTML usage context: section, grouping content

copyright-page

The copyright page of the work.

HTML usage context: section, grouping content

seriespage [draft]

Marketing section used to list related publications.

HTML usage context: section, grouping content

acknowledgments

A section or statement that acknowledges significant contributions by persons, organizations, governments, and other entities to the realization of the work.

HTML usage context: section, grouping content

DPUB-ARIA role: doc-acknowledgments

imprint

Information relating to the publication or distribution of the work.

HTML usage context: section, grouping content

imprimatur

A formal statement authorizing the publication of the work.

HTML usage context: section, grouping content

contributors

A list of contributors to the work.

HTML usage context: section, grouping content

other-credits

Acknowledgments of previously published parts of the work, illustration credits, and permission to quote from copyrighted material.

HTML usage context: section, grouping content

errata

A set of corrections discovered after initial publication of the work, sometimes referred to as corrigenda.

HTML usage context: section, aside, grouping content

DPUB-ARIA role: doc-errata

dedication

An inscription at the front of the work, typically addressed in tribute to one or more persons close to the author.

HTML usage context: section, grouping content

DPUB-ARIA role: doc-dedication

revision-history

A record of changes made to a work.

HTML usage context: section, grouping content

D.8.8 Complementary Content

case-study [draft]

A detailed analysis of a specific topic.

Inherits from: xhv:complementary

HTML usage context: sectioning content

help [deprecated]

Helpful information that clarifies some aspect of the content or assists in its comprehension.

Inherits from: xhv:complementary

HTML usage context: aside, phrasing content

Replaced by: tip

marginalia [deprecated]

Content, both textual and graphical, that is offset in the margin.

Inherits from: xhv:complementary

HTML usage context: aside, phrasing content

Replaced by: aside

notice

Notifies the user of consequences that might arise from an action or event. Examples include warnings, cautions and dangers.

HTML usage context: section, grouping content

DPUB-ARIA role: doc-notice

pullquote [draft]

A distinctively placed or highlighted quotation from the current content designed to draw attention to a topic or highlight a key point.

Inherits from: xhv:complementary

HTML usage context: aside

DPUB-ARIA role: doc-pullquote

Secondary or supplementary content, typically formatted as an inset or box.

Inherits from: xhv:complementary

HTML usage context: aside

Replaced by: aside

tip

Helpful information that clarifies some aspect of the content or assists in its comprehension.

Inherits from: xhv:complementary

HTML usage context: aside, phrasing content

DPUB-ARIA role: doc-tip

warning [deprecated]

A warning.

HTML usage context: section, grouping content

Replaced by: notice

D.8.9 Titles and Headings

halftitle

The title appearing on the first page of a work or immediately before the text.

Inherits from: title

HTML usage context: heading content. This property should only appear once within the document scope.

fulltitle

The full title of the work, either simple, in which case it is identical to title, or compound, in which case it consists of a title and a subtitle.

Inherits from: title

Same as: http://purl.org/dc/terms/title

HTML usage context: heading content. This property should only appear once within the document scope.

covertitle

The title of the work as displayed on the work's cover.

Inherits from: title

HTML usage context: heading content. This property should only appear once within the document scope.

title

The primary name of a document component, such as a list, table, or figure.

HTML usage context: heading content, phrasing content descendants of heading content.

subtitle

An explanatory or alternate title for the work, or a section or component within it.

Inherits from: title

HTML usage context: heading content, phrasing content descendants of heading content, paragraphs, divs

DPUB-ARIA role: doc-subtitle

label [draft]

The text label that precedes an ordinal in a component title (e.g., 'Chapter', 'Part', 'Figure', 'Table').

Inherits from: title

HTML usage context: Phrasing content descendants of heading content, li and figcaption

ordinal [draft]

An ordinal specifier for a component in a sequence of components (e.g., '1', 'IV', 'B-1').

Inherits from: title

HTML usage context: Phrasing content descendants of heading content, li and figcaption

bridgehead

A structurally insignificant heading that does not contribute to the hierarchical structure of the work.

HTML usage context: flow content, typically p, div or span

D.8.10 Educational Content

Learning objectives

learning-objective

An explicit designation or description of a learning objective or a reference to an explicit learning objective.

HTML usage context: flow content, phrasing content

learning-objectives [draft]

A collection of learning-objectives.

HTML usage context: sectioning content, grouping content

learning-outcome [draft]

The understanding or ability a student is expected to achieve as a result of a lesson or activity.

HTML usage context: flow content

learning-outcomes [draft]

A collection of learning-outcomes.

HTML usage context: sectioning content, grouping content

learning-resource

A resource provided to enhance learning, or a reference to such a resource.

HTML usage context: flow content

learning-resources [draft]

A collection of learning-resources.

HTML usage context: sectioning content, grouping content

learning-standard [draft]

A formal set of expectations or requirements typically issued by a government or a standards body.

HTML usage context: sectioning content, phrasing content

learning-standards [draft]

A collection of learning-standards.

HTML usage context: sectioning content, grouping content

Testing

answer [draft]

The component of a self-assessment problem that provides the answer to the question.

HTML usage context: aside, grouping content

answers [draft]

A collection of answers.

HTML usage context: sectioning content, grouping content

assessment

A test, quiz, or other activity that helps measure a student's understanding of what is being taught.

HTML usage context: sectioning content

assessments [draft]

A collection of assessments.

HTML usage context: sectioning content

feedback [draft]

Instruction to the reader based on the result of an assessment.

HTML usage context: grouping content, phrasing content

fill-in-the-blank-problem [draft]

A problem that requires the reader to input a text answer to complete a sentence, statement or similar.

HTML usage context: aside, grouping content

general-problem [draft]

A problem with a free-form solution.

HTML usage context: aside, grouping content

qna

A section of content structured as a series of questions and answers, such as an interview or list of frequently asked questions.

HTML usage context: lists or sectioning content

DPUB-ARIA role: doc-qna

match-problem [draft]

A problem that requires the reader to match the contents of one list with the corresponding items in another list.

HTML usage context: aside, grouping content

multiple-choice-problem [draft]

A problem with a set of potential answers to choose from ‒ some, all, or none of which may be correct.

HTML usage context: aside, grouping content

practice [draft]

A review exercise or sample.

See also: practices

HTML usage context: aside, grouping content

question [draft]

The component of a self-assessment problem that identifies the question to be solved.

HTML usage context: grouping content

practices [draft]

A collection of practices.

HTML usage context: sectioning content

true-false-problem [draft]

A problem with either a true or false answer.

HTML usage context: aside, grouping content

D.8.11 Comics

panel

An individual frame, or drawing.

HTML usage context: li

Usage details: EPUB Region-Based Navigation

panel-group

A group of panels (e.g., a strip).

HTML usage context: li

Usage details: EPUB Region-Based Navigation

balloon

An area in a comic panel that contains the words, spoken or thought, of a character.

HTML usage context: li

Usage details: EPUB Region-Based Navigation

text-area

An area of text in a comic panel. Used to represent titles, narrative text, character dialogue (inside a balloon or not) and similar.

HTML usage context: li

Usage details: EPUB Region-Based Navigation

sound-area

An area of text in a comic panel that represents a sound.

HTML usage context: li

Usage details: EPUB Region-Based Navigation

D.8.12 Notes and Annotations

annotation [deprecated]

Explanatory information about passages in the work.

Inherits from: xhv:complementary

HTML usage context: aside, phrasing content

Replaced by: Open Annotation in EPUB

note [deprecated]

A note. This property does not carry spatial positioning semantics, as do the footnote and endnote properties. It can be used to identify footnotes, endnotes, marginal notes, inline notes, and similar when legacy naming conventions are not desired.

HTML usage context: On the aside element when identifying a single note, or on descendants of sectioning content when identifying individual notes in a group (refer to footnotes and endnotes).

Replaced by: footnote, endnote

footnote

Ancillary information, such as a citation or commentary, that provides additional context to a referenced passage of text.

See also: footnotes

HTML usage context: On the aside element when identifying a single footnote, or on descendants of sectioning content when identifying individual footnotes in a group (refer to footnotes and endnotes).

DPUB-ARIA role: doc-footnote

endnote

One of a collection of notes that occur at the end of a work, or a section within it, that provides additional context to a referenced passage of text.

See also: endnotes

HTML usage context: On the aside element when identifying a single endnote, or on descendants of sectioning content when identifying individual endnotes in a group (refer to footnotes and endnotes).

DPUB-ARIA role: doc-endnote (Deprecated)

rearnote [deprecated]

A note appearing in the rear (backmatter) of the work, or at the end of a section.

See also: rearnotes

HTML usage context: On the aside element when identifying a single rearnote, or on descendants of sectioning content when identifying individual rearnotes in a group (refer to footnotes and rearnotes).

Replaced by: endnote

footnotes

A collection of footnotes.

See also: footnote

HTML usage context: sectioning content

endnotes

A collection of notes at the end of a work or a section within it.

See also: endnote

HTML usage context: sectioning content

DPUB-ARIA role: doc-endnotes

rearnotes [deprecated]

A collection of notes appearing at the rear (backmatter) of the work, or at the end of a section.

See also: rearnote

HTML usage context: sectioning content

Replaced by: endnotes

D.8.14 Document Text

Terms for describing components at the phrasing level.

credit [draft]

An acknowledgment of the source of integrated content from third-party sources, such as photos. Typically identifies the creator, copyright, and any restrictions on reuse.

HTML usage context: phrasing content

DPUB-ARIA role: doc-credit

keyword

A key word or phrase.

HTML usage context: phrasing content

topic-sentence

A phrase or sentence serving as an introductory summary of the containing paragraph.

HTML usage context: phrasing content

concluding-sentence

A phrase or sentence serving as a concluding summary of the containing paragraph.

HTML usage context: phrasing content

D.8.15 Pagination

pagebreak

A separator denoting the position before which a break occurs between two contiguous pages in a statically paginated version of the content.

Page break locators are also commonly used to provide static markers in purely digital publications (i.e., where no statically paginated equivalent exists). These markers provide consistent navigation regardless of differences in font and screen size that can otherwise affect the dynamic pagination of the content.

EPUB Creators must ensure the name of the page break is an end user-consumable page number that identifies the page that is beginning.

HTML usage context: phrasing and flow content, where the value of the carrying elements title attribute takes precedence over element content for the purposes of representing the pagebreak value

DPUB-ARIA role: doc-pagebreak

page-list

A navigational aid that provides a list of links to the pagebreaks in the content.

HTML usage context: sectioning content

DPUB-ARIA role: doc-pagelist

D.8.16 Tables

table

A structure containing data or content laid out in tabular form.

HTML usage context: Not Allowed

Media Overlays usage context: Identifies a seq or par as an escapable or skippable table structure.

table-row

A row of data or content in a tabular structure.

HTML usage context: Not Allowed

Media Overlays usage context: Identifies a seq or par as an escapable or skippable table row.

table-cell

A single cell of tabular data or content.

HTML usage context: Not Allowed

Media Overlays usage context: Identifies a seq or par as an escapable or skippable table cell.

D.8.17 Lists

list

A structure that contains an enumeration of related content items.

HTML usage context: Not Allowed

Media Overlays usage context: Identifies a seq or par as an escapable or skippable list structure.

list-item

A single item in an enumeration.

HTML usage context: Not Allowed

Media Overlays usage context: Identifies a seq or par as an escapable or skippable list item.

D.8.18 Figures

figure

An illustration, diagram, photo, code listing or similar, referenced from the text of a work, and typically annotated with a title, caption and/or credits.

HTML usage context: Not Allowed

Media Overlays usage context: Identifies a seq or par as an escapable or skippable figure.

D.8.19 Asides

aside

Secondary or supplementary content.

HTML usage context: Not Allowed

Media Overlays usage context: Identifies a seq or par as an escapable or skippable aside.

E. Schemas

This section is non-normative.

E.1 Package Document Schema

A non-normative schema for Package Documents is available at https://github.com/w3c/epubcheck/tree/master/src/main/resources/com/adobe/epubcheck/schema/30/package-30.nvdl.

Validation using this schema requires a processor that supports [NVDL], [RelaxNG-Schema], [ISOSchematron] and [XMLSCHEMA-2].

Note

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

Note

These schemas may be updated and corrected outside of formal revisions of this specification. As a result, they are subject to change at any time.

E.2 OCF Schemas

E.2.1 Schema for container.xml

A non-normative schema for container.xml files is available at https://github.com/w3c/epubcheck/tree/master/src/main/resources/com/adobe/epubcheck/schema/30/ocf-container-30.nvdl.

Validation using this schema requires a processor that supports [RelaxNG-Schema] and [XMLSCHEMA-2].

E.2.2 Schema for encryption.xml

The schema for encryption.xml files is included in [XMLSEC-RNGSCHEMA-20130411].

E.2.3 Schema for signatures.xml

The schema for signatures.xml files is included in [XMLSEC-RNGSCHEMA-20130411].

E.3 Media Overlays Schema

A non-normative schema for Media Overlays is available at https://github.com/w3c/epubcheck/tree/main/src/master/resources/com/adobe/epubcheck/schema/30/media-overlay-30.nvdl.

Validation using this schema requires a processor that supports [NVDL], [RelaxNG-Schema], [ISOSchematron] and [XMLSCHEMA-2].

Note

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

F. Detailed Examples

F.1 Scripting Contexts

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:

F.2 Packaged EPUB

The following example demonstrates the use of the OCF format to contain a signed and encrypted EPUB Publication within an OCF ZIP Container.

F.3 Clock Values

The following are examples of allowed clock values:

G. Media Type Registrations

This section is non-normative.

G.1 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. It identifies the resources in the EPUB Publication and provides metadata information. The Package Document and its related specifications are maintained and defined by the World Wide Web Consortium (W3C).

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 3 specification 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 3 specification located at https://www.w3.org/TR/epub-33/.

The EPUB 3 specification supersedes the Open Packaging Format 2.0.1 specification, which is located at http://www.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

  • Bluefire Reader

  • Calibre

  • Google Play Books

  • Kobo

  • Microsoft Edge

  • Readium

Additional information:
Magic number(s):

none

File extension(s):

.opf

Macintosh File Type Code(s):

TEXT

Fragment Identifiers:

A registry of linking schemes is maintained at http://www.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:

public-epub3@w3.org

Intended usage:

COMMON

Author/Change controller:

World Wide Web Consortium (W3C)

G.2 The application/epub+zip Media Type

This section is non-normative.

This appendix registers the media type application/epub+zip for the EPUB Open Container Format (OCF).

An OCF ZIP Container, or EPUB Container, file is a container technology based on the [ZIP] archive format. It is used to encapsulate the EPUB Publication. OCF and its related standards are maintained and defined by the World Wide Web Consortium (W3C).

MIME media type name:

application

MIME subtype name:

epub+zip

Required parameters:

None.

Optional parameters:

None.

Encoding considerations:

OCF ZIP Container files are binary files encoded in the application/zip media type.

Security considerations:

All processors that read OCF ZIP Container 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 ZIP Container files, application/epub+zip may describe content that poses security implications beyond those noted here. However, only in cases 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. In such cases, matters of security would fall outside the domain of this registration document.

Security considerations that apply to application/zip also apply to OCF ZIP Container files.

Interoperability considerations:

None.

Published specification:

This media type registration is for the EPUB Open Container Format (OCF), as described by the EPUB 3 specification located at https://www.w3.org/TR/epub-33/.

The EPUB 3 specification supersedes both RFC 4839 and 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 that 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
  • Bluefire Reader
  • Calibre
  • Google Play Books
  • Kobo
  • Microsoft Edge
  • Readium
Additional information:
Magic number(s):

0: PK 0x03 0x04, 30: mimetype, 38: application/epub+zip

File extension(s):

OCF ZIP Container files are most often identified with the extension .epub.

Macintosh file type code(s):

ZIP

Fragment identifiers:

A registry of linking schemes is maintained at http://www.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:

public-epub3@w3.org

Intended usage:

COMMON

Author/change controller:

World Wide Web Consortium (W3C)

H. Change Log

Note that this change log only identifies substantive changes — those that affect the conformance of EPUB Publications or are similarly noteworthy.

For a list of all issues addressed during the revision, refer to the Working Group's issue tracker.

H.1 Substantive Changes since the Previous Working Draft

H.2 Substantive changes since EPUB 3.2

I. Acknowledgements

This section is non-normative.

The editors would like to thank the members of the EPUB 3 Working Group for their contributions to this specification:

J. References

J.1 Normative references

[AuthorityRegistry]
EPUB Subject Authorities Registry. URL: http://www.idpf.org/epub/registries/authorities/
[BCP47]
Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47
[BIDI]
Unicode Bidirectional Algorithm. Mark Davis; Aharon Lanin; Andrew Glass. Unicode Consortium. 12 February 2020. Unicode Standard Annex #9. URL: https://www.unicode.org/reports/tr9/tr9-42.html
[CSS-Device-Adapt-1]
CSS Device Adaptation Module Level 1. Rune Lillesveen; Florian Rivoal; Matt Rakow. W3C. 29 March 2016. W3C Working Draft. URL: https://www.w3.org/TR/css-device-adapt-1/
[CSS-Fonts-3]
CSS Fonts Module Level 3. John Daggett; Myles Maxfield; Chris Lilley. W3C. 20 September 2018. W3C Recommendation. URL: https://www.w3.org/TR/css-fonts-3/
[CSS-Text-3-20160119]
CSS Text Level 3 (20160119). Elika J. Etemad et al. URL: https://drafts.csswg.org/date/2016-01-19T17:23:23/css-text/
[CSS-Text-Decor-3]
CSS Text Decoration Module Level 3. Elika Etemad; Koji Ishii. W3C. 13 August 2019. W3C Candidate Recommendation. URL: https://www.w3.org/TR/css-text-decor-3/
[CSS-Values-3]
CSS Values and Units Module Level 3. Tab Atkins Jr.; Elika Etemad. W3C. 6 June 2019. W3C Candidate Recommendation. URL: https://www.w3.org/TR/css-values-3/
[CSS-Writing-Modes-3]
CSS Writing Modes Level 3. Elika Etemad; Koji Ishii. W3C. 10 December 2019. W3C Recommendation. URL: https://www.w3.org/TR/css-writing-modes-3/
[CSS-Writing-Modes-3-20151215]
CSS Writing Modes Level 3. Elika Etemad; Koji Ishii. W3C. 15 December 2015. W3C Candidate Recommendation. URL: https://www.w3.org/TR/2015/CR-css-writing-modes-3-20151215/
[CSS2]
CSS 2. W3C. W3C Recommendation. URL: https://www.w3.org/TR/CSS2/
[CSSSnapshot]
CSS Snapshot. URL: https://www.w3.org/TR/CSS/
[DateTime]
Date and Time Formats. W3C. 27 August 1998. W3C Note. URL: https://www.w3.org/TR/NOTE-datetime
[DC11]
Dublin Core Metadata Element Set, Version 1.1. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dces/
[DCTERMS]
DCMI Metadata Terms. DCMI Usage Board. DCMI. 20 January 2020. DCMI Recommendation. URL: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/
[DOM]
DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[ECMASCRIPT]
ECMAScript Language Specification. Ecma International. URL: https://tc39.es/ecma262/
[EPUB-A11Y-11]
EPUB Accessibility 1.1. Matt Garrish; George Kerscher; Charles LaPierre; Gregorio Pellegrino; Avneesh Singh. W3C. 23 February 2021. W3C Working Draft. URL: https://www.w3.org/TR/epub-a11y-11/
[EPUB-MULTI-REND-11]
EPUB Multiple-Rendition Publications 1.1. Matt Garrish. W3C. 12 January 2021. W3C Note. URL: https://www.w3.org/TR/epub-multi-rend-11/
[EPUB-OVERVIEW-33]
EPUB 3 Overview. Garth Conboy; Matt Garrish; Daniel Weck. W3C. 12 January 2021. W3C Note. URL: https://www.w3.org/TR/epub-overview-33/
[EPUB-RS-33]
EPUB 3.3 Reading Systems. Garth Conboy; Dave Cramer; Marisa DeMeglio; Matt Garrish; Daniel Weck. W3C. 12 January 2021. W3C Working Draft. URL: https://www.w3.org/TR/epub-rs-33/
[EPUBContentDocs-301]
EPUB Content Documents 3.0.1. Markus Gylling; William McCoy; Elika J. Etimad; Matt Garrish. IDPF. 26 June 2014. URL: http://idpf.org/epub/301/spec/epub-contentdocs-20140626.html
[EPUBPublications-30]
EPUB Publications 3.0. Markus Gylling; William McCoy; Matt Garrish. IDPF. 11 October 2011. URL: http://idpf.org/epub/30/spec/epub30-publications-20111011.html
[EPUBPublications-301]
EPUB Publications 3.0.1. Markus Gylling; William McCoy; Matt Garrish. IDPF. 26 June 2014. URL: http://idpf.org/epub/301/spec/epub-publications-20140626.html
[FIPS-180-4]
FIPS PUB 180-4 Secure Hash Standard. U.S. Department of Commerce/National Institute of Standards and Technology. URL: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
[GIF]
Graphics Interchange Format. CompuServe Incorporated. 31 July 1990. URL: https://www.w3.org/Graphics/GIF/spec-gif89a.txt
[H264]
H.264 : Advanced video coding for generic audiovisual services. 2017-04-13. URL: https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=13189
[HTML]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[HTML-RDFA]
HTML+RDFa 1.1 - Second Edition. Manu Sporny. W3C. 17 March 2015. W3C Recommendation. URL: https://www.w3.org/TR/html-rdfa/
[Infra]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[ISO8601]
Representation of dates and times. ISO 8601:2004.. International Organization for Standardization (ISO). 2004. ISO 8601:2004. URL: http://www.iso.org/iso/catalogue_detail?csnumber=40874
[JPEG]
JPEG File Interchange Format. Eric Hamilton. C-Cube Microsystems. Milpitas, CA, USA. September 1992. URL: https://www.w3.org/Graphics/JPEG/jfif3.pdf
[JSON-LD]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 3 November 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/
[MATHML3]
Mathematical Markup Language (MathML) Version 3.0 2nd Edition. David Carlisle; Patrick D F Ion; Robert R Miner. W3C. 10 April 2014. W3C Recommendation. URL: https://www.w3.org/TR/MathML3/
[MP3]
Information technology — Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s — Part 3: Audio. ISO/IEC. August 1993. Published. URL: https://www.iso.org/standard/22412.html
[MP4]
Information technology — Coding of audio-visual objects — Part 14: MP4 file format. ISO/IEC. January 2020. Published. URL: https://www.iso.org/standard/79110.html
[MPEG4-Audio]
Information technology — Coding of audio-visual objects — Part 3: Audio. ISO/IEC. December 2019. Published. URL: https://www.iso.org/standard/76383.html
[ONIX]
ONIX for Books 3.0. URL: https://www.editeur.org/8/ONIX/
[OpenType]
OpenType specification. Microsoft. URL: http://www.microsoft.com/typography/otspec/default.htm
[OPF-201]
Open Packaging Format 2.0.1. IDPF. 04 September 2010. URL: http://www.idpf.org/epub/20/spec/OPF_2.0.1_draft.htm
[PNG]
Portable Network Graphics (PNG) Specification (Second Edition). Tom Lane. W3C. 10 November 2003. W3C Recommendation. URL: https://www.w3.org/TR/PNG/
[PRONUNCIATION-LEXICON]
Pronunciation Lexicon Specification (PLS) Version 1.0. Paolo Baggia. W3C. 14 October 2008. W3C Recommendation. URL: https://www.w3.org/TR/pronunciation-lexicon/
[RDFA-CORE]
RDFa Core 1.1 - Third Edition. Ben Adida; Mark Birbeck; Shane McCarron; Ivan Herman et al. W3C. 17 March 2015. W3C Recommendation. URL: https://www.w3.org/TR/rdfa-core/
[RFC2046]
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed; N. Borenstein. IETF. November 1996. Draft Standard. URL: https://tools.ietf.org/html/rfc2046
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC2397]
The "data" URL scheme. L. Masinter. IETF. August 1998. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc2397
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987
[RFC4329]
Scripting Media Types. B. Hoehrmann. IETF. April 2006. Informational. URL: https://tools.ietf.org/html/rfc4329
[RFC6386]
VP8 Data Format and Decoding Guide. J. Bankoski; J. Koleszar; L. Quillio; J. Salonen; P. Wilkins; Y. Xu. IETF. November 2011. Informational. URL: https://tools.ietf.org/html/rfc6386
[RFC7845]
Ogg Encapsulation for the Opus Audio Codec. T. Terriberry; R. Lee; R. Giles. IETF. April 2016. Proposed Standard. URL: https://tools.ietf.org/html/rfc7845
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://tools.ietf.org/html/rfc8174
[RoleRegistry]
EPUB Collection Roles Registry. URL: http://www.idpf.org/epub/registries/roles
[SMIL3]
Synchronized Multimedia Integration Language (SMIL 3.0). Dick Bulterman. W3C. 1 December 2008. W3C Recommendation. URL: https://www.w3.org/TR/SMIL3/
[SSML]
Speech Synthesis Markup Language (SSML) Version 1.1. Daniel Burnett; Zhi Wei Shuang. W3C. 7 September 2010. W3C Recommendation. URL: https://www.w3.org/TR/speech-synthesis11/
[SVG]
SVG. W3C. URL: https://www.w3.org/TR/SVG/
[TR15]
Unicode Normalization Forms. URL: http://www.unicode.org/reports/tr15/
[TrueType]
Apple TrueType Reference Manual. Apple. 2002. URL: https://developer.apple.com/fonts/TrueType-Reference-Manual/
[TypesRegistry]
EPUB Publication Types Registry. URL: http://www.idpf.org/epub/vocab/package/types
[Unicode]
The Unicode Standard. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
[URL]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[US-ASCII]
"Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986..
[WAI-ARIA]
Accessible Rich Internet Applications (WAI-ARIA) 1.0. James Craig; Michael Cooper et al. W3C. 20 March 2014. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria/
[WebP-Container]
WebP Container Specification. URL: https://developers.google.com/speed/webp/docs/riff_container
[WebP-LB]
WebP Lossless Bitstream Specification. URL: https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification
[WOFF]
WOFF File Format 1.0. Jonathan Kew; Tal Leming; Erik van Blokland. W3C. 13 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/WOFF/
[WOFF2]
WOFF File Format 2.0. Vladimir Levantovsky; Raph Levien. W3C. 1 March 2018. W3C Recommendation. URL: https://www.w3.org/TR/WOFF2/
[XInclude]
XML Inclusions (XInclude) Version 1.0 (Second Edition). Jonathan Marsh; David Orchard; Daniel Veillard. W3C. 15 November 2006. W3C Recommendation. URL: https://www.w3.org/TR/xinclude/
[XML]
Extensible Markup Language (XML) 1.0 (Fifth Edition). Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau et al. W3C. 26 November 2008. W3C Recommendation. URL: https://www.w3.org/TR/xml/
[XML-NAMES]
Namespaces in XML 1.0 (Third Edition). Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson et al. W3C. 8 December 2009. W3C Recommendation. URL: https://www.w3.org/TR/xml-names/
[XMLDSIG-CORE1]
XML Signature Syntax and Processing Version 1.1. Donald Eastlake; Joseph Reagle; David Solo; Frederick Hirsch; Magnus Nyström; Thomas Roessler; Kelvin Yiu. W3C. 11 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/xmldsig-core1/
[XMLENC-CORE1]
XML Encryption Syntax and Processing Version 1.1. Donald Eastlake; Joseph Reagle; Frederick Hirsch; Thomas Roessler. W3C. 11 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/xmlenc-core1/
[XMLENC-DECRYPT]
Decryption Transform for XML Signature. Merlin Hughes; Takeshi Imamura; Hiroshi Maruyama. W3C. 10 December 2002. W3C Recommendation. URL: https://www.w3.org/TR/xmlenc-decrypt/
[XMLSCHEMA-2]
XML Schema Part 2: Datatypes Second Edition. Paul V. Biron; Ashok Malhotra. W3C. 28 October 2004. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema-2/
[XMP]
Extensible metadata platform (XMP) specification -- Part 1. Adobe Systems Incorporated. ISO/IEC. 15 February 2012. URL: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=57421
[XPTRSH]
XPointer Shorthand Notation. 25 March 2003. URL: https://www.w3.org/TR/2003/REC-xptr-framework-20030325/
[ZIP]
.ZIP File Format Specification. 1 September 2012. Final. URL: https://www.pkware.com/documents/casestudies/APPNOTE.TXT

J.2 Informative references

[AttributeExtensions]
EPUB Custom Attribute Extensions for Content Documents. URL: http://www.idpf.org/epub/extensions/attributes
[Audiobooks]
Audiobooks. Wendy Reid; Matt Garrish. W3C. 10 November 2020. W3C Recommendation. URL: https://www.w3.org/TR/audiobooks/
[CSS3-MediaQueries]
Media Queries. Florian Rivoal et al. W3C. 19 June 2012. W3C Recommendation. URL: https://www.w3.org/TR/css3-mediaqueries/
[DPUB-ARIA-1.0]
Digital Publishing WAI-ARIA Module 1.0. Matt Garrish; Tzviya Siegman; Markus Gylling; Shane McCarron. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/dpub-aria-1.0/
[EPUB-A11Y-TECH-11]
EPUB Accessibility Techniques 1.1. Matt Garrish; George Kerscher; Charles LaPierre; Gregorio Pellegrino; Avneesh Singh. W3C. 23 February 2021. W3C Note. URL: https://www.w3.org/TR/epub-a11y-tech-11/
[EPUBPackages-32]
EPUB Packages 3.2. Matt Garrish; Dave Cramer. EPUB 3 Community Group. 08 May 2019. URL: https://www.w3.org/publishing/epub32/epub-packages.html
[HTML-ARIA]
ARIA in HTML. Steve Faulkner; Scott O'Hara; Patrick Lauke. W3C. 15 January 2021. W3C Working Draft. URL: https://www.w3.org/TR/html-aria/
[ISOSchematron]
ISO/IEC 19757-3: Rule-based validation — Schematron. 2006-06-01. URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip
[JSON-LD11]
JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/
[NVDL]
ISO/IEC 19757-4: NVDL (Namespace-based Validation Dispatching Language). 2006-06-01. URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c038615_ISO_IEC_19757-4_2006(E).zip
[ODF]
Open Document Format for Office Applications (OpenDocument) v1.0. 1 May 2005. URL: https://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf
[RelaxNG-Schema]
Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG. ISO/IEC. 2008. URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip
[RFC]
Request for Comments. URL: https://www.ietf.org/standards/rfcs/
[RFC4839]
Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF). G. Conboy; J. Rivlin; J. Ferraiolo. IETF. April 2007. Informational. URL: https://tools.ietf.org/html/rfc4839
[RoleExtensions]
EPUB Collection Element Role Extensions. URL: http://www.idpf.org/epub/extensions/roles
[UAAG20]
User Agent Accessibility Guidelines (UAAG) 2.0. James Allan; Greg Lowney; Kimberly Patch; Jeanne F Spellman. W3C. 15 December 2015. W3C Note. URL: https://www.w3.org/TR/UAAG20/
[XMLBase]
XML Base (Second Edition). Jonathan Marsh; Richard Tobin. W3C. 28 January 2009. W3C Recommendation. URL: https://www.w3.org/TR/xmlbase/
[XMLSEC-RNGSCHEMA-20130411]
XML Security RELAX NG Schemas. Murata Makoto; Frederick Hirsch. W3C. 11 April 2013. W3C Note. URL: https://www.w3.org/TR/2013/NOTE-xmlsec-rngschema-20130411/