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, must keep track of the various changes to HTML and the technologies it references to ensure they keep their processes up to date.

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 may include in XHTML content documents.

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, however, must keep track of changes to the SVG standard to ensure they keep their processes up to date.

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.

EPUB 3 only supports Presentation Markup [mathml3]. Content Markup is only allowed in structured markup annotations.

This specification relies on a subset of [smil3], from which the media overlays elements and attributes defined in 9.2.2 Media overlay document definition are derived.

This specification refers to the [url] standard for terminology and processing related to URLs expressed in EPUB publications. It is anticipated that new and revised web formats will adopt this standard, but until then this may put this specification in conflict with the internal requirements for some formats (e.g., valid relative paths), specifically with respect to the use of internationalized URLs. If a format does not allow internationalized URLs (i.e., URLs must conform to [rfc3986] or earlier), that requirement takes precedence within those resources.

To manifest plane defines all the resources of an EPUB publication. It is analogous to the package document manifest, but includes resources not present in that list.

The primary resources in this group are designated publication resources, which are all the resources used in rendering an EPUB publication to the user. EPUB creators always have to list these resources in the manifest element.

Publication resources are further classified by their use(s) in the spine plane and content plane.

The manifest plane also contains a set of linked resources. These resources are tangential to the direct rendering. They include, for example, metadata records and links to external content (e.g., where to purchase an EPUB publication).

Unlike publication resources, they are not listed in the package document manifest (i.e., because they are not essential to rendering the EPUB publication). They are instead defined in link elements in the package document metadata. These elements define their nature and purpose similar to how manifest item elements define publication resource. (In this way, they are like an extension of the manifest.)

Refer to 5.5.6 The link element for more information about linked resources.

Resources in the manifest plane are also sometimes broken down by where they are located. Although most publication resources have to be located in the EPUB container (called container resources), EPUB 3 allows audio, video, font and script data resources to be hosted outside the container. These exceptions were made to speed up the download and loading of EPUB publications, as these resources are typically quite large, and, in the case of fonts, not essential to the presentation. When remotely hosted, these publication resources are referred to as remote resources.

Since linked resources are not essential to the rendering of an EPUB publication, there are no requirements on where they are located and consequently no special naming of them based on their location. They may be located within the EPUB container or outside it.

The spine plane defines resources used in the default reading order established by the spine, which includes both linear and non-linear content. The spine instructs reading systems on how to load these resources as the user progresses through the EPUB publication. Although many resources may be bundled in an EPUB container, they are not all allowed by default in the spine.

EPUB 3 defines a special class of resources called EPUB content documents that EPUB creators can use in the spine without any restrictions. EPUB content documents encompass both XHTML content documents and SVG content documents.

To use any other type of resource in the spine, called a foreign content document, requires including a fallback to an EPUB content document. This extensibility model allows EPUB creators to experiment with formats while ensuring that reading systems are always able to render something for the user to read, as there is no guarantee of support for foreign content documents.

A mechanism called manifest fallbacks allows EPUB creators to provide fallbacks for foreign content documents. In this model, the manifest entry for the foreign content document must include a fallback attribute that points to the next possible resource for reading systems to try when they do not support its format. Although not common, a fallback resource can specify another fallback, thereby making chains many resources deep. The one requirement is that there must be at least one EPUB content document in a manifest fallback chain.

Although they are not directly listed in the spine, all of the resources in the fallback chain are considered part of the spine, and by extension part of the spine plane, since any may be used by a reading system.

Refer to 3.5.1 Manifest fallbacks for more information.

The content plane classifies resources that are used when rendering EPUB content documents and foreign content documents. These types of resources include embedded media, CSS style sheets, scripts, and fonts. These resources fall into three categories based on their reading system support: core media type resources, foreign resources, and exempt resources.

A core media type resource is one that reading systems have to support, so it can be used without restriction in EPUB or foreign content documents. For more information about core media type resources, refer to 3.2 Core media types.

The opposite of core media type resources are foreign resources. These are resources that reading systems are not guaranteed to support the rendering of. As a result, similar to how using foreign content documents in the spine requires fallbacks to ensure their rendering, using foreign resources in content documents also requires fallbacks. These fallbacks are provided in one of two ways: using the capabilities of the host format or via manifest fallbacks.

The preferred method is to use the fallback capabilities of the host format. Many HTML elements, for example, have intrinsic fallback capabilities. One example is the picture element [html], which allows EPUB creators to specify multiple alternative image formats.

If an intrinsic fallback method is not available, it is also possible to use manifest fallbacks, but this method, as cautioned against in the previous section, is discouraged. For more information about foreign resources, refer to 3.3 Foreign resources.

Falling between core media type resources and foreign resources are exempt resources. These are most closely associated with foreign resources, as there is no guarantee that reading systems will render them. But like core media types, they do not require fallbacks.

Exempt resources tend to address specific cases for which there are no core media types defined, but for which providing a fallback would prove cumbersome or unnecessary. These include embedding video, adding accessibility tracks, and linking to resources from the [html] link element.

Refer to 3.4 Exempt resources for more information about these exceptions.

Manifest fallbacks are a feature of the package document that create a manifest fallback chain for a publication resource, allowing reading systems to select an alternative format they can render.

Fallback chains are created using the fallback attribute on manifest item elements. This attribute references the ID [xml] of another manifest item that is a fallback for the current item. The ordered list of all the references that a reading system can reach, starting from a given item's fallback attribute, represents the full fallback chain for that item. This chain also represents the EPUB creator's preferred fallback order.

There are two cases for manifest fallbacks:

Spine fallbacks

EPUB creators MUST specify a fallback chain for a foreign content document to ensure that reading systems can always render the spine item. In this case, the chain MUST contain at least one EPUB content document.

EPUB creators MAY provide fallbacks for EPUB content documents (e.g., to provide a fallback for scripted content).

When a fallback chain includes more than one EPUB content document, EPUB creators can use the properties attribute to differentiate the purpose of each.

Content fallbacks

Note

The original purpose for content fallbacks was to specify fallback images for the [html] img element. As HTML now has intrinsic fallback mechanism for images, the use of content fallbacks is strongly discouraged. EPUB creators should always use the intrinsic fallback capabilities of [html] and [svg] to provide fallback content.

EPUB creators MUST provide a content fallback for foreign resources when the elements that reference them do not have intrinsic fallback capabilities. In this case, the fallback chain MUST contain at least one core media type resource.

EPUB creators MAY also provide manifest fallbacks for core media type resources (e.g., to allow reading systems to select from more than one image format).

Regardless of the type of manifest fallback specified, fallback chains MUST NOT contain self-references or circular references to item elements in the chain.

The following sections provide additional clarifications about the intrinsic fallback requirements of specific elements.

This section is non-normative.

The OCF abstract container file system model uses a single common root directory. All container resources 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 stores the following special files:

container.xml [required]

Identifies one or more package documents 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 EPUB creators use font obfuscation.

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

Refer to 4.2.6 META-INF directory for conformance requirements for the various files in the META-INF directory.

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. Refer to 4.2.6 META-INF directory for the requirements for the contents of this directory.

The file name mimetype in the root directory is reserved for use by OCF ZIP containers, as explained in 4.3 OCF ZIP container.

Files in the META-INF directory and the mimetype file are not publication resources so MUST NOT be listed in the manifest.

EPUB creators MAY locate all other files within the OCF abstract container in any location descendant from the root directory, provided they are not within the META-INF directory. EPUB creators MUST NOT reference files in the META-INF directory from an EPUB publication.

In the context of the OCF abstract container, file paths and file names are scalar value strings [infra] (i.e., their values are case sensitive).

In addition, the following restrictions are designed to allow file paths and file names to be used without modification on most operating systems:

• File names MUST NOT exceed 255 bytes.

• The file paths 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 commonly used operating systems may not support these characters consistently:

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

  • All Unicode Non Characters, specifically:

    • The 32 contiguous characters in the Basic Multilingual Plane (U+FDD0 … U+FDEF)

    • The last two code points of the Basic Multilingual Plane (U+FFFE and U+FFFF)

    • The last two code points at the end of the Supplementary Planes (U+1FFFE, U+1FFFF … U+EFFFE, U+EFFFF)

  • Specials (U+FFF0 … U+FFFF)

  • Supplementary Private Use Area-A (U+F0000 … U+FFFFF)

  • Supplementary Private Use Area-B (U+100000 … U+10FFFF)

  Note

  The Unicode Character Database [uax44] also includes a list of deprecated characters. EPUB creators are advised to avoid these characters, as well, as it is expected that EPUB conformance checkers will flag their use.

• For compatibility with older reading systems, file names SHOULD NOT contain SPACE (U+0020) characters.

• All file names within the same directory MUST be unique following Unicode canonical normalization [uax15] and then full case folding [unicode]. (Refer to Unicode Canonical Case Fold Normalization Step [charmod-norm] for more information.)

To derive the file path, given a file or directory file in the OCF abstract container, apply the following steps (expressed using the terminology of [infra]):

1. Let path be an empty list.
2. Let current be file.
3. While current is not the root directory:
   1. prepend the file name of current to path;
   2. set current to the parent directory of current.
4. Return the concatenation of path using the U+002F (/) character.

The container root URL is the URL [url] of the root directory. It is implementation-specific, but EPUB creators MUST assume it has the following properties:

• The result of parsing "/" with the container root URL as base is the container root URL.
• The result of parsing ".." with the container root URL as base is the container root URL.

The content URL of a file or directory in the OCF abstract container is the result of parsing the file's file path with the container root URL as base.

A string url is a valid-relative-ocf-URL-with-fragment string if it is a path-relative-scheme-less-url string, optionally followed by U+0023 (#) and a url-fragment string, and if the following steps return true:

1. Set the container root URL to https://a.example.org/A/.

   Explanation

   The goal of the algorithm is to detect whether url could be seen as "leaking" outside the container. To do that, the standard URL parsing algorithm is used with an artificial root URL; the detection of the "leak" is done by comparing the result of the parsing with the presence of the first test path segment (A). (Note that the artificial container root URL wilfully violates, for the purpose of this algorithm, the required properties by using that first test path segment.)

2. Let base be the base URL that must be used to parse url as defined by the context (document or environment) where url is used, and according to the content URL of the package document (see 5.2 Parsing URLs in the package document).

   Explanation

   In the case of a URL in the package document the base variable is set to the content URL of the package document. In the case of a document within the META-INF directory, the base variable is set to the container root URL (see 4.2.6.2 Parsing URLs in the META-INF directory). In the case of a URL in an XHTML content document, the base URL used for parsing is defined by the HTML standard. Typically, it will be the content URL of the content document (unless the discouraged base element is used).

3. Let testURLRecord be the result of applying the URL parser to url, with base.
4. Let testURLStringA be the result of applying the URL Serializer to testURLRecord.

5. Set the container root URL to https://b.example.org/B/.

   Explanation

   The reasons to repeat the same steps twice with different, and artificial, settings of the container root URL is to avoid collision which may occur if the url string also includes /A/. Consider, for example, the case where url is ../../A/doc.xhtml.

6. Set base to be the base URL that must be used to parse url as defined by the context (document or environment) where url is used, and according to the content URL of the package document (see 5.2 Parsing URLs in the package document).
7. Set testURLRecord to be the result of applying the URL parser to url, with base.
8. Let testURLStringB be the result of applying the URL Serializer to testURLRecord.

9. If testURLStringA does not start with https://a.example.org/ or testURLStringB does not start with https://b.example.org/, return true.

   Explanation

   If any of the result does not share the test URL host, it means that url, or its base URL (for example, in HTML, if it is explicitly set with the base element), was absolute and points outside the container. This is acceptable.

10. If testURLStringA starts with https://a.example.org/A/ and testURLStringB starts with https://b.example.org/B/, return true.

    Explanation

    The presence of the first test path segments (A, respectively B) indicate that the URL doesn't leak outside the container.

11. Return false.

In the OCF abstract container, any URL string MUST be an absolute-url-with-fragment string or a valid-relative-ocf-URL-with-fragment string.

In addition, all relative-URL-with-fragment strings [url] MUST, after parsing, be equal to the content URL of an existing file in the OCF abstract container.

This section is non-normative.

An OCF ZIP container is a physical single-file manifestation of an OCF abstract container. The container allows:

• the exchange of in-progress EPUB publication between different individuals and/or different organizations;

• the transfer of EPUB publications from a publisher or conversion house to the distribution or sales channel; and

• the delivery of EPUB publications to EPUB reading systems or users.

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 4.2.6.3.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, EPUB creators 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 for Deflate, 45 for ZIP64).

• In the local file header table, EPUB creators MUST set the compression method field to the values 0 or 8.

EPUB creators MUST include the mimetype file as the first file in the OCF ZIP container. In addition:

• 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 whitespace.
• The mimetype file MUST NOT begin with the Unicode byte order mark U+FEFF.
• EPUB creators MUST NOT compress or encrypt the mimetype file.
• EPUB creators MUST NOT include an extra field in its ZIP header.

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 fonts 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 OCF ZIP container is insufficient to signify that the font cannot be reused in other contexts. This uncertainty can undermine the otherwise useful font embedding capability of EPUB publications.

To discourage reuse of their fonts, some font vendors might only allow their use in EPUB publications if the 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 fonts. 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 fonts.

This section is non-normative.

This specification does not claim that obfuscation constitutes encryption, nor does it guarantee that the resource will be secure from copyright infringement. The hope is only that this algorithm will meet the requirements of vendors who require some assurance that their fonts cannot be extracted simply by unzipping the OCF ZIP container and copying the resource.

Obfuscation, like any protection scheme, cannot fully protect fonts from being accessed in their deobfuscated state. The mechanism only provides an obstacle for those who are unaware of the license details. It will not prevent a determined user from gaining full access to the font through such alternative means as:

• applying the deobfuscation algorithm to extract the raw font file;
• accessing the deobfuscated font through a reading system that must deobfuscate it to render the content (e.g., by accessing the resources through a browser-based reading system); or
• accessing the deobfuscated font through authoring tools that provide the visual rendering of the content.

As a result, whether this method of obfuscation satisfies the requirements of individual font licenses remains a question for the licensor and licensee. EPUB creators are responsible for ensuring their use of obfuscation meets font licensing requirements.

EPUB creators should also be aware that obfuscation may lead to interoperability issues in reading systems as reading systems are not required to deobfuscate fonts. As a result, the visual presentation of their publications may differ from reading system to reading system.

Also note that the algorithm is restricted to obfuscating fonts. It is not intended as a general-purpose mechanism for obfuscating any resource in the EPUB container.

EPUB creators MUST derive the key used in the obfuscation algorithm from the unique identifier.

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

EPUB creators MUST generate a SHA-1 digest of the UTF-8 representation of the resulting string as specified by the Secure Hash Standard [fips-180-4]. They can then use this digest as the key for the algorithm.

The algorithm employed to obfuscate fonts consists of modifying the first 1040 bytes (~1KB) of the font file. (In the unlikely event that the font file is less than 1040 bytes, this process will modify the entire file.)

To obfuscate the original data, store, as the first byte of the embedded font, the result of performing a logical exclusive or (XOR) on the first byte of the raw font file and the first byte of the obfuscation key.

Repeat this process with the next byte of source and key and continue for all bytes in the key. At this point, the process continues starting with the first byte of the key and 21st byte of the source. Once 1040 bytes are encoded in this way (or the end of the source is reached), directly copy any remaining data in the source to the destination.

EPUB creators MUST obfuscate fonts before compressing and adding them to the OCF ZIP container. Note that as obfuscation is not encryption, this requirement is not a violation of the one in 4.2.6.3.2 Encryption file (encryption.xml) to compress fonts before encrypting them.

The following pseudo-code exemplifies the obfuscation algorithm.

1. set ocf to OCF ZIP container file
2. set source to font file
3. set destination to obfuscated font file
4. set keyData to key for file
5. set outer to 0
6. while outer < 52 and not (source at EOF)
   1. set inner to 0
   2. while inner < 20 and not (source at EOF)
      1. read 1 byte from source (Assumes read advances file position)
      2. set sourceByte to result of read
      3. set keyByte to byte inner of keyData
      4. set obfuscatedByte to (sourceByte XOR keyByte)
      5. write obfuscatedByte to destination
      6. increment inner
      end while
   3. increment outer
   end while
7. if not (source at EOF) then
   1. read source to EOF
   2. write result of read to destination
   end if
8. Deflate destination
9. store destination as source in ocf

Although not technically encrypted data, all obfuscated fonts MUST have an entry in the encryption.xml file accompanying the EPUB publication (see 4.2.6.3.2 Encryption file (encryption.xml)).

EPUB creators MUST specify an EncryptedData element for each obfuscated font. Each EncryptedData element MUST contain a child EncryptionMethod element whose Algorithm attribute has the value http://www.idpf.org/2008/embedding. The presence of this attribute signals the use of the algorithm described in this specification.

EPUB creators MUST list the path to the obfuscated font in the CipherReference child of the CipherData element. As the obfuscation algorithm is restricted to fonts, the URI attribute of the CipherReference element MUST reference a Font core media type resource.

To prevent trivial copying of the embedded font to other EPUB publications, EPUB creators MUST NOT provide the obfuscation key in the encryption.xml file.

Specifies the base direction [bidi] of the textual content and attribute values 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].

Reading systems will assume the value auto when EPUB creators omit the attribute or use an invalid value.

Allowed on: collection, Dublin Core elements, meta, and package.

A valid URL string [url] that references a resource.

The URL string MUST NOT reference resources via elements in the package document (e.g., via a manifest item or spine itemref declaration).

Allowed on: item and link.

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

Allowed on: collection, Dublin Core elements, item, itemref, link, manifest, meta, package, and spine.

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

Allowed on: item and link.

A space-separated list of property values.

Refer to each element's definition for the reserved vocabulary for the attribute.

Allowed on: item, itemref, and link.

Establishes an association between the current expression and the element or resource identified by its value. EPUB creators MUST use as the value a path-relative-scheme-less-URL string, optionally followed by U+0023 (#) and a URL-fragment string that references the resource or element they are describing.

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

When creating expressions about a publication resource, the refines attribute SHOULD specify a fragment identifier that references the ID [xml] of the resource's manifest entry.

Refinement chains MUST NOT contain circular references or self-references.

Allowed on: link and meta.

Specifies the language of the textual content 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].

Allowed on: collection, Dublin Core elements, meta, and package.

The metadata element encapsulates meta information.

Element Name:

metadata

Usage:

REQUIRED first child of package.

Attributes:

None

Content Model:

In any order:

• dc:identifier [1 or more]

• dc:title [1 or more]

• dc:language [1 or more]

• Dublin Core Optional Elements [0 or more]

• meta [1 or more]

• OPF2 meta [0 or more] (legacy)

• link [0 or more]

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 does not provide complex metadata encoding capabilities. If EPUB creators need to provide more detailed information, they can associate metadata records (e.g., that conform to an international standard such as [onix] or are created for custom purposes) using the link element. This approach allows reading systems to process the metadata 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 [dcterms] dc:title, dc:identifier, and dc:language elements together with the [dcterms] dcterms:modified property. All other metadata is OPTIONAL.

The meta element provides a generic mechanism for including metadata properties from any vocabulary. Although EPUB creators MAY use this mechanism for any metadata purposes, they will typically use it to include rendering metadata defined in EPUB specifications.

The Dublin Core elements [dcterms] and meta element have mandatory child text content [dom]. In the descriptions for these elements, this specification refers to this content as the element's value .

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 is not significant. Sequences of one or more whitespace characters are collapsed to a single space [infra] during processing .

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

Element Name:

meta

Usage:

As child of the metadata element. Repeatable.

Attributes:

• dir [optional]

• id [optional]

• property [required]

• refines [optional]

• scheme [optional]

• xml:lang [optional]

Content Model:

Text

Each meta element defines a metadata expression. The property attribute takes a property data type value that defines the statement 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 EPUB creators can define 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.

EPUB creators MAY use subexpressions to refine the meaning of other subexpressions, thereby creating chains of information.

The Meta Properties Vocabulary is the default vocabulary for use with the property attribute.

EPUB creators MAY add terms from other vocabularies as defined in D.1 Vocabulary association mechanisms.

The scheme attribute identifies the system or scheme the EPUB creator obtained the element's value from. The value of the attribute MUST be a property data type value that resolves to the resource that defines the scheme. The scheme attribute does not have a default vocabulary (i.e., all values require a prefix).

The metadata section MUST contain exactly one dcterms:modified property [dcterms] containing the last modification date. The value of this property MUST be an [iso8601-1] complete representation of a date and time of day matching the extended format: YYYY-MM-DDThh:mm:ssZ

EPUB creators MUST express the last modification date in Coordinated Universal Time (UTC) and MUST terminate it with the "Z" (Zulu) time zone indicator.

EPUB creators should update the last modified date whenever they make changes to the EPUB publication.

EPUB creators MAY specify additional modified properties 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).

The link element associates resources with an EPUB publication, such as metadata records.

Element Name:

link

Usage:

As a child of metadata. Repeatable.

Attributes:

• href [required]

• hreflang [optional]

• id [optional]

• media-type [conditionally required]

• properties [optional]

• refines [optional]

• rel [required]

Content Model:

Empty

The metadata element MAY contain zero or more link elements, each of which identifies the location of a publication resource or a linked resource in its REQUIRED href attribute.

Resources referenced from the link element are publication resources only when they are:

• referenced from the spine; or

• included or embedded in an EPUB content document (e.g., a metadata record serialized as RDFa [rdfa-core] or as JSON-LD [json-ld11] embedded in an [html] script element).

In all other cases (e.g., when linking to standalone [onix] records), the resources referenced are not publication resources (i.e., are not subject to core media type requirements) and EPUB creators MUST NOT list them in the manifest.

EPUB creators MAY locate linked resources within the EPUB container or externally, but should consider that reading systems are not required to retrieve resources outside the EPUB container.

The media-type attribute is OPTIONAL when a linked resource is located outside the EPUB container, as more than one media type could be served from the same URL [url]. EPUB creators MUST specify the attribute for all linked resources within the EPUB container.

The OPTIONAL hreflang attribute identifies the language of the linked resource. The value MUST be a well-formed language tag [bcp47].

The REQUIRED rel attribute takes a space-separated list of property values that establish the relationship the linked resource has with the EPUB publication.

The value of the media-type attribute is not always sufficient to identify the type of linked resource (e.g., many XML-based record formats use the media type "application/xml"). To aid reading systems in the identification of such generic resources, EPUB creators MAY specify a semantic identifier in the properties attribute.

The Metadata Link Vocabulary is the default vocabulary for the rel and properties attributes.

EPUB creators MAY add relationships and properties from other vocabularies as defined in D.1 Vocabulary association mechanisms.

EPUB creators MAY provide one or more linked metadata records.

In addition to full records, EPUB creators MAY also use the link element to identify individual metadata properties available in an alternative format.

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]

With the exception of the package document, the manifest MUST list all publication resources regardless of whether they are container resources or remote resources.

As the package document is already identified by the container.xml file, the manifest MUST NOT specify an item element for it (i.e., a self-reference serves no purpose).

The item element represents a publication resource.

Element Name:

item

Usage:

As a child of manifest. Repeatable.

Attributes:

• fallback [conditionally required]

• href [required]

• id [required]

• media-overlay [optional]

• media-type [required]

• properties [optional]

Content Model:

Empty

Each item element identifies a publication resource by the URL [url] in its href attribute. The value MUST be an absolute- or path-relative-scheme-less-URL string [url]. EPUB creators MUST ensure each URL is unique within the manifest scope after parsing.

The publication resource identified by an item element MUST conform to the applicable specification(s) as inferred from the MIME media type [rfc2046] provided in the media-type attribute. For core media type resources, EPUB creators MUST use the media type designated in 3.2 Core media types.

The fallback attribute specifies the fallback for the referenced publication resource. The fallback attribute's IDREF [xml] value MUST resolve to another item in the manifest.

The fallback for one item MAY specify a fallback to another item, and so on, creating a chain of fallback options. Refer to 3.5.1 Manifest fallbacks for additional requirements related to the use of fallback chains.

The media-overlay attribute takes an IDREF [xml] that identifies the media overlay document for the resource described by this item. Refer to 9.3.5 Media overlays packaging for more information.

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

Use of the element is deprecated.

Refer to the bindings element definition in [epubpublications-301] for more information.

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:

• id [optional]

• page-progression-direction [optional]

• toc [optional] (legacy)

Content Model:

itemref [1 or more]

The spine MUST specify at least one EPUB content document or foreign content document.

EPUB creators MUST list in the spine all EPUB and foreign content documents that are hyperlinked to from publication resources in the spine, where hyperlinking encompasses 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., EPUB creators must list all EPUB and foreign content documents hyperlinked to from hyperlinked documents, and so on.).

EPUB creators also MUST list in the spine all EPUB and foreign content documents hyperlinked to from the EPUB navigation document, regardless of whether EPUB creators include the EPUB navigation document 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 EPUB creators specify the default value, they are expressing no preference and the reading system can choose the rendering direction.

Although the page-progression-direction attribute sets the global flow direction, individual EPUB content documents and parts of EPUB content documents MAY override this setting (e.g., via the writing-mode CSS property). Reading systems may 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.

The itemref element identifies an EPUB content document or foreign content document in the default reading order.

Element Name:

itemref

Usage:

As a child of spine. Repeatable.

Attributes:

• id [optional]

• idref [required]

• linear [optional]

• properties [optional]

Content Model:

Empty

Each itemref element MUST reference the ID [xml] of an item in the manifest via the IDREF [xml] in its idref attribute. item element IDs MUST NOT be referenced more than once.

Each referenced manifest item MUST be either a) an EPUB content document or b) a foreign content document that includes an EPUB content document in its manifest fallback chain.

The linear attribute indicates whether the referenced item contains content that contributes to the primary reading order and that reading systems must read sequentially ("yes"), or auxiliary content that enhances or augments the primary content that reading systems can access 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 should access as part of the default reading order from supplementary content which a reading system might, for example, present in a popup window or omit 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.

A linear itemref element is one whose linear attribute value is explicitly set to "yes" or that omits the attribute — reading systems will assume the value "yes" for itemref elements without the attribute. The spine MUST contain at least one linear itemref element.

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.

EPUB creators MAY add terms from other vocabularies as defined in D.1 Vocabulary association mechanisms.

The collection element defines a related group of resources.

Element Name:

collection

Usage:

OPTIONAL sixth element of package. Repeatable.

Attributes:

• dir [optional]

• id [optional]

• role [required]

• xml:lang [optional]

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 EPUB creators to assemble resources into logical groups for a variety of potential uses: enabling reassembly into a meaningful unit of content split across multiple EPUB content documents (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.

EPUB creators MUST identify the role of each collection element in its role attribute, whose value MUST be one or more NMTOKENs [xmlschema-2] and/or absolute-URL-with-fragment strings [url].

The requirements for authoring specialized collections are defined by their respective specifications.

The creation of new collection element roles is now deprecated.

Refer to the collection element definition in [epubpackages-32] for more information about the creation of specialized collections, including the requirements and restrictions on their use.

The package document legacy features are retained from EPUB 2 only to allow EPUB creators to author content that can function, to some degree, in reading systems that only support EPUB 2 publications.

These features were added primarily to address the overlap period as EPUB 3 reading systems were developed, as there was still a high probability at that time that users would be opening EPUB 3 publications on EPUB 2 reading systems.

As reading systems that only handle EPUB 2 publications are now rare, EPUB creators should consider the likelihood of their publications still being opened on these types of older devices before making the effort to add these legacy features.

EPUB creators MAY include the legacy features defined in this section for compatibility purposes with EPUB 2 reading systems.

EPUB 3 reading systems will not use these features when presenting publications to users.

The meta element [opf-201] provides a means of including generic metadata for EPUB 2 reading systems.

Refer to the meta element definition in [opf-201] for more information.

The guide element [opf-201] provides machine-processable navigation to key structures in EPUB 2 reading systems.

Refer to the guide element definition in [opf-201] for more information.

The NCX [opf-201] provides a table of contents for EPUB 2 reading systems.

Refer to the NCX definition in [opf-201] for more information.

This section is non-normative.

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.

An XHTML content document:

• MUST be an [html] document that conforms to the XML syntax.

• MUST conform to the conformance criteria for all document constructs defined by [html] unless explicitly overridden in 6.1.4 HTML deviations and constraints.

• MAY include extensions to the [html] grammar as defined in 6.1.3 HTML extensions, and MUST conform to all content conformance constraints defined therein.

Unless specified otherwise, XHTML content documents inherit all definitions of semantics, structure, and processing behaviors from the [html] specification.

This section defines EPUB 3 XHTML content document extensions to the underlying [html] document model.

This section defines deviations from, and constraints on, the underlying [html] document model applicable to EPUB 3 XHTML content documents.