EPUB Publications 3.0
EPUB Publications 3.0
Recommended Specification
11 October 2011
This version
Latest version
Previous version
A diff of changes from the previous draft is available at
this link
Please refer to the
errata
for this document, which may include some normative corrections.
Copyright © 2010, 2011 International Digital Publishing Forum™
All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the
International Digital Publishing Forum (IDPF)
EPUB is a registered trademark of the International Digital Publishing Forum.
Editors
Markus Gylling, DAISY Consortium
William McCoy, International Digital Publishing Forum (IDPF)
Matt Garrish, Invited Expert
Table of Contents
1. Overview
1.1. Purpose and Scope
1.2. Terminology
1.3. Conformance Statements
2. EPUB Publications
2.1. Content Conformance
2.2. Reading System Conformance
3. Package Documents
3.1. Introduction
3.2. Content Conformance
3.3. Reading System Conformance
3.4. Package Document Definition
3.4.1. The
package
Element
3.4.2. The
metadata
Element
3.4.3. The DCMES
identifier
Element
3.4.4. The DCMES
title
Element
3.4.5. The DCMES
language
Element
3.4.6. The DCMES Optional Elements
3.4.7. The
meta
Element
3.4.8. The
meta
Element (OPF2) [OBSOLETE]
3.4.9. The
link
Element
3.4.10. The
manifest
Element
3.4.11. The
item
Element
3.4.12. The
spine
Element
3.4.13. The
itemref
Element
3.4.14. The
guide
Element [DEPRECATED]
3.4.15. The
bindings
Element
3.4.16. The
mediaType
Element
4. Package Metadata
4.1. Publication Identifiers
4.1.1. Unique Identifier
4.1.2. Package Identifier
4.2. Vocabulary Association Mechanisms
4.2.1. Overview
4.2.2. Default Vocabulary
4.2.3. Reserved Vocabularies
4.2.4. The
prefix
Attribute
4.2.5. The property Data Type
4.2.5.1. Syntax
4.2.5.2. Processing
4.3. Package Metadata Vocabulary
4.3.1. Overview
4.3.2. Metadata
meta
Properties
4.3.3. Metadata
link
Properties
4.3.4. Manifest
item
Properties
4.3.5. Spine
itemref
Properties
5. Publication Resources
5.1. Core Media Types
5.2. Restrictions and Fallbacks
5.2.1. Foreign Resource Restrictions
5.2.2. Manifest Fallbacks
5.3. Publication Resource Locations
5.4. XML Conformance
A. Package Document Schema
B. The
application/oebps-package+xml
Media Type
C. Acknowledgements and Contributors
References
1 Overview
1.1 Purpose and Scope
This section is informative
This specification, EPUB Publications 3.0, defines publication-level semantics and conformance requirements for EPUB® 3, including the format of the
Package Document
and rules for how this document and other
Publication Resource
s are associated to create a conforming EPUB Publication.
This specification is one of a family of related specifications that compose EPUB 3, the third major revision of an interchange and delivery format for digital publications based on XML and Web Standards. It is meant to be read and understood in concert with the other specifications that make up EPUB 3:
The EPUB 3 Overview
EPUB3Overview
, which provides an informative overview of EPUB and a roadmap to the rest of the EPUB 3 documents. The Overview should be read first.
EPUB Content Documents 3.0
ContentDocs30
, which defines profiles of XHTML, SVG and CSS for use in the context of
EPUB Publication
s.
EPUB Open Container Format (OCF) 3.0
OCF3
, which defines a file format and processing model for encapsulating a set of related resources into a single-file (ZIP)
EPUB Container
EPUB Media Overlays 3.0
MediaOverlays30
, which defines a format and a processing model for synchronization of text and audio.
This specification supersedes Open Package Format 2.0.1
OPF2
. Refer to
EPUB3Changes
for information on differences between this specification and its predecessor.
1.2 Terminology
EPUB Publication (or Publication)
A logical document entity consisting of a set of interrelated
resources
and packaged in an
EPUB Container
, as defined by
this specification and its
sibling specifications
Publication Resource
A resource that contains content or instructions that contribute to the logic and rendering of the
EPUB Publication
. In the absence of this resource, the Publication might not render as intended by the
Author
. Examples of Publication Resources include the
Package Document
EPUB Content Document
s,
EPUB Style Sheet
s, audio, video, images, embedded fonts and scripts.
With the exception of the Package Document itself, Publication Resources must be listed in the
manifest
and must be bundled in the EPUB container file unless specified otherwise in
Publication Resource Locations
Examples of resources that are not Publication Resources include those identified by the Package Document
link
element and those identified in outbound hyperlinks that resolve outside the
EPUB Container
(e.g., referenced from an
HTML5
element
href
attribute).
Foreign Resource
Publication Resource
that is not a
Core Media Type
. A Foreign Resource requires at least one fallback, as defined in
Restrictions and Fallbacks
Core Media Type Resource
Publication Resource
that is a
Core Media Type
and may therefore be included in the
EPUB Publication
without the provision of
fallbacks
EPUB Content Document
Publication Resource
that conforms to one of the EPUB Content Document definitions (
XHTML
or
SVG
).
An EPUB Content Document is a
Core Media Type
, and may therefore be included in the
EPUB Publication
without the provision of
fallbacks
XHTML Content Document
An
EPUB Content Document
conforming to the profile of
HTML5
defined in
XHTML Content Documents
ContentDocs30
XHTML Content Documents use the
XHTML syntax
of
HTML5
SVG Content Document
An
EPUB Content Document
conforming to the constraints expressed in
SVG Content Documents
ContentDocs30
EPUB Navigation Document
A specialization of the
XHTML Content Document
, containing human- and machine-readable global navigation information, conforming to the constraints expressed in
EPUB Navigation Documents
ContentDocs30
Scripted Content Document
An
EPUB Content Document
that includes scripting or an
XHTML Content Document
that contains
HTML5 forms
elements.
Refer to
Scripted Content Documents
ContentDocs30
for more information.
Top-level Content Document
An
EPUB Content Document
referenced directly from the
spine
Core Media Type
A set of
Publication Resource
types for which no fallback is required. Refer to
Publication Resources
for more information.
Package Document
Publication Resource
carrying bibliographical and structural metadata about the
EPUB Publication
, as defined in
Package Documents
Manifestation
The digital (or physical) embodiment of a work of intellectual content. Changes to the content such as significant revision, abridgement, translation, or the realization of the content in a different digital or physical form result in a new manifestation. There may be many individual but identical copies of a manifestation, termed 'instances' or 'items'. The ISBN is an example of a manifestation identifier, and is shared by all instances of that manifestation.
All instances of a manifestation need not be bit-for-bit identical, as minor corrections or revisions are not judged to create a new manifestation or work.
Unique Identifier
The Unique Identifier is the primary identifier for an
EPUB Publication
, as identified by the
unique-identifier
attribute. The Unique Identifier may be shared by one or many
Manifestation
s of the same work that conform to the EPUB standard and embody the same content, where the differences between the Manifestations are limited to those changes that take account of differences between
EPUB Reading System
s (and which themselves may require changes in the ISBN).
The Unique Identifier is less granular than the ISBN. However, significant revision, abridgement, etc. of the content requires a new Unique Identifier.
Package Identifier
The Package Identifier allows any instance of an
EPUB Publication
to be compared against another to determine if they are identical, different versions of the same
Manifestation
, or unrelated.
Refer to
Package Identifier
for more information.
Manifest
A list of all
Publication Resource
s that constitute the
EPUB Publication
Refer to
manifest
for more information.
Spine
An ordered list of
Publication Resource
s,
typically
EPUB Content Document
s, representing the default reading order of the Publication.
Refer to
spine
for more information.
Media Overlay Document
An XML document that associates the
XHTML Content Document
with pre-recorded audio narration in order to provide a synchronized playback experience, as defined in
MediaOverlays30
Text-to-Speech (TTS)
The rendering of the textual content of an
EPUB Publication
as artificial human speech using a synthesized voice.
EPUB Style Sheet (or Style Sheet)
A CSS Style Sheet conforming to the CSS profile defined in
EPUB Style Sheets
ContentDocs30
Viewport
The region of an
EPUB Reading System
in which the content of an
EPUB Publication
is rendered visually to a
User
CSS Viewport
Viewport
capable of displaying CSS-styled content.
EPUB Container (or Container)
The ZIP-based packaging and distribution format for
EPUB Publication
s defined in
OCF3
Author
The person(s) or organization responsible for the creation of an
EPUB Publication
, which is not necessarily the creator of the content and resources it contains.
User
An individual that consumes an
EPUB Publication
using an
EPUB Reading System
EPUB Reading System (or Reading System)
A system that processes
EPUB Publication
s for presentation to a
User
in a manner conformant with
this specification and its
sibling specifications
1.3 Conformance Statements
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
RFC2119
All sections of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendices applies to all child content and subsections they may contain.
All examples in this specification are informative.
2 EPUB Publications
This section defines conformance requirements for
EPUB Publication
s and
EPUB Reading System
s at the Publication level. Conformance requirements particular to specific
Publication Resource
s and processing contexts are located in the specifications referenced herein.
2.1 Content Conformance
An
EPUB Publication
must meet all of the following criteria:
All Publication Resources
All
Publication Resource
s it contains must be represented in the Package Document (as defined in
manifest
), adhere to the
constraints for Core Media Types and Fallback
and be located as per
Publication Resource Locations
The Package Document
It must contain exactly one
Package Document
, which must conform to the content requirements defined in
Package Document — Content Conformance
Content Documents
It must contain at least one
EPUB Content Document
conformant to the content requirements defined in
EPUB Content Documents
ContentDocs30
The EPUB Navigation Document
It must contain exactly one
EPUB Navigation Document
conformant to the content requirements defined in
EPUB Navigation Documents — Content Conformance
ContentDocs30
EPUB Style Sheets
It may contain zero or more
EPUB Style Sheet
s conformant to the content requirements defined in
EPUB Style Sheets — Content Conformance
ContentDocs30
EPUB Pronunciation Lexicons
It may contain zero or more PLS Documents conformant to the content requirements defined in
PLS Documents — Content Conformance
ContentDocs30
Media Overlay Documents
It may contain zero or more
Media Overlay Document
s conformant to the content requirements defined in
MediaOverlays30
Additional Publication Resources
It may contain zero or more
Publication Resource
s in addition to those listed above, each of which must adhere to the requirements in
All Publication Resources
Container
It must be packaged in a
EPUB Container
as defined in
OCF3
2.2 Reading System Conformance
An
EPUB Reading System
must meet all of the following criteria:
EPUB 3 Processing
It must process the
EPUB Container
as defined in
OCF3
It must process the
Package Document
as defined in
Package Document — Reading System Conformance
, and honor all presentation logic expressed through the Package Document (e.g., the reading order, fallback chains and bindings).
It must not fail catastrophically if it encounters two distinct EPUB Publications with the same
Unique Identifier
Unless specified as
conditional behavior
in this section, it must support all
Core Media Type Resource
s.
It may support an arbitrary set of
Foreign Resource
types, and must process fallbacks for unsupported Foreign Resources as defined in
Restrictions and Fallbacks
if not.
It must process
XHTML Content Document
s as defined in
XHTML Content Documents — Reading System Conformance
ContentDocs30
It must process
SVG Content Document
s as defined in
SVG Content Documents — Reading System Conformance
ContentDocs30
If it has a
CSS Viewport
, it must support visual rendering of
XHTML Content Document
s as defined in
EPUB Style Sheets — Reading System Conformance
ContentDocs30
If it has the capability to render raster images
, it must support the
raster image Core Media Types
If it has the capability to render vector images
, it must support the
vector image Core Media Types
If it has the capability to render pre-recorded audio
, it must support the
MP3 audio Core Media Type
, should support the
MP4 audio Core Media Type
and should support Media Overlays
MediaOverlays30
If it supports
Text-to-Speech (TTS)
rendering
, it should support
PLS Documents
ContentDocs30
, the CSS3 Speech features of the
EPUB CSS Profile
ContentDocs30
and
SSML attributes
ContentDocs30
in
XHTML Content Document
s.
It must support the EPUB Canonical Fragment Identifiers scheme
EPUBCFI
for linking, and may support additional linking schemes as defined in the
EPUB Linking Scheme Registry
note
It is recommended that Reading Systems support at least one of the
H.264
and
VP8
video codecs, but this is not a conformance requirement; a Reading System may support no video codecs at all. Content creators and Reading System developers should take into consideration factors such as breadth of adoption, video playback quality, and technology usage royalty requirements when making a choice to include or implement video in either (or potentially, both) formats.
Backward Compatibility
It should process EPUB version 2 Publications as defined in
OPF2
OPS2
and
OCF2
It must attempt to process any Publication whose Package Document
version
attribute designates a version lower than
3.0
or which omits the
version
attribute.
Forward Compatibility
It should attempt to process any Publication whose Package Document
version
attribute designates a version higher than
3.0
or which omits the
version
attribute.
XML Processing
It must be a
conformant non-validating processor
XML
It must be a
conformant processor
as defined in
XMLNS
It must support
xml-stylesheet
processing instructions
ASSOCSS
, and may support additional processing instructions.
It must be a conformant application as defined by
XML Base
note
A conforming Reading System is not necessarily a single dedicated program or device, but may exist as a distributed system.
3 Package Documents
3.1 Introduction
This section is informative
The
Package Document
carries bibliographic and structural metadata about an
EPUB Publication
, and is thus the primary source of information about how to process and display it.
The Package Document is an XML document consisting of a set of container elements, each dedicated to housing information about a particular aspect of the Publication. These containers effectively centralize metadata for the Publication, detail the individual resources that compose it and provide reading order and other information for rendering the Publication to a
User
The following list summarizes the information a Package Document contains:
Publication
metadata
— mechanisms for including and/or referencing metadata applicable to the entire Publication and particular resources within it.
Publication manifest
— identifies (via IRI) and describes (via MIME media type) the set of resources that collectively compose the Publication.
spine
— an ordered sequence of ID references to top-level resources in the manifest from which all other resources in the set can be reached or utilized. The spine defines the default reading order of the Publication.
Fallback chains
— an optional means for Publications to define an ordered list of top-level resources that can be considered content equivalents that a Reading System can choose between for rendering.
Bindings
— an optional means of associating script-based implementations with custom media types.
3.2 Content Conformance
Package Document
must meet all of the following criteria:
Document Properties
It must meet the conformance constraints for XML documents defined in
XML Conformance
It must be valid to the Package Document schema, as defined in
Appendix A,
Package Document Schema
, and conform to all content conformance constraints expressed in
Package Document Definition
File Properties
The Package Document filename should use the file extension
.opf
Package Documents have the MIME media type
application/oebps-package+xml
RFC4839
3.3 Reading System Conformance
An
EPUB Reading System
must meet all of the following criteria:
Processing
It must process the Package Document in conformance with all Reading System conformance constraints expressed in
Package Document Definition
3.4 Package Document Definition
All elements
XML
defined in this section are in the
namespace
XMLNS
unless otherwise specified.
3.4.1 The
package
Element
The
package
element is the root container of the
Package Document
and encapsulates
Publication
metadata and resource information.
Element Name
package
Usage
The
package
element is the root element of the Package Document.
Attributes
version
[required]
Specifies the EPUB specification version to which the Publication conforms.
The attribute must have the value
3.0
to indicate compliance with this version of the specification.
unique-identifier
[required]
An IDREF
XML
that identifies the
dc:identifier
element that provides the package's preferred, or primary, identifier.
Refer to
Publication Identifiers
for more information.
prefix
[optional]
Declaration mechanism for prefixes not
reserved by this specification
Refer to
The
prefix
Attribute
for more information.
xml:lang
[optional]
Specifies the language used in the contents and attribute values of the carrying element and its descendants, as defined in section
2.12 Language Identification
of
XML
dir
[optional]
Specifies the base text direction of the content and attribute values of the carrying element and its descendants.
Inherent directionality specified using
Unicode
takes precedence over this attribute.
Allowed values are
ltr
(left-to-right) or
rtl
(right-to-left).
id
[optional]
The ID
XML
of this element, which must be unique within the document scope.
Content Model
In this order:
metadata
[required]
manifest
[required]
spine
[required]
guide
[optional/deprecated]
bindings
[optional]
3.4.2 The
metadata
Element
The
metadata
element encapsulates
Publication
meta information.
Element Name
metadata
Usage
Required first child of
package
Attributes
The
metadata
element has no attributes defined in this specification.
Content Model
In any order:
dc:identifier
[1 or more]
dc:title
[1 or more]
dc:language
[1 or more]
DCMES Optional Elements
[0 or more]
meta
[1 or more]
OPF2 meta
[0 or more]
link
[0 or more]
The minimal required metadata that Publications must include consists of three elements from the Dublin Core Metadata Element Set
DCMES
title
identifier
and
language
— together with the
modified
property
from DCMI Metadata Terms
DCTERMS
. Refer to the
example
at the end of this section for an instance of a complete minimal metadata set.
Additional optional metadata is expressed using the
DCMES optional elements
and the
meta
element.
Examples
The following example represents the minimal set of metadata that all Publications must contain.
2011-01-01T12:00:00Z
3.4.3 The DCMES
identifier
Element
The
DCMES
identifier
element contains a single identifier associated with the
EPUB Publication
, such as a UUID, DOI, ISBN or ISSN.
Element Name
dc:identifier
Namespace
Usage
Required child of
metadata
. Repeatable.
Attributes
id
[optional]
The ID
XML
of this element, which must be unique within the document scope.
The
id
attribute is required on the
identifier
element containing the unique identifier. See below.
Content Model
Text
Every
metadata
section must include at least one
identifier
element containing an unambiguous identifier for the Publication. Multiple
identifier
elements are permitted, but only one can be marked as the
Unique Identifier
via the
package
element
unique-identifier
attribute.
The following example shows the unique
identifier
element for a Publication.
This specification makes a distinction between the
Unique Identifier
for an EPUB Publication and the identifier that uniquely identifies a specific version of it (i.e., to be able to differentiate EPUB Publications containing different versions of the same
Manifestation
). Two copies of an EPUB that are bit-for-bit identical are the same version and must retain the same
last modified date
. If they are not bit-for-bit identical, they represent different versions, and must have different last modified dates.
To identify a specific version of a packaged Publication, a
Package Identifier
can be constructed by combining the Unique Identifier with the last modified date of the Publication. Changes between versions may include minor typographic or markup corrections, without affecting the Unique Identifier. Significant revisions to the content that result in a new edition require a change of the Unique Identifier. For more information on the semantics and requirements of the Package Identifier, refer to
Package Identifier
This specification imposes no additional restrictions or requirements on identifiers except that they must be at least one character in length. It is strongly recommended that all identifiers be fully qualified URIs, however.
Reading Systems must trim all leading and trailing whitespace from the element value, as defined by the XML specification
XML
, before processing the value.
To determine whether an
identifier
conforms to an established system or has been granted by an issuing authority, Reading Systems should parse the value of the property. For additional precision (e.g., if the scheme cannot be determined from the value or could lead to an ambiguous result),
Author
s may
attach
an
identifier-type
property to assist in Reading System identification. When included, the
identifier-type
property should take precedence over value parsing the
identifier
The following example shows how an
identifier
can be additionally marked as a DOI using the
identifier-type
property.
06
This specification does not require or endorse the use of any specific scheme for identifiers, and imposes no restrictions or requirements on
identifier-type
identifiers beyond those specified in the property definition.
When an EPUB Publication is derived from another publication, the identifier for that source publication may be included in the Publication metadata, and must be represented using the
DCMES
source
element
3.4.4 The DCMES
title
Element
The
DCMES
title
element represents an instance of a name given to the
EPUB Publication
Element Name
dc:title
Namespace
Usage
Required child of
metadata
. Repeatable.
Attributes
id
[optional]
The ID
XML
of this element, which must be unique within the document scope.
xml:lang
[optional]
Specifies the language used in the contents and attribute values of the carrying element and its descendants, as defined in section
2.12 Language Identification
of
XML
dir
[optional]
Specifies the base text direction of the content and attribute values of the carrying element and its descendants.
Inherent directionality specified using
Unicode
takes precedence over this attribute.
Allowed values are
ltr
(left-to-right) or
rtl
(right-to-left).
Content Model
Text
Every
metadata
section must include at least one
title
element containing the title for the Publication. Multiple
title
elements are permitted, but the
title-type
property should be
attached
to indicate the type of title (e.g., the main title of a work, a subtitle, etc.).
The following example shows how to indicate different title types.
main
edition
short
When adding the
title-type
property,
Author
s should designate only one
title
element as containing the main title for the Publication. If no means of determining title types is provided, or understood, Reading Systems must treat the first
title
element in document order as the main title. This specification does not define how additional
title
elements should be processed in such situations.
The optional
display-seq
property may also be attached to each
title
to indicate their primacy for display and other rendering purposes.
The following example shows how to indicate display sequence.
main
1
subtitle
2
subtitle
3
This specification imposes no additional restrictions or requirements on titles except that they must be at least one character in length.
Reading Systems must trim all leading and trailing whitespace from the element value, as defined by the XML specification
XML
, before processing the value.
Examples
The following example shows how the title "THE LORD OF THE RINGS, Part One: The Fellowship of the Ring" could be classified.
main
collection
1
extended
The following example shows how the complex title "The Great Cookbooks of the World: Mon premier guide de cuisson, un Mémoire. The New French Cuisine Masters, Volume Two. Special Anniversary Edition" could be classified.
main
2
collection
1
collection
2
3
edition
4
Mon premier guide de cuisson, un Mémoire.
The New French Cuisine Masters, Volume Two.
Special Anniversary Edition
extended
3.4.5 The DCMES
language
Element
The
DCMES
language
element specifies the language of the Publication content.
Element Name
dc:language
Namespace
Usage
Required child of
metadata
Attributes
id
[optional]
The ID
XML
of this element, which must be unique within the document scope.
Content Model
Text
Every
metadata
section must include at least one
language
element with a value conforming to
RFC5646
The following example shows a Publication is in U.S. English.
Additional
language
elements may be included for multilingual Publications, but each element's value must conform to
RFC5646
Reading Systems must trim all leading and trailing whitespace from the element value, as defined by the XML specification
XML
, before processing the value.
3.4.6 The DCMES Optional Elements
All elements from the
DCMES
element set — except for
identifier
language
and
title
, as defined above — are designated as optional. These elements all conform to the following generalized definition:
Element Name
contributor | coverage | creator | date | description | format | publisher | relation | rights | source | subject | type
Namespace
Usage
Optional child of
metadata
. Repeatable.
Attributes
id
[optional]
The ID
XML
of this element, which must be unique within the document scope.
xml:lang
[optional]
Specifies the language used in the contents and attribute values of the carrying element and its descendants, as defined in section
2.12 Language Identification
of
XML
dir
[optional]
Specifies the base text direction of the content and attribute values of the carrying element and its descendants.
Inherent directionality specified using
Unicode
takes precedence over this attribute.
Allowed values are
ltr
(left-to-right) or
rtl
(right-to-left).
Content Model
Text
* The
xml:lang
and
dir
attributes are permitted only on the following elements:
contributor
coverage
creator
description
publisher
relation
rights
and
subject
The value of all optional
DCMES
elements must be at least one character in length.
Reading Systems must trim all leading and trailing whitespace from the element value, as defined by the XML specification
XML
, before processing the value.
Except as detailed below, this specification does not modify the
DCMES
definitions for these elements.
The DCMES
contributor
Element
The
contributor
element is used to represent the name of a person, organization, etc. that played a secondary role in the creation of the content of a Publication.
The use of the
contributor
element is identical to the use of the
creator
element in all other respects, as detailed in the next section.
The DCMES
creator
Element
The
creator
element represents the name of a person, organization, etc. responsible for the creation of the content of a Publication. The
role
property can be
attached
to the element to indicate the function the creator played in the creation of the content.
The following example shows how to represent a
creator
as an author using a MARC relators term.
aut
The
creator
element should contain the name of the creator as a Reading System will present it to a
User
. The
file-as
property may be attached to include a normalized form of the name, and the
alternate-script
property can be used to represent a creator's name in another language or script.
The following example shows the different ways a creator's name can be included to facilitate processing and rendering.
aut
村上 春樹
Murakami, Haruki
If a Publication has more than one creator, each should be included in a separate
creator
element. The order in which to render the
creator
names should be specified using the
display-seq
property.
The following example shows how to indicate the display order for
creator
elements.
aut
1
ill
2
If no means of establishing the primacy of creators is included, Reading Systems must use the order of
creator
elements.
Secondary contributors should be represented using DCMES
contributor
elements.
The DCMES
date
Element
The
date
element must only be used to define the publication date of the
EPUB Publication
. The publication date is not the same as the
last modified date
(the last time the content was changed), which must be included using the
DCTERMS
modified
property.
For compliance with EPUB 2 Reading Systems, the date string should conform to
Date and Time Formats
The following example shows a publication date.
Additional dates should be expressed using the specialized date properties available in the
DCTERMS
vocabulary, or similar.
The publication date may be common to all instances of a Publication or may change from instance to instance (if the Publication gets generated on demand, for example).
Only one
date
element is allowed.
The DCMES
source
Element
The
source
element must only be used to specify the identifier of the source publication from which this
EPUB Publication
is derived.
The following example shows the ISBN identifier for a Publication together with the source ISBN identifier for the print work it was derived from.
15
15
The
source
element allows the print source of the pagination of a Publication to be determined.
Only one
source
element is allowed.
The DCMES
type
Element
The
type
element is used to indicate that the given Publication is of a specialized type (e.g., annotations packaged in EPUB format or a dictionary).
This specification does not define values for this element, however. The development of specialized Publication types, and the assignment of formal identifiers to represent them, will occur independently of this specification.
Only one
type
element is allowed.
3.4.7 The
meta
Element
The
meta
element provides a generic means of including package metadata, allowing the expression of primary metadata about the package or content and refinement of that metadata.
Element Name
meta
Usage
As child of the
metadata
element. Repeatable.
Attributes
property
[required]
property
Refer to
Vocabulary Association Mechanisms
for more information.
refines
[context dependent]
Identifies the expression or resource augmented by this element. The value of the attribute must be a relative IRI
RFC3987
pointing to the resource or element it describes.
The
refines
attribute is optional depending on the type of metadata being expressed. When omitted, the
meta
element defines a
primary expression
id
[optional]
The ID
XML
of this element, which must be unique within the document scope.
scheme
[optional]
property
data type value indicating the source the value of the element is drawn from.
Content Model
Text
Each
meta
element defines a metadata expression, where the
property
attribute defines the statement being made in the expression and the text content of the element represents the assertion.
This specification defines two types of metadata expressions that can be defined using the
meta
element:
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.
subexpression
is one in which the expression defined in the
meta
element enhances the meaning of the expression or resource referenced in its
refines
attribute. A subexpression may refine a media clip, for example, by expressing its duration, or refine a creator or contributor expression by defining the person's role.
Subexpressions are not limited to refining only primary expressions and resources; they may be used to refine the meaning of other subexpressions, thereby creating chains of information.
note
All of the
DCMES
elements represent primary expressions, and permit refinement by
meta
element subexpressions.
This specification
reserves a set of vocabularies
for use in the
property
attribute, but terms from any vocabulary may be used so long as a
prefix is declared
for the vocabulary.
The
scheme
attribute can be used to identify the system or scheme that a
meta
element's value is drawn from. The value of the scheme attribute is a
property
data type that resolves to the resource that defines the scheme.
The following example shows how a subexpression can be attached to an
creator
to indicate it represents an author. The
scheme
indicates the value is drawn from the MARC relators terms.
aut
If a Reading System does not recognize the
scheme
attribute value, it should treat the value of the element as a string.
Reading Systems should ignore all
meta
elements whose
property
attributes define expressions they do not recognize. A Reading System must not fail when encountering unknown expressions.
In order to ensure that a
Package Identifier
can be constructed, the
metadata
element must contain exactly one
meta
element defining a
DCTERMS
modified
property for the Publication. Additional
modified
properties may be included, but they must have a different subject (i.e., they must include a
refines
attribute pointing to an element or resource).
Every
meta
element must express a value that is at least one character in length after whitespace normalization.
Unless an individual property explicitly defines a different whitespace normalization algorithm, Reading Systems must trim all leading and trailing whitespace from the
meta
element values, as defined by the XML specification
XML
, before further processing them.
Examples
The following example represents a more complete set of metadata that typical Publications will contain.
uuid
15
15
main
aut
村上 春樹
Murakami, Haruki
2011-01-01T12:00:00Z
The following example shows an identifier that has been issued by a metadata authority.
xmlns="http://www.idpf.org/2007/opf">
Metadata Authority Inc.
3.4.8 The
meta
Element (OPF2) [OBSOLETE]
The
meta
element defined in
OPF2
has been obsoleted and replaced by the new
meta
element, but may be included as an optional repeatable child of the
metadata
element for forwards compatibility purposes.
EPUB 3 Reading Systems must ignore this element.
3.4.9 The
link
Element
The
link
element is used to associate resources with a Publication, such as metadata records.
Element Name
link
Usage
As a child of
metadata
. Repeatable.
Attributes
href
[required]
An absolute or relative IRI reference
RFC3987
to a resource.
rel
[required]
A space-separated list of
property
values.
id
[optional]
The ID
XML
of this element, which must be unique within the document scope.
refines
[optional]
Identifies the expression or resource augmented by this element. The value of the attribute must be a relative IRI
RFC3987
pointing to the resource or element it describes.
When the
refines
attribute is omitted, the expression applies to the EPUB Publication as a whole.
media-type
[optional]
A media type
RFC2046
that specifies the type and format of the resource referenced by this
link
Content Model
Empty
The
metadata
element may contain zero or more
link
elements.
The
href
attribute of the
link
element identifies the location of the resource — inclusion of which is optional in the container file — and the
rel
attribute defines the nature of the resource (i.e., its relation to the Publication or property specified in the
refines
attribute). Reading Systems are not required to dereference these resources. Refer to
Metadata
link
Properties
for the list of resource types that are recognized by this specification.
Resources identified by the
link
element
href
attribute must not be represented as
item
s in the
manifest
When the
link
element references a metadata record, precedence must be given to metadata defined inline in the Package Document
metadata
element in the case of conflicts.
The optional
refines
attribute can be attached when the referenced resource applies to another metadata item (e.g., to tie an XML Signature
XML DSIG Core
to a metadata authority). The resource applies to the Publication as a whole when the attribute is not present.
If a Reading System does not recognize the relationship of the resource as defined in the
rel
attribute, it should ignore the
link
element.
Examples
The following example shows the
link
element used to associate three metadata resources with the Publication: an ONIX record, an XMP record, and a link to an informational web page. Note that as
foaf
is not a
predefined prefix
, the
metadata extensibility mechanism
is employed to associate the vocabulary.
3.4.10 The
manifest
Element
The
manifest
element provides an exhaustive list of the
Publication Resource
s that constitute the
EPUB Publication
, each represented by an
item
element.
Element name
manifest
Usage
Required second child of
package
, following
metadata
Attributes
id
[optional]
The ID
XML
of this element, which must be unique within the document scope.
Content Model
One or more
item
elements
[required]
note
This specification supports internationalized resource naming, so elements and attributes that reference Publication Resources accept IRIs as their value. For compatibility with older Reading Systems that only accept URIs, resource names should be restricted to the ASCII character set.
3.4.11 The
item
Element
The
item
element represents a
Publication Resource
Element Name
item
Usage
As a child of
manifest
. Repeatable.
Attributes
id
[required]
The ID
XML
of this element, which must be unique within the document scope.
href
[required]
An IRI
RFC3987
specifying the location of the Publication Resource described by this
item
media-type
[required]
A media type
RFC2046
that specifies the type and format of the Publication Resource described by this
item
fallback
[conditionally required]
An IDREF
XML
that identifies the fallback for a non-Core Media Type.
Refer to
Manifest Fallbacks
for more information.
properties
[optional]
A space-separated list of
property
values.
Refer to
Manifest
item
Properties
for a set of properties defined by this specification.
media-overlay
[optional]
An IDREF
XML
that identifies the
Media Overlay Document
for the resource described by this
item
Refer to
Packaging
MediaOverlays30
for more information.
Content Model
Empty
Each
item
element in the
manifest
identifies a
Publication Resource
by the IRI provided in its
href
attribute. The IRI may be absolute or relative. In the case of relative IRIs, Reading Systems must use the IRI of the Package Document as the base when resolving these to absolute IRIs. The resulting absolute IRI must be unique within the
manifest
scope.
All Publication Resources must be referenced from the
manifest
, regardless of whether they are included in the
EPUB Container
or made available remotely. Refer to
Publication Resource Locations
for media type-specific requirements regarding resource locations.
The Publication Resource identified by an
item
element must conform to the applicable specification(s) as inferred from the MIME media type provided in the
media-type
attribute.
Core Media Type Resource
s must use the media type designated in
EPUB Core Media Types
All
Foreign Resource
s must provide a fallback as defined in
Restrictions and Fallbacks
All Publication Resources must declare any applicable descriptive metadata properties as defined in
Manifest
item
Properties
via the
item
element
properties
attribute. Exactly one
item
must be declared as the
EPUB Navigation Document
using the
nav
property.
Reading Systems must ignore all descriptive metadata properties that they do not recognize.
The manifest is not self-referencing: it must not include an
item
element that refers to the Package Document itself.
note
The order of
item
elements in the manifest is not significant. The presentation sequence of content documents is provided in the
spine
Examples
The following example shows a
manifest
that only contains
Core Media Type Resource
s.
The following example shows a
manifest
that references two
Foreign Resource
s, and therefore uses the
fallback chain mechanism
to supply content alternatives. The fallback chain terminates with a Core Media Type.
media-type="application/docbook+xml"
fallback="fall1"/>
media-type="application/z3986-auth+xml"
fallback="fall2" />
media-type="application/xhtml+xml"/>
note
Refer also to the
Manifest item properties examples
for use of the
properties
attribute.
3.4.12 The
spine
Element
The
spine
element defines the default reading order of the
EPUB Publication
content by defining an ordered list of
manifest
item
references
Element name
spine
Usage
Required third child of
package
, following
manifest
Attributes
id
[optional]
The ID
XML
of this element, which must be unique within the document scope.
toc
[optional]
An IDREF
XML
that identifies the manifest
item
that represents the superseded
NCX
Refer to
NCX Superseded
for more information.
page-progression-direction
[optional]
The global direction in which the Publication content flows.
Allowed values are
ltr
(left-to-right),
rtl
(right-to-left) and
default
When the
default
value is specified, the Author is expressing no preference and the Reading System may chose the rendering direction. This value must be assumed when the attribute is not specified.
Content Model
Multiple
itemref
elements
[required]
The
spine
represents an ordered subset of the Publication Resources listed in the
manifest
, with content items not being referenced being ancillary to those that do.
Reading Systems must provide a means of rendering a Publication in the order defined by the
spine
, which includes: 1) recognizing the first primary (
linear='yes'
item
in the
spine
as the beginning of the main reading order of the Publication; and, 2) rendering successive primary items in the order given in the
spine
note
Although the
page-progression-direction
attribute sets the global flow direction for a Publication, individual Content Documents and parts of Content Documents may override this setting (e.g., via the
direction
and
writing-mode
CSS properties). Reading Systems may also provide mechanisms to override the default direction (e.g., buttons or settings that allow the application of alternate style sheets).
NCX Superseded
The NCX feature defined in
OPF2
is superseded by the
EPUB Navigation Document
ContentDocs30
. EPUB 3 Publications may include an NCX (as defined in OPF 2.0.1) for EPUB 2 Reading System forwards compatibility purposes, but EPUB 3 Reading Systems must ignore the NCX in favor of the EPUB Navigation Document.
note
As the EPUB 2 NCX and the EPUB 3 Navigation Document use different mechanisms for identification in the Package Document (the spine
toc
attribute and the
nav
property on the manifest
item
element, respectively) they can co-exist without conflict in an EPUB 3 Publication.
3.4.13 The
itemref
Element
The child
itemref
elements of the
spine
represent a sequential list of
Publication Resource
s (
typically
EPUB Content Document
s). The order of the
itemref
elements defines the default reading order of the Publication.
Element Name
itemref
Usage
As a child of
spine
. Repeatable.
Attributes
idref
[required]
An IDREF
XML
that identifies a manifest
item
linear
[optional]
Specifies whether the referenced content is primary.
The value of the attribute must be
yes
or
no
. The default value is
yes
id
[optional]
The ID
XML
of this element, which must be unique within the document scope.
properties
[optional]
A space-separated list of
property
values.
Refer to
Spine
itemref
Properties
for a set of properties defined by this specification.
Content Model
Empty
Each
itemref
element must reference an
item
in the
manifest
via its
idref
attribute.
Each referenced manifest
item
must be either a) an
EPUB Content Document
or b) another type of
Publication Resource
which,
regardless of whether it is a
Core Media Type Resource
or a
Foreign Resource
, must include an EPUB Content Document in its
fallback chain
note
Although the
EPUB Navigation Document
is
required in EPUB Publications
, it is optional to include it in the
spine
The
itemref
element
linear
attribute indicates whether referenced item is considered primary (
yes
) or auxiliary (
no
) in the
spine
. This attribute may be used to enable Reading Systems to distinguish presentation of body content from supplementary content which might be, for example, presented in a popup window or omitted from an aural rendition.
Any applicable descriptive metadata properties, such as those defined in the
Spine
itemref
Properties
, should be declared via the
properties
attribute.
Reading Systems must ignore all metadata properties expressed in the
properties
attribute that they do not recognize.
Examples
The following example shows a
spine
element corresponding to
the manifest example above
3.4.14 The
guide
Element [DEPRECATED]
The
guide
element
OPF2
is deprecated in favor of the
landmarks
feature in the
EPUB Navigation Document
. Refer to
The landmarks nav Element
ContentDocs30
for more information.
Authors may include the
guide
element in the Package Document for EPUB 2 Reading System forwards compatibility purposes. EPUB 3 Reading Systems must ignore the
guide
element when provided in EPUB 3 Publications whose
EPUB Navigation Document
includes the
landmarks
feature.
3.4.15 The
bindings
Element
The
bindings
element defines a set of custom handlers for media types not supported by this specification.
Element Name
bindings
Usage
Optional fourth or fifth child of
package
, following
spine
or
guide
Attributes
None.
Content Model
One or more
mediaType
elements
[required]
The
package
element may contain at most one
bindings
element.
The
bindings
element provides a means for Authors to include more sophisticated fallbacks than would otherwise be possible with the
HTML5
object
element's intrinsic fallback mechanisms. When present, Reading Systems that support scripting must utilize the
bindings
element to handle
object
elements that reference unsupported media types.
Each of the
bindings
element's child
mediaType
elements defines a unique handler for one of the foreign media types referenced in the Publication's
XHTML Content Document
s.
When an unsupported media type is encountered during processing of a document, the Reading System must look up the handler in the
bindings
element by checking the
media-type
attribute of each
mediaType
element for a match (and before attempting any other type of
fallback processing
). If a match is found, the XHTML Content Document referenced in the element's
handler
attribute must be instantiated instead of the referenced resource. If no match is found, the Reading System should continue with normal fallback processing (i.e., check for an intrinsic fallback for the
object
).
The Reading System must instantiate the designated handler as if it had been referenced from the
object
element's
data
attribute with the following parameters:
src
the value of which must be an IRI
RFC3987
to the resource (i.e., the value of the
object
element's
data
attribute).
type
the value of which must be the resource media type (i.e., the value of the
object
element's
media-type
attribute).
Any additional
param
children of the
object
element must be similarly added as parameters using the
param
's
name
attribute as the new parameter name and its
value
attribute as the new value.
For example, the following
object
element containing a foreign media type:
would result in the following query string being sent to the handler XHTML Content Document after processing:
src=horse.ogg&type=audio/ogg&autoplay=false
All IRI reserved characters, plus the characters
space
and
, in the generated query string must be encoded and decoded as per
RFC3987
object
elements that reference media types handled by the
bindings
element are only processed in
spine
-referenced XHTML Content Documents (i.e., they are ignored in
container-constrained scripting contexts
).
Example
The following partial example illustrates how bindings can be used to provide a slideshow.
Consider a Publication with the following Package Document:
media-type="image/jpeg"/>
media-type="application/xhtml+xml"/>
media-type="application/xhtml+xml"
properties="scripted"/>
media-type="application/x-demo-slideshow"/>
and the following content in the file
content.xhtml
and the following content in the file
slideshow.xml
Depending on the capabilities of the
User
's Reading System, they will see one of the following renditions of the slideshow:
If the Reading System supports the native slideshow format, it will render a rotating set of images as specified in
slideshow.xml
If the Reading System cannot support the slideshow media type but supports scripting, it can check the
bindings
element in the Package Document for a scripted fallback. There it will find a reference to the
item
element containing the handler document (
impl.xhtml
). The Reading System can now load this document to render a JavaScripted equivalent of the slideshow (source not shown).
If the Reading System does not support the slideshow media type and also does not support scripting, it will use the fallback images specified in the
object
element to show a static set of all the images.
3.4.16 The
mediaType
Element
The
mediaType
element associates a
Foreign Resource
media type with a handler
XHTML Content Document
Element Name
mediaType
Usage
As a child of
bindings
. Repeatable.
Attributes
media-type
[required]
A media type
RFC2046
that specifies the type and format of the resource to be handled.
handler
[required]
An IDREF
XML
that identifies the manifest XHTML Content Document to be invoked to handle content of the type specified in this element
Content Model
Empty
Each child
mediaType
of a
bindings
element must define a unique content type in its
media-type
attribute, and the media type specified must not be a Core Media Type.
The required
handler
attribute must reference the ID
XML
of an
item
in the
manifest
of the default implementation for this media type. The referenced
item
must be an XHTML Content Document.
All XHTML Content Documents designated as handlers must have the
scripted
property set in their
manifest
item
's
properties
attribute.
4 Package Metadata
4.1 Publication Identifiers
4.1.1 Unique Identifier
The Package Document's author is responsible for including a primary identifier that is unique to one and only one particular
EPUB Publication
. This
Unique Identifier
, whether chosen or assigned, must be stored in a
dc:identifier
element
in the Package metadata and be referenced as the Unique Identifier in the
package
element
unique-identifier
attribute
Although not static, changes to the Unique Identifier for a Publication should be made as infrequently as possible. New identifiers should not be issued when updating metadata, fixing errata or making other minor changes to the Publication.
4.1.2 Package Identifier
The
Unique Identifier
of an
EPUB Publication
typically should not change with each minor revision to the package or its contents, as Unique Identifiers are intended to have maximal persistence both for referencing and distribution purposes. Each release of a Publication normally requires that the new version be uniquely identifiable, however, which results in the contradictory need for reliable Unique Identifiers that are changeable.
To redress this problem of identifying minor modifications and releases without changing the Unique Identifier, this specification defines the semantics for a Package Identifier, or means of distinguishing and sequentially ordering Publications with the same Unique Identifier. The Package Identifier is not an actual property in the package
metadata
section, but is a value that can be obtained from two required pieces of metadata: the Unique Identifier and the last modification date of the Publication.
When the taken together, the combined value represents a unique identity that can be used to distinguish any particular version of an EPUB
Manifestation
from another. To ensure that a Package Identifier can be constructed, the Publication must include exactly one
DCTERMS
modified
property containing the last modification date (see
meta
). The value of this property must be an XML Schema
XSD-DATATYPES
dateTime conformant date of the form:
CCYY-MM-DDThh:mm:ssZ
The modification date must be expressed in Coordinated Universal Time (UTC) and must be terminated by the
time zone indicator.
Although not a part of the package metadata, for referencing and other purposes this specification requires that all string representations of the identifier be constructed using the at sign (
) as the separator (i.e., of the form "id
date"). Whitespace must not be included when concatenating the strings.
The following example shows how a Unique Identifier and modification date are combined to form the Package Identifier.
2011-01-01T12:00:00Z
results in the Package ID:
urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809@2011-01-01T12:00:00Z
Note that it is possible that the separator character may occur in the Unique Identifier, as these identifiers may be any string value. The Package Identifier consequently must be split on the last instance of the at sign when decomposing it into its component parts.
The Package Identifier does not supersede the Unique Identifier, but represents the means by which different versions of the same Publication can be distinguished and identified in distribution channels and by Reading Systems. The sequential, chronological order inherent in the required format of the timestamp also places Publications in order without requiring knowledge of the exact identifier that came before.
The Package Identifier consequently allows a set of Publications to be inspected to determine if they represent the same version of the same Publication, different versions of a single Publication, or any combination of differing and similar Publications.
4.2 Vocabulary Association Mechanisms
4.2.1 Overview
This section is informative
The
property
properties
rel
and
scheme
attributes use the
property data type
to represent terms from metadata vocabularies. Similar to a CURIE
RDFa10
, the property data type represents an IRI
RFC3987
in compact form and simplifies the authoring of metadata from standardized vocabularies.
A property value is an expression that consists of a prefix and a reference, where the prefix — whether literal or implied — is a shorthand mapping of an IRI that typically resolves to a term vocabulary. When the prefix is converted to its IRI representation and combined with the reference, the resulting IRI normally resolves to a fragment within that vocabulary that contains human- and/or machine-readable information about the term.
To assist Reading Systems in processing property values, the means of establishing the IRI a prefix maps to is required, and this specification defines three such mechanisms:
default vocabulary
— defines the mapping when a property value does not include a prefix;
a set of
reserved prefixes
— these mappings are predefined (i.e., all Reading Systems recognize them) and can be used without having to be declared; and
the
prefix
attribute
— a declarative means of creating new prefix mappings on the root
package
element.
4.2.2 Default Vocabulary
The default vocabulary is a vocabulary that does not require a prefix to be declared in order to use its terms in package metadata, and whose terms must always be unprefixed.
To facilitate the inclusion of package metadata, this specification defines the
Package Metadata Vocabulary
as the default vocabulary for Package Documents.
If a
property
value does not include a prefix, the IRI
RFC3987
stem
must be used to generate the resulting IRI.
The IRI associated with the Package Metadata Vocabulary must not be assigned a prefix using the
prefix
attribute
4.2.3 Reserved Vocabularies
This specification exclusively defines the following set of prefixes for use in package metadata.
Reserved metadata prefixes
Prefix
IRI
dcterms
marc
media
onix
xsd
The prefixes listed in the previous table must not be redeclared using the
prefix
attribute
declaration mechanism. Similarly, the IRIs associated with each prefix must not be assigned to another prefix.
4.2.4 The
prefix
Attribute
The
prefix
attribute defines additional prefix mappings not
reserved
by the specification.
The value of the
prefix
attribute is a whitespace-separated list of one or more prefix-to-IRI mappings of the form:
(EBNF productions
ISO/IEC 14977
prefixes
mapping
, {
whitespace
, {
whitespace
} ,
mapping
} ;
mapping
prefix
, ":" ,
space
, {
space
} , ? xsd:anyURI ? ;
prefix
? xsd:NCName ? ;
space
#x20 ;
whitespace
(#x20 | #x9 | #xD | #xA) ;
The following example shows prefixes for the Friend of a Friend (
foaf
) and DBPedia (
dbp
) vocabularies being declared using the
prefix
attribute.
dbp: http://dbpedia.org/ontology/">
The
prefix
attribute must not be used to redefine the
default vocabulary
or the
predefined prefixes
The prefix '_' is reserved for future compatibility with RDFa
RDFa10
processing, so must not be defined.
4.2.5 The property Data Type
4.2.5.1 Syntax
The property data type is a compact means of expressing an IRI
RFC3987
and consists of an optional prefix separated from a reference by a colon.
(EBNF productions
ISO/IEC 14977
property
prefix
, ":" ] ,
reference
prefix
? xsd:NCName ? ;
reference
? irelative-ref ? ;
/* as defined in
RFC3987
*/
The property data type is derived from the CURIE data type defined in
RDFa10
, and represents a subset of CURIEs.
The following example shows a property value composed of the prefix
dcterms
and the reference
modified
2011-01-01T12:00:00Z
After
processing
, this property would expand to the following IRI:
as the
dcterms:
prefix is a
reserved prefix
that maps to the IRI
When a prefix is omitted from the property value, the expressed reference represents a term from the
default vocabulary
The following example shows a property value taken from the default vocabulary.
aut
This property would expand to:
when the IRI for the default vocabulary is concatenated with the reference.
An empty string does not represent a valid property value, even though it is valid to the definition above.
4.2.5.2 Processing
A Reading System must use the following rules to create an IRI
RFC3987
from a property:
If the property consists only of a reference, the IRI is obtained by concatenating the IRI stem associated with the
default vocabulary
to the reference.
If the property consists of a prefix and reference, the IRI is obtained by concatenating the IRI stem associated with the prefix to the reference. If no matching prefix has been defined, the property is invalid.
The resulting IRI must be valid to
RFC3987
. Reading Systems are not required to resolve this IRI, however.
4.3 Package Metadata Vocabulary
4.3.1 Overview
This section is informative
The following sections both define a set of properties for use in package metadata and constitute a referenceable vocabulary. This vocabulary is the
default vocabulary
reserved by this specification for the use of unprefixed terms in package metadata.
The properties defined in this vocabulary are referenceable using the base IRI
note
Property usage examples in the following sections have been drawn from the
metadata
and
meta
examples whenever possible. Refer to those examples for fuller context.
4.3.2 Metadata
meta
Properties
The
meta
element properties enhance Publication metadata by providing additional level(s) of detail.
These properties must reference the expression or resource they augment in the
refines
attribute on their parent
meta
element.
The following tables detail the available properties.
alternate-script
Description:
The
alternate-script
property provides an alternate expression of the associated property value in a language and script identified by the
xml:lang
attribute.
This property is typically attached to
creator
and
title
properties for internationalization purposes.
Allowed value(s):
xsd:string
Cardinality:
In the metadata section:
zero or more
Attached to other metadata:
zero or one
Extends:
All properties.
Example:
村上 春樹
display-seq
Description:
The
display-seq
property indicates the numeric position in which to display the current property relative to identical metadata properties (e.g., to indicate the order in which to render multiple
title
s).
When the
display-seq
property is attached to some, but not all, of the members in a set, only the elements identified as having a sequence should be included in any rendering.
Allowed value(s):
xsd:unsignedInt
Cardinality:
In the metadata section:
zero or more
Attached to other metadata:
zero or one
Extends:
All properties.
Example:
1
file-as
Description:
The
file-as
property provides the normalized form of the associated property for sorting.
Allowed value(s):
xsd:string
Cardinality:
In the metadata section:
zero or more
Attached to other metadata:
zero or one
Extends:
All properties.
Example:
Murakami, Haruki
group-position
Description:
The
group-position
property indicates the numeric position in which the Publication is ordered relative to other works belonging to the same group (whether all EPUBs or not).
The
group-position
property can be attached to any metadata property that establishes the group (such as a series title).
A Publication can belong to more than one group.
Allowed value(s):
A single
xsd:unsignedInt
or series of decimal-separated numbers (e.g.,
or
2.2.1
).
Cardinality:
In the metadata section:
zero or more
Attached to other metadata:
zero or one
Extends:
All properties.
Example:
2
identifier-type
Description:
The
identifier-type
property indicates the form or nature of an
identifier
When the
identifier-type
value is drawn from a code list or other formal enumeration, the
scheme
attribute should be attached to identify its source.
Allowed value(s):
xsd:string
Extends:
identifier
Cardinality:
In the metadata section:
zero or more
Attached to other metadata:
zero or one
Example:
15
meta-auth
Description:
The
meta-auth
property provides the name of a party or authority responsible for an instance of package metadata.
Allowed value(s):
xsd:string
Cardinality:
In the metadata section:
zero or more
Attached to other metadata:
zero or one
Extends:
All properties.
Example:
Metadata Authority Inc.
role
Description:
The
role
property describes the nature of work performed by a
creator
or
contributor
(e.g., that the person is the author or editor of a work).
When the
role
value is drawn from a code list or other formal enumeration, the
scheme
attribute should be attached to identify its source.
Allowed value(s):
xsd:string
Cardinality:
In the metadata section:
zero or more
Attached to other metadata:
zero or one
Extends:
contributor
creator
Example:
aut
title-type
Description:
The
title-type
property indicates the form or nature of a
title
When the
title-type
value is drawn from a code list or other formal enumeration, the
scheme
attribute should be attached to identify its source. When a scheme is not specified, Reading Systems should recognize the following title type values:
main
subtitle
short
collection
edition
and
expanded
Allowed value(s):
xsd:string
Extends:
title
Cardinality:
In the metadata section:
zero or more
Attached to other metadata:
zero or one
Example:
main
4.3.3 Metadata
link
Properties
The following tables define properties for use in the
metadata
link
element
rel
attribute.
marc21xml-record
Description:
The
marc21xml-record
property indicates the referenced resource is a MARC21 record
MARC21XML
Cardinality:
Zero or one
Extends:
Only applies to the Publication. Must not be used when the
refines
attribute is present.
Example:
mods-record
Description:
The
mods-record
property indicates the referenced resource is a MODS record
MODS
Cardinality:
Zero or one
Extends:
Only applies to the Publication. Must not be used when the
refines
attribute is present.
Example:
onix-record
Description:
The
onix-record
property indicates the referenced resource is an ONIX record
ONIX
Cardinality:
Zero or one
Extends:
Only applies to the Publication. Must not be used when the
refines
attribute is present.
Example:
xml-signature
Description:
The
xml-signature
property indicates the referenced resource contains an XML Signature
XML DSIG Core
for the Publication or associated property.
The
link
element's
href
attribute typically references a specific
signature
element in the Signatures.xml file
OCF3
via a fragment identifier.
Cardinality:
Zero or more
Extends:
All properties.
Example:
xmp-record
Description:
The
xmp-record
property indicates the referenced resource is an XMP record
XMP
Cardinality:
Zero or one
Extends:
Only applies to the Publication. Must not be used when the
refines
attribute is present.
Example:
4.3.4 Manifest
item
Properties
The following tables define properties for use in the
manifest
item
element
properties
attribute.
The
Applies to
field indicates which Publication Resource type(s) the given property may be specified on, the
Cardinality
field indicates the number of times the property must appear within the Package Document scope, and the
Usage
field indicates usage conditions.
cover-image
Description:
The
cover-image
property identifies the described Publication Resource as the cover image for the Publication.
Applies to:
All
raster and vector image types
Cardinality:
Zero or one
Usage:
Optional.
mathml
Description:
The
mathml
property indicates that the described Publication Resource contains one or more instances of MathML markup.
Applies to:
EPUB Content Document
Cardinality:
Zero or more
Usage:
Must be set if and only if the criterion specified in
Description
above is met.
nav
Description:
The
nav
property indicates that the described Publication Resource constitutes the
EPUB Navigation Document
of the Publication.
Applies to:
The
EPUB Navigation Document
Cardinality:
Exactly one
Usage:
Required.
remote-resources
Description:
The
remote-resources
property indicates that the described Publication Resource contains one or more internal references to other Publication Resources that are located outside of the
EPUB Container
(refer to
Publication Resource Locations
for more information).
Applies to:
All Publication Resources with the capability of internal referencing (e.g.,
XHTML Content Document
s,
SVG Content Document
s,
EPUB Style Sheet
s and
Media Overlay Document
s).
Cardinality:
Zero or more
Usage:
Must be set if and only if the criterion specified in
Description
above is met.
scripted
Description:
The
scripted
property indicates that the described Publication Resource is a
Scripted Content Document
(i.e., contains scripted content and/or elements from
HTML5 forms
).
Applies to:
EPUB Content Document
Cardinality:
Zero or more
Usage:
Must be set if and only if the criterion specified in
Description
above is met.
svg
Description:
The
svg
property indicates that the described Publication Resource contains one or more instances of SVG markup.
Applies to:
XHTML Content Document
s; the value is implied for
SVG Content Document
s.
Cardinality:
Zero or more
Usage:
Must be set if and only if the criterion specified in
Description
above is met.
switch
Description:
The
switch
property indicates that the described Publication Resource contains one or more instances of the
epub:switch
element.
Applies to:
XHTML Content Document
s.
Cardinality:
Zero or more
Usage:
Must be set if and only if the criterion specified in
Description
above is met.
The
mathml
remote-resources
scripted
svg
and
switch
properties must be specified whenever the resource referenced by an
item
matches their respective definitions. These properties do not apply recursively to content included into a resource (e.g., via the HTML5
iframe
element). For example, if a non-scripted XHTML Content Document embeds a scripted Content Document, only the embedded document's manifest
item
properties
attribute will have the
scripted
value.
Examples
The following example shows a
manifest
item
element that represents the
EPUB Navigation Document
of a Publication.
The following example shows a
manifest
item
element that represents the cover image of a Publication.
The following example shows a
manifest
item
element representing a
Scripted Content Document
that also contains embedded
MathML
4.3.5 Spine
itemref
Properties
The following tables define properties for use in the
itemref
element
properties
attribute.
The
Cardinality
field indicates the number of times the property must appear within the Package Document scope, and the
Usage
field indicates usage conditions.
page-spread-left
Description:
The
page-spread-left
property indicates that the first page of the associated
item
's
EPUB Content Document
represents the left-hand side of a two-page spread.
Cardinality:
Zero or more
Usage:
Optional. This property must not be specified on an
itemref
that also specifies the
page-spread-right
property.
page-spread-right
Description:
The
page-spread-right
property indicates that the first page of the associated
item
's
EPUB Content Document
represents the right-hand side of a two-page spread.
Cardinality:
Zero or more
Usage:
Optional. This property must not be specified on an
itemref
that also specifies the
page-spread-left
property.
Examples
The following example shows how a two-page spread of a map might be indicated in the
spine
5 Publication Resources
5.1 Core Media Types
The following table lists the
EPUB 3 Core Media Types
. When a
Publication Resource
conforms to a Core Media Type specification, it is a
Core Media Type Resource
and can be included in the Publication without the provision of fallbacks (refer to
Restrictions and Fallbacks
for more information).
The columns in the table represent the following information:
Media Type
The MIME media type
RFC2046
used to represent the given Publication Resource in the
manifest
Content Type Definition
The specification to which the given
Core Media Type Resource
must conform.
Applies to
The Publication Resource type(s) that the Media Type and Content Type Definition applies to.
EPUB Core Media Types
Media Type
Content Type Definition
Applies to
Image Types
image/gif
GIF
GIF Images
image/jpeg
JPEG
JPEG Images
image/png
PNG
PNG Images
image/svg+xml
SVG Content Documents
ContentDocs30
SVG documents
Application Types
application/xhtml+xml
XHTML Content Documents
ContentDocs30
XHTML Content Document
s and the
EPUB Navigation Document
application/x-dtbncx+xml
OPF2
The
superseded
NCX
application/vnd.ms-opentype
OpenType
OpenType fonts
application/font-woff
WOFF
WOFF fonts
application/smil+xml
MediaOverlays30
EPUB Media Overlay documents
application/pls+xml
PLS
Text-to-Speech (TTS)
Pronunciation lexicons
Audio Types
audio/mpeg
MP3
MP3 audio
audio/mp4
AAC LC
MP4
AAC LC audio using MP4 container
Text Types
text/css
EPUB Style Sheets
ContentDocs30
EPUB Style Sheet
s.
text/javascript
RFC4329
Scripts
note
This specification does not define any video codecs as Core Media Types. Refer to the
note in EPUB Publications — Reading System Conformance
above for informative recommendations on support for video codecs in EPUB Publications.
5.2 Restrictions and Fallbacks
5.2.1 Foreign Resource Restrictions
All
Publication Resource
s of an
EPUB Publication
must be
Core Media Type Resource
s or must provide a Core Media Type fallback. The cases in which
Foreign Resource
may be used, and the requirement and rules for Core Media Type fallback provision in such cases, are detailed below.
Intrinsic Fallback in EPUB Content Documents
Foreign Resources may be referenced from EPUB Content Document elements that have explicit intrinsic fallback mechanisms (e.g., the
HTML5
object
canvas
audio
and
video
elements). A Core Media Type resource must be provided via the given element's intrinsic fallback mechanism in such cases.
For the
HTML5
video
element, the image referenced by the
poster
attribute and text content embedded within the
video
element are also considered valid Core Media Type fallbacks in addition to the
video
element's intrinsic fallback capabilities. For the purpose of providing a last resort fallback for Reading Systems that do not support video or the given video format(s), at least one of these should be included with each occurrence of the
video
element.
For the
HTML5
audio
element, text content embedded within the element is also considered a valid Core Media Type fallback in addition to the
audio
element's intrinsic fallback capabilities. For the purpose of providing a last resort fallback for Reading Systems that do not support audio, embedded text content should be included with each occurrence of the
audio
element.
In this version of this specification, the
HTML5
track
element is exempt from the
Core Media Type usage rule
: Foreign Resources may be referenced from
track
without the provision of a Core Media Type fallback.
Intrinsic Fallback in EPUB Style Sheets
Fonts embedded in Content Documents or EPUB Style Sheets using the
@font-face
mechanism may be Foreign Resources. Reading Systems must use the
rules for matching font styles
CSS3Fonts
when identifying a fallback for an unsupported font type.
Spine Resources
Foreign Resources may be referenced directly from
spine
itemref
elements, and in this case
Manifest fallbacks
must be provided.
5.2.2 Manifest Fallbacks
Fallbacks must be provided for each Publication Resource referenced in a
spine
itemref
element that is not an
EPUB Content Document
Fallbacks are provided using the
fallback
attribute on the
manifest
item
element that represents the Publication Resource. The
fallback
attribute's IDREF
XML
value must resolve to another
item
in the
manifest
. This fallback
item
may itself specify another fallback
item
, and so on.
The ordered list of all the ID references that can be reached starting from a given item's
fallback
attribute represents the
fallback chain
for that item. The order of the resources in the fallback chain represents the Authors' preferred fallback order.
A Reading System that does not support the Media Type of a given Publication Resource must traverse the fallback chain until it has identified at least one supported Publication Resource to be used in place of the unsupported resource. If the Reading System supports multiple Publication Resources in the fallback chain, it may select the resource to use based on specific
properties
of that resource, otherwise it should honor the Authors' preferred fallback order.
A fallback chain must contain at least one
EPUB Content Document
and must not contain any circular- or self-references to
item
s in the chain.
Fallbacks may also be provided for
Top-level Content Document
s that are EPUB Content Documents; a Reading System may choose to utilize such fallbacks in order to find the optimal version of a Content Document to render in a given context. An example of when this feature can be utilized is when providing
fallbacks for scripted content
ContentDocs30
5.3 Publication Resource Locations
All
Publication Resource
s must be located in the
EPUB Container
, with the following exceptions:
Audio resources
may be located in the Container or remotely.
Video resources may be located in the Container or remotely.
Authors should prefer locating audio and video resources in the Container to allow the user access to the entire presentation regardless of connectivity status.
note
The above rules for Publication Resource locations apply regardless of whether the given resource is a
Core Media Type Resource
or a
Foreign Resource
note
The inclusion of remote resources in an
EPUB Publication
is indicated via the
remote-resources
property on the
manifest
item
element.
5.4 XML Conformance
Any
Publication Resource
that is an XML-Based Media Type must meet the following constraints:
It must be a conformant XML 1.0 Document as defined in
Conformance of Documents
XMLNS
External identifiers
must not appear in the document type declaration
XML
It must not make use of XInclude
XInclude
It must be encoded in UTF-8 or UTF-16
Unicode
The above constraints apply regardless of whether the given Publication Resource is a
Core Media Type Resource
or a
Foreign Resource
Appendix A. Package Document Schema
The schema for Package Documents is available at
This schema is normative.
note
Validation using this schema will require a processor that supports
NVDL
RelaxNG
and
ISOSchematron
Note, however, that the NVDL schema layer can be substituted by a multi-pass validation using the embedded RELAX NG and ISO Schematron schemas alone.
Appendix B. The
application/oebps-package+xml
Media Type
This appendix registers the media type
application/oebps-package+xml
for the EPUB Package Document. This registration supersedes
RFC4839
The Package Document is an XML file that describes an EPUB Publication
Publications30
. It identifies the resources in the Publication and provides metadata information. The Package Document and its related standards are maintained and defined by the International Digital Publishing Forum (IDPF).
MIME media type name:
application
MIME subtype name:
oebps-package+xml
Required parameters:
None.
Optional parameters:
None.
Encoding considerations:
Package Documents are UTF-8 or UTF-16 encoded XML.
Security considerations:
Package Documents contain well-formed XML conforming to the XML 1.0 specification.
Clearly, it is possible to author malicious files which, for example, contain malformed data. Most XML parsers protect themselves from such attacks by rigorously enforcing conformance.
All processors that read Package Documents should rigorously check the size and validity of data retrieved.
There is no current provision in the EPUB Publications 3.0 standard for encryption, signing, or authentication within the Package Document format.
Interoperability considerations:
None.
Published specification:
This media type registration is for the EPUB Package Document, as described by the EPUB Publications 3.0 specification located at
The EPUB Publications 3.0 specification supersedes the Open Packaging Format 2.0.1 specification, which is located at
and which also uses the
application/oepbs-package+xml
media type.
Applications which use this media type:
This media type is in wide use for the distribution of ebooks in the EPUB format. The following list of applications is not exhaustive.
Adobe Digital Editions
Aldiko
Azardi
Apple iBooks
Barnes & Noble Nook
Calibre
Google Books
Ibis Reader
MobiPocket reader
Sony Reader
Stanza
Additional information:
Magic number(s):
none
File extension(s):
.opf
Macintosh File Type Code(s):
TEXT
Fragment Identifiers:
The IDPF maintains a registry of linking schemes at
. Some of these schemes define custom fragment identifiers that resolve to
application/oebps-package+xml
documents.
Person & email address to contact for further information:
William McCoy,
[email protected]
Intended usage:
COMMON
Author/Change controller:
International Digital Publishing Forum (
Appendix C. Acknowledgements and Contributors
This appendix is informative
EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.
The EPUB 3 specifications were prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group, operating under a charter approved by the membership in May, 2010 under the leadership of:
Gylling
Markus
(DAISY Consortium)
Chair
Conboy
Garth
(Google Inc.)
Vice-chair
Duga
Brady
(Google Inc.)
Vice-chair, Subgroup Lead
McCoy
Bill
(International Digital Publishing Forum (IDPF))
Secretary
Kasdorf
Bill
(Apex CoVantage)
Subgroup Lead
MURATA
Makoto
(JEPA EPUB Study Group)
Subgroup Lead
Sorotokin
Peter
(Adobe)
Subgroup Lead
Active members of the working group included:
IDPF Members
Abrams
Willie
(Ingram Digital)
Acton
Daniel
(Google)
Allesi
Ana Maria
(HarperCollins)
Amos
Dan
(DNAML (DNL eBooks))
Arany
Steve
(John Wiley & Sons)
Artin
Michael
(Barnes & Noble)
Badger
Brandon
(Google)
Ballard
Kevin
(Apple Inc.)
Beard
Elliot
(HarperCollins)
Belfanti
Paul
(Pearson)
Bell
Graham
(EDItEUR)
Bide
Mark
(EDItEUR)
Bogaty
Nick
(Adobe)
Bowers
Micah
(Bluefire Productions)
Brantley
Peter
(Internet Archive)
Breglio
Melissa
(Apple Inc.)
Broome
Karen
(Sony)
Brugge
John
(Benetech)
Carbonell
Oliver
(Sony)
Chang
Phobos
(Chinese Foundation for Digitization Technology)
Chen
Mei-Li
(Institute for Information Industry)
Chen
Peter
(ITRI)
Choi
Soo
(HarperCollins)
Chow
King-Wai
(ASTRI (Hong Kong Applied Science & Technology Research Institute))
Clutter
Mat
(Random House)
Conboy
Garth
(Google)
Cramer
Dave
(Hachette Book Group)
Cronin
Margot
(Bowker)
Daly
Liza
(Threepress)
De Meulemeester
Eric
(Jouve/Publishing Dimensions)
DeMeglio
Marisa
(DAISY Consortium)
Deltour
Romain
(DAISY Consortium)
Dougherty
Casey
(Apple Inc.)
Drake
Jama
(Impelsys)
Duga
Brady
(Google)
Elliott
Ray
(Crossway)
Fahlgren
Keith
(Threepress)
Fain
Guy
(Crossway)
Freese
Eric
(Aptara)
Gardeur
Hadrien
(Feedbooks)
Gold
Eric
(Digital Divide Data)
Goodwin
Jonathan
(Appfoundry)
Gopinath
Anith
(Impelsys)
Gosling
Andreas
(Penguin)
Grazioli
Frank
(John Wiley & Sons)
Gunn
Dave
(RNIB)
Gylling
Markus
(DAISY Consortium)
Haas
Matt
(Pearson)
Hadfield
Tom
(CourseSmart)
Hagino
Masaaki
(Voyager Japan)
Hawkins
Kevin
(University of Michigan Library)
Hayashi
Junichi
(Voyager Japan)
Heiberger
Richard
(HarperCollins)
Hepp
Mike
(Dartmouth Journal Services)
Herren
Matthew
(BlankPage)
Hisashi
Saiga
(Sharp)
Hoda
Hisashi
(Voyager Japan)
Howard
William
(Easypress)
Hughes
Dan
(Liguori Publications)
Hulse
Leslie
(HarperCollins)
Imsieke
Gerrit
(le-tex)
Jain
Anupam
(Innodata Isogen)
Jie
Fan
(Gansu DUZHE Digital Sci&Tech)
Johnson
Rick
(Ingram Digital)
Jung
Kanghee
(Incube Technologies)
Kakar
Samir
(Aptara)
Kanai
Takeshi
(Sony)
Kasdorf
Bill
(Apex CoVantage)
Kasher
Bob
(BookMasters and Newgen Imaging)
Kato
Kazuyuki
(East Co.)
Keating
Patrick
(Bluefire Productions)
Kerscher
George
(DAISY Consortium)
Kida
Yasuo
(Apple Inc.)
Kim
Jean
(Barnes & Noble)
Kim
HyunYoung
(Incube Technologies)
Kim
Terry
(INKA Entworks)
Kitagawa
Masahiro
(Impress Holdings)
Koike
Toshiaki
(Voyager Japan)
Kok
Dan
(Crossway)
Kotrch
Steve
(Simon & Schuster)
Larroque
Benoit
(Feedbooks)
Levantovsky
Vladimir
(Monotype Imaging)
Lu
Cho-Chin
(Institute for Information Industry)
Lynch
Ryan
(Apple Inc.)
MacFarlane
James
(Easypress)
Makower
Dave
(Apple Inc.)
Mandelbaum
David
(Barnes & Noble)
Manis
Will
(Metaplates)
McCloy-Kelley
Liisa
(Random House)
McCoy
Bill
(IDPF)
Menzies
Tracey
(HarperCollins)
Mitchell
Chris
(Random House)
Moore
Helen
(HarperCollins)
Muller
Eric
(Adobe)
Murata
Makoto
(JEPA EPUB Study Group)
Mussinelli
Christina
(Associazione Italiana Editori)
Nagai
Yoshinori
(Sharp)
Novelli
Joe
(Sony)
O'Connor
Theresa
(Apple Inc.)
Ohmura
Yoshinori
(Impress Holdings)
Olenick
Michael
(Bowker)
Oshiyama
Taka
(East Co.)
Pagano
Pat
(Barnes & Noble)
Picco
Marty
(AppFoundry)
Prabhu
John
(HOV Services)
Pritchett
James
(Learning Ally (formerly RFB&D))
Rao
Vishnu
(Sharp Laboratories)
Rivlin
John
(Google)
Rubino
Frank
(Kaplan Publishing)
Ruffino
Daniel
(Penguin)
Rui Hua
Wang
(Gansu DUZHE Digital Sci&Tech)
Ruse
Tyler
(LibreDigital)
Sanicola
Daniel
(Penguin)
Schirmer
Lorenz
(Monotype Imaging)
Shiohama
Daihei
(Voyager Japan)
Shrivastava
Abhishek
(CourseSmart)
Slavin
Wayne
(Barnes & Noble)
Slye
Christopher
(Adobe)
Smith
Michael
(IDPF)
Soiffer
Neil
(Design Science)
Sorotokin
Peter
(Adobe)
Stevenson
Tobias
(eBookArchitects)
Tahara
Kyoji
(Toppan Printing)
Takase
Hiroshi
(East Co.)
Tallent
Joshua
(eBookArchitects)
Tanabe
Shu
(Toppan Printing)
Thomas
Vinu
(Impelsys)
Tsumagari
Koichiro
(Voyager Japan)
Valentine
Chelsea
(LibreDigital)
Vangage
Peter
(Harlequin)
Vido
Ariel
(Geografica Editora)
Wait
John
(Pearson)
Walkley
George
(Hachette Book Group)
Watters
Kevin
(Harlequin)
Webster
Roger
(Barnes & Noble)
Weck
Daniel
(DAISY Consortium)
Wei
Selena
(Chinese Foundation for Digitization Technology)
White
Russell
(Random House)
Wiles
Alexis
(Overdrive, Inc.)
Witwer
Adam
(O'Reilly)
Wright
Ric
(Adobe)
Young
Liz
(Crossway)
Zu
Alex
(ASTRI (Hong Kong Applied Science & Technology Research Institute))
Invited Experts/Observers
Bowes
Rick
Cazenove
Rhys
Collingridge
Peter
Cook
Mike
Etemad
Elika J.
W3C CSS WG Liason
Forster
Karen
Freed
Geoff
Fujisawa
Jun
Garrish
Matt
Gould
Bryan
Görner
Martin
Hsieh
Michael
Ishii
Koji
Johar
Kenny
Karlsson
Mattias
Kennedy
Dianne
Kilborn
Peter
Koppel
Josh
Lee
Tommy
Lu
Kenny
Lubeck
Scott
Masanori
Kusunoki
McKinney
Steven
Murakami
Shinyu
Ning
Elliott
Noring
Jon
Norton
Paul
Oishi
Yasuharu
Passey
Lee
Rosmaita
Gregory
Seaman
David
Severdia
Ron
Shan
Walter
Smith(tm)
Michael
(W3C)
W3C Liason
Sperberg
Roger
Walsh
Norman
Zergaoui
Mohamed
For more detailed acknowledgements and information about contributors to each version of EPUB, refer to
Acknowledgements and Contributors
EPUB3Overview
References
Normative References
AAC LC
ISO/IEC 14496-3:2009 - Information technology -- Coding of audio-visual objects -- Part 3: Audio
ASSOCSS
Associating Style Sheets with XML documents 1.0 (Second Edition)
James Clark, et al.
28 October 2010.
CSS3Fonts
CSS Fonts Module Level 3
John Daggett.
ContentDocs30
EPUB Content Documents 3.0
DCMES
Dublin Core Metadata Element Set, Version 1.1
DCTERMS
DCMI Metadata Terms
EPUBCFI
EPUB Canonical Fragment Identifier (epubcfi) Specification
GIF
GRAPHICS INTERCHANGE FORMAT(sm) Version 89a
HTML5
HTML5: A vocabulary and associated APIs for HTML and XHTML
ISOSchematron
ISO/IEC 19757-3: Rule-based validation — Schematron
JPEG
JPEG Standard (JPEG ISO/IEC 10918-1 ITU-T Recommendation T.81)
MARC21XML
MARC 21 XML Schema
MODS
Metadata Object Description Schema (MODS)
MP3
ISO/IEC 11172-3:1993 - Information technology -- Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s -- Part 3: Audio
MP4
Information technology -- Coding of audio-visual objects -- Part 14: MP4 file format
MediaOverlays30
EPUB Media Overlays 3.0
NVDL
ISO/IEC 19757-4: NVDL (Namespace-based Validation Dispatching Language)
OCF2
Open Container Format 2.0.1
OCF3
Open Container Format 3.0
ONIX
ONIX for Books
OPF2
Open Packaging Format 2.0.1
OPS2
Open Publication Structure 2.0.1
OpenType
ISO/IEC 14496-22:2009 - Information technology -- Coding of audio-visual objects -- Part 22: Open Font Format
PLS
Pronunciation Lexicon Specification 1.0 (PLS)
Paolo Baggia.
14 October 2008.
PNG
Portable Network Graphics (PNG) Specification (Second Edition)
David Duce.
10 November 2003.
Publications30
EPUB Publications 3.0
RDFa10
RDFa in XHTML: Syntax and Processing
A collection of attributes and processing rules for extending XHTML to support RDF.
Ben Adida, et al.
14 October 2008.
RFC2046
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
(RFC 2046)
N. Freed, N. Borenstein.
November 1996.
RFC2119
Key words for use in RFCs to Indicate Requirement Levels
(RFC 2119)
March 1997.
RFC3987
Internationalized Resource Identifiers (IRIs)
(RFC 3987)
M Duerst, et al.
January 2005.
RFC4839
Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF) (RFC 4839)
G Conboy, et al.
April 2007.
RFC5646
Tags for Identifying Languages
(RFC 5646)
A. Phillips, M. Davis.
September 2009.
RelaxNG
ISO/IEC 19757-2: Regular-grammar-based validation — RELAX NG. Second Edition
2008-12-15.
Unicode
The Unicode Consortium. The Unicode Standard, Version 5.0.0, defined by: The Unicode Standard, Version 5.0 (Boston, MA, Addison-Wesley, 2007. ISBN 0-321-48091-0)
WOFF
WOFF File Format 1.0
Jonathan Kew, et al.
XInclude
XML Inclusions (XInclude) Version 1.0 (Second Edition)
J. Marsh, et al.
15 November 2006.
XML
Extensible Markup Language (XML) 1.0 (Fifth Edition)
T. Bray, et al.
26 November 2008.
XML Base
XML Base (Second Edition)
Jonathan Marsh, et al.
28 January 2009.
XML DSIG Core
XML-Signature Syntax and Processing Version 1.1
M. Bartel, et al.
3 March 2011.
XMLNS
Namespaces in XML (Third Edition)
T. Bray, D. Hollander, A. Layman, R. Tobin. W3C.
8 December 2009.
XMP
Extensible Metadata Platform
XSD-DATATYPES
XML Schema Part 2: Datatypes Second Edition
Paul V. Biron et al.
28 October 2004.
Informative References
EPUB3Changes
EPUB 3 Differences from EPUB 2.0.1
William McCoy, et al.
EPUB3Overview
EPUB 3 Overview
Garth Conboy, et al.
H.264
H.264 : Advanced video coding for generic audiovisual services
RFC4329
Scripting Media Types
B. Höhrmann.
April 2006.
VP8
VP8 Data Format and Decoding Guide
J. Bankoski, et al.