EPUB Multiple-Rendition Publications
Draft Specification 9 December 2013
Copyright © 2012-2013 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
Jim Lester (Barnes & Noble), Takeshi Kanai (Sony), Matt Garrish (Invited Expert)
Authors
Takeshi Kanai (Sony), Jim Lester (Barnes & Noble), Brady Kroupa (Barnes & Noble), Garth Conboy (Google), Brady Duga (Google), MURATA Makoto (JEPA), Theresa O’Connor (Apple), Hadrien Gardeur (Feedbooks) ... others...
Status of this Document
This specification is a work in progress and subject to change.
All comments on this specification should be submitted via the EPUB 3 Working Group Issue Tracker, hosted on Google Code. NOTE: you must login via a Google Account in order to submit an issue. Please submit spec comments with the labels "Type-ReviewComment" and "Spec-AHL". Members of the EPUB Working Group may submit questions via the mailing list.
Table of Contents
3.3 Reading System Conformance
3.4 Rendition Selection Attributes
3.4.1 The rendition:media attribute
3.4.2 The rendition:layout attribute
3.4.3 The rendition:language attribute
3.4.4 The rendition:accessMode attribute
3.4.5 The rendition:description attribute
4.3 Reading System Conformance
4.4 EPUB Rendition Mapping Document Definition
4.4.1 XHTML Content Document: Restrictions
4.4.2 The nav Element: Modifications and Restrictions
4.4.4 Container Identification
Appendix A. Navigation Document Schema
Appendix B. Acknowledgements and Contributors
This section is informative
This specification, EPUB Multiple-Rendition Publications, defines the creation and rendering of EPUB® Publications consisting of more than one Rendition.
The need to include more than one Rendition of an EPUB Publication has grown as Reading Systems have evolved and become more sophisticated. While some measure of content adaptation has always been possible at the style sheet level, it is both limited in what it can accomplish and limited to content rendering. Existing fallback mechanisms within the EPUB Package Document are equally simple in nature, only ensuring that resources can be rendered.
Adaptation is not just about optimizing styling and positioning content for screen considerations, such as dimensions and color or Reading System orientation, but often involves changing the content itself. The resources and markup required to render a fixed-layout Rendition of an EPUB Publication may overlap with a reflowable version of the same, but the two are never exactly the same. Adaptation also involves adapting the prose of a work. In an increasingly interconnected world, including multiple translations of a work rather than bundling them all separately as single-language EPUB Publications is often a necessity. And adaptation is also about the ability to move from the same spot in one Rendition to the equivalent spot in another as changes in the reading environment occur.
This specification defines how a Reading System can adapt the content intelligently to handle these complex needs.[a] It addresses each of the major requirements in the discovery of, selection of, and mapping between, multiple Renditions of an EPUB Publication. In particular:
Each major section in this specification deals with one these requirements, detailing the functionality added to address its handling. Taken together, the features enable the creation of advanced multiple-Rendition EPUB Publications that Reading Systems can adapt to changing User needs.
Refer to the EPUB Specifications for definitions of EPUB-specific terminology used in this document.
Container Document
The container.xml file located in the child META-INF directory of the OCF Container root directory. Each Rendition in the Container is identified by a rootfile element.
Metadata Document
The metadata.xml file located in the META-INF directory off the OCF container root. Contains the default metadata for the EPUB Publication.
Rendition Mapping Document
A specialization of the XHTML Content Document, containing machine-readable mappings between equivalent content in different Renditions, conforming to the constraints expressed in Rendition Mapping.
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.
This section is informative
For reliable processing of EPUB Publications, each needs to be uniquely identifiable from any other. Uniqueness between EPUB Publications is not enough, however, as more than one version of an EPUB Publication could exist. As a result, it is also necessary to be able to identify and order each release of an EPUB Publication
In order to distinguish both these characteristics, the concept of a Release Identifier [Publications301] was introduced in EPUB 3. This identifier is a combination of the Unique Identifier and the last modified date, but can be unique to each Rendition because it is expressed in the Package Document metadata (e.g., the last modification dates for Renditions could be different if minor corrections only were necessary to some of them).
The Release Identifier defined in a Package Document only effectively identifies the EPUB Publication as a whole when there is only one Rendition in the Container. With multiple-Rendition Publications, a new Release Identifier that covers all the Renditions of the EPUB Publication is necessary, otherwise comparisons are complicated by trying to figure out which Rendition(s) have changed and how to compare them from one release to the next.
This section details how to define such a global Release Identifiers for an EPUB Publication.
The Release Identifier for a multiple-rendition EPUB Publication is expressed in the META-INF/container.xml file [OCF301] using two child elements of the root metadata element:
The dc:identifier element is a direct adaptation of the [Publications301] dc:identifier element. The identifier value expressed in this element must conform to the requirements for identifiers defined in 3.4.3 The DCMES identifier Element [Publications301].
A unique-identifier attribute that identifies the dc:identifier element containing the Unique Identifier must be included on the root metadata element. The value of this attribute must be the IDREF [XML] of the corresponding dc:identifier element.
NOTE
As other specifications can include metadata in the Metadata File, the unique-identifier attribute is necessary to ensure there is an unambiguous means of determining which dc:identifier carries the identifier.
The meta element is an adaptation of the [Publications301] meta element, with the following differences:
The dcterms prefix is inherited from the reserved prefixes [Publications301] for package metadata and must be recognized by Reading Systems.
The value of the dcterms:modified property must conform to the pattern and rules defined in 4.1.2 Release Identifier [Publications301]. Only one dcterms:modified property is allowed in the Metadata File[c].
The following example shows a Release Identifier expressed in the metadata.xml file:
<metadata xmlns="http://www.idpf.org/2013/metadata"
xmlns:dc="http://purl.org/dc/elements/1.1/"
unique-identifier="pub-id">
<dc:identifier id="pub-id">urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</dc:identifier>
<meta property="dcterms:modified">2011-01-01T12:00:00Z</meta>
</metadata>
This section is informative
Although each EPUB Publication represents a single work, it is possible to optimize the rendering of that work in any number of different ways. An issue of a magazine, for example, could include a fixed layout version (print replica) for rendering on tablet-sized screens and a reflowable version for smaller cellphone screens where the fixed layout would be scaled to illegibility (or automatically reflowed in unwanted ways if fixed layouts are not supported).
The OCF Container allows multiple Renditions of the same EPUB Publication to be included, but does not specify how Reading Systems must determine the unique properties of the multiple Renditions listed in the Container Document, or select between them.
This section redresses this problem by defining both a set of rendition selection attributes that can be attached to rootfile elements in the Container Document and a processing model that allows Authors to specify which Rendition is the best representation depending on various conditions. Reading Systems can then select the appropriate representation from the list of Renditions to match the current configuration and User preferences.
A Container Document must meet all of the following criteria:
› It must be valid to the definition and requirements for the container.xml file specified in Container – META-INF/container.xml [OCF301].
› It may include any of the selection attributes as defined in Rendition Selection Attributes.
An EPUB Reading System must [e]meet all of the following criteria for Rendition selection:
› It must[f] evaluate Rendition selection attributes as defined in Rendition Selection Attributes.
› It should determine the Rendition to present to a User as defined in 3.5 Processing Model.
› It must ignore Rendition selection attributes in EPUB Publications with only a single Rendition.
› It must ignore attributes[g] not defined in Rendition Selection Attributes.
The rendition:media attribute identifies the media features of a Reading System the given Rendition is best suitable for rendering on.
Attribute Name
media
Namespace
http://www.idpf.org/2013/rendition
Usage
may be specified on Container Document rootfile elements.
Value
A CSS 3 media query [MediaQueries].
As per [MediaQueries], the media query in this attribute must [h]evaluate to true in order for the given Rendition to be selected for rendering. Media queries that evaluate to “not all”[i] per 3.1 Error Handling [MediaQueries] should be treated as false for the purposes of Rendition selection (i.e., the given Rendition is not a valid match).
The following example shows two Renditions of The Sandman bundled in the same container, one optimized for screens wider than 1920 pixels. The Default Rendition will be used for screen sizes smaller than 1920 pixels by default.
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container"
xmlns:rendition="http://www.idpf.org/2013/rendition">
<rootfiles>
<rootfile full-path="Sandman.opf"
media-type="application/oebps-package+xml"/>
<rootfile full-path="Sandman-large.opf"
media-type="application/oebps-package+xml"
rendition:media="min-width: 1920px"/>
</rootfiles>
</container>
The rendition:layout attribute indicates whether the given Rendition is reflowable or pre-paginated.
Attribute Name
layout
Namespace
http://www.idpf.org/2013/rendition
Usage
may be specified on Container Document rootfile elements.
Value
The value of the attribute must be reflowable or pre-paginated.[j]
When specified on a rootfile element, the value of this attribute must match the global rendition:layout setting for the referenced Rendition.
If a User preference is defined, the attribute evaluates to true if the preference matches the specified value, otherwise it evaluates to false. If no User preference is defined, the Reading System should ignore the attribute when selecting from the available Renditions.
The following example shows two Renditions of a magazine bundled in the same container. Note that it is not necessary to state that the Default Rendition is reflowable, since Renditions are reflowable by default.
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container"
xmlns:rendition="http://www.idpf.org/2013/rendition">
<rootfiles>
<rootfile full-path="EPUB/reflow/magazine.opf"
media-type="application/oebps-package+xml"/>
<rootfile full-path="EPUB/fxl/magazine.opf"
media-type="application/oebps-package+xml"
rendition:layout="pre-paginated"/>
</rootfiles>
</container>
The rendition:language attribute indicates that the given Rendition is optimized for the specified language.
Attribute Name
language
Namespace
http://www.idpf.org/2013/rendition
Usage
may be specified on Container Document rootfile elements.
Value
must contain a valid language code conforming to [RFC5646].[k]
The rendition:language attribute more precisely identifies the primary language of a Rendition than does the inclusion of dc:language elements in the Rendition’s Package Document, as the presence of dc:language elements only indicates that the specified languages are prominently used in the prose.
The following example shows a multilingual EPUB Publication, with English, French and Spanish Renditions of the content.
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container"
xmlns:rendition="http://www.idpf.org/2013/rendition">
<rootfiles>
<rootfile full-path="EPUB/en/package.opf"
media-type="application/oebps-package+xml"
rendition:language="en"/>
<rootfile full-path="EPUB/fr/package.opf"
media-type="application/oebps-package+xml"
rendition:language="fr"/>
<rootfile full-path="EPUB/es/package.opf"
media-type="application/oebps-package+xml"
rendition:language="es"/>
</rootfiles>
</container>
The rendition:accessMode attribute identifies the way in which intellectual content is communicated in a Rendition, and is based on the [ISO24751-3] "Access Mode" property.
Attribute Name
accessMode
Namespace
http://www.idpf.org/2013/rendition
Usage
may be specified on Container Document rootfile elements.
Value
must be one or more of the values: auditory, textual or visual
This property defines the primary access mode(s) for a given Rendition. For example, although a textual work may include images, audio and video, its primary means of conveying information is the text. Likewise, a visual work might include alt text and/or descriptions, but these adaptations are not listed as a textual mode for the Rendition for the purpose of selection.
The way in which information is encoded also needs to be considered when designating an access mode. If a work has text components, or is completely textual in nature, but that content is burned into an image format, the access mode is visual (e.g., character dialogue in a JPEG page of a comic or a scan of a document).
A rendition may include more than one primary access mode. For example, the textual version may also embed the auditory version using media overlays. In such cases, the attribute should list each primary access mode available.
If a User preference is defined, the attribute evaluates to true if that preference matches any of the access modes defined in it, otherwise it evaluates to false. If no User preference is defined, the Reading System should ignore the attribute when selecting from the available Renditions.[l]
The following example shows an EPUB Publication with an image-based Rendition and a text-based serialization available.
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container"
xmlns:rendition="http://www.idpf.org/2013/rendition">
<rootfiles>
<rootfile full-path="EPUB/comic/package.opf"
media-type="application/oebps-package+xml"
rendition:accessMode="visual"/>
<rootfile
full-path="EPUB/novel/package.opf"
media-type="application/oebps-package+xml"
rendition:accessMode="textual"/>
</rootfiles>
</container>
The rendition:description attribute allows each rootfile to be annotated with a human-readable description of its selection criteria.
Attribute Name
description
Namespace
http://www.idpf.org/2013/rendition
Usage
may be specified on Container Document rootfile elements.
Value
Text.
The rendition:description attribute provides a title for the given rendition (e.g., for manual rendition selection).[n]
When using the rendition:description attribute, the language of the title should [o]be expressed using an xml:lang attribute. The language may be specified on the root container element for all titles, or on individual rootfile elements for multilingual publications.
The following example shows the rendition:description attribute being used to more fully explain the nature of the rendition.
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container"
xmlns:rendition="http://www.idpf.org/2013/rendition"
xml:lang="en">
<rootfiles>
…
<rootfile
full-path="EPUB/package.opf"
media-type="application/oebps-package+xml"
rendition:media="color, min-width: 1024"
rendition:layout="pre-paginated"
rendition:description="Color-optimized print replica"/>
</rootfiles>
</container>
The rendition:description attribute is not considered a selection attribute for the purposes of evaluating which Rendition to render.
This section describes the method by which Reading Systems locate the optimal Rendition to present to a User.
Rendition selection should occur on initial rendering, and Reading Systems should re-evaluate the selection in response to changes in the User environment (e.g., change in device orientation or viewport size).
When a change condition is triggered, the Reading System should evaluate the rootfile elements in the Container Document as follows, starting with the last rootfile entry:
If the Default Rendition is reached, select the given Rendition and exit the process.
NOTE
This processing model does not require that the selection process occur on a User's device, or that all Renditions be provided in the Container. Rendition selection could occur on the server side of a cloud-based delivery system, for example, and only a single best-match Rendition sent to the device.
NOTE
Since EPUB 2 Reading Systems, and EPUB 3 Reading Systems that do not support multiple-Rendition selection, will render the Default Rendition, Authors need to consider which Rendition will have the greatest compatibility across Reading Systems and ensure it is listed first.
A Reading System may provide the User the option to manually select any of the Renditions in the Container. It should use the rendition:description attribute attribute value to present the option, when available.
As EPUB did not previously define a Rendition selection model, custom selection models might be encountered in some EPUB Publications. When recognized, these selection models should be utilized. If both rendition selection attributes conformant to this specification and custom attributes are defined, the latter must [p]be ignored.
This section is informative
The Rendition Mapping Document identifies related content locations across the Renditions in a multiple-Rendition EPUB Publication, allowing Reading Systems to switch between Renditions while keeping the User’s place.
The Rendition Mapping Document is represented as XHTML, and uses nav elements with unordered lists to group the mappings. There is no display component to the Rendition Mapping Document: it is designed to enable automated switching. The lack of a rendering context means that the XHTML content model for this document is very restrictive, allowing only a single nav element in the body, to ease both authoring and processing.
To enable the mapping of content locations between Renditions, the Rendition Mapping Document’s nav element consists of a series of one or more unordered lists, each of which represents a common point across all the Renditions (e.g., a chapter, a page or a component within a page). The list items in each unordered list represent the set of equivalent link destinations across the available Renditions for that content (e.g., one link might point to a document representing one page of a fixed layout Rendition, while the equivalent link to a reflowable Rendition might point to the corresponding page break indicator within the XHTML Content Document containing the page).
Knowing the position of the User in the current Rendition, when a change in context occurs, or is triggered by the User, the Reading System can inspect the sibling list items to determine the EPUB Content Document to load that best meets the new conditions.
A conformant EPUB Rendition Mapping Document must meet all of the following criteria:
Document Properties
› It must conform to all content conformance constraints for XHTML Content Documents as defined in XHTML Content Documents — Content Conformance [ContentDocs30].
› It must conform to all content conformance constraints specific for EPUB Rendition Mapping Documents expressed in EPUB Rendition Mapping Document Definition.
Publication
› It must not be listed in the Package Document manifest of any of the EPUB Publication’s Renditions.
Container
› It must not be encrypted in the OCF Container.
A conformant EPUB Reading System must meet all of the following criteria for processing EPUB Rendition Mapping Documents:
› When a change in Renditions occurs, the Reading Systems must locate the current position in the Rendition Mapping Document and load the matching position in the new Rendition.
The Rendition Mapping Document is a compliant EPUB XHTML Content Document, but with the following restrictions on the [HTML5] content model:
The Rendition Mapping Document inherits the content model for nav elements defined in The nav Element: Restrictions [ContentDocs30], but with the following modifications and restrictions:
Each ul element in the Rendition Mapping Document nav element identifies a common content location across the available Renditions. The number of these synchronization points, and level of granularity provided, is at the discretion of Authors.
Each list item within the unordered list must identify the portion of the given Rendition that is equivalent to the other child li elements in a child a element. The href attribute of the a element must specify which Rendition it is referring to either by using an Intra-Publication CFI, or by providing the relative path to the Publication Document for the Rendition, as the value of an epub:rendition attribute.
If an li element is meant to refer to a geometric region of a Fixed Layout Document, then a Media Fragment URI should be used.
TBD - the Media Fragment URI spec does not currently support geometry for circle, ellipse or polyline - we need to add those.[q]
To indicate that the ul element contains a set of rendition mapping locations in its child li elements, it must specify the value “resource_map“ in its epub:type attribute.
Examples
The following example shows a Rendition Mapping Document for a magazine with 3 Renditions: text, portrait and landscape. ‘article 1’ is on pages 5 and 6 of the fixed layout Renditions and the landscape Rendition uses spreads (non-synthetic).
<html>
<head>
<meta charset="utf-8"/>
</head>
<body>
<nav>
<ul epub:type="resource_map">
<!-- First Page of the Article 1 -->
<li>
<a href= "../../text/default.opf#epubcfi(/6/8[article1.html]!/4/2:20" />
</li>
<li>
<a href="../../images/page5.png"
epub:rendition="../../portrait/portrait.opf"[r] />
</li>
</ul>
<ul>
<!-- Second Page of the Article 1 -->
<li>
<a href= "../../text/default.opf#epubcfi(/6/8[article1.html]!/4/22:40" />
</li>
<li>
<a href="../../images/page6.png"
epub:rendition="../../portrait/portrait.opf" />
</li>
</ul>
<ul>
<!-- Article 1 -->
<li>
<a href= "../../text/default.opf#epubcfi(/6/8[article1.html]!" />
</li>
<li>
<a href="../../images/page5-6.png"
epub:rendition="../../landscape/landscape.opf" />
</li>
</ul>
</nav>
</body>
</html>
The following example shows a multilingual EPUB Publication with each language in a separate Rendition.
<html>
<head>
<meta charset="utf-8"/>
</head>
<body>
<nav>
<ul epub:ty[s]pe="resource_map">
<!-- Chapter 1 -->[t]
<li><a href = "../../en/en.opf#epubcfi(/6/2)" /></li>
<li><a href = "../../fr/fr.opf#epubcfi(/6/4)" /></li>
<li><a href = "../../de/de.opf#epubcfi(/6/2)" /></li>
<li><a href = "../../es/es.opf#epubcfi(/6/6)" /></li>
<li><a href = "../../it/it.opf#epubcfi(/6/2)" /></li>
</ul>
<ul epub:type="resource_map">
<!-- Chapter 2 -->
<li><a href = "../../en/en.opf#epubcfi(/6/4)" /></li>
<li><a href = "../../fr/fr.opf#epubcfi(/6/6)" /></li>
<li><a href = "../../de/de.opf#epubcfi(/6/4)" /></li>
<li><a href = "../../es/es.opf#epubcfi(/6/8)" /></li>
<li><a href = "../../it/it.opf#epubcfi(/6/6)" /></li>
</ul>
<ul epub:type="resource_map">
<!-- Chapter 3 -->
<li><a href = "../../en/en.opf#epubcfi(/6/6)" /></li>
<li><a href = "../../fr/fr.opf#epubcfi(/6/8)" /></li>
<li><a href = "../../de/de.opf#epubcfi(/6/6)" /></li>
<li><a href = "../../es/es.opf#epubcfi(/6/10)" /></li>
<li><a href = "../../it/it.opf#epubcfi(/6/8)" /></li>
</ul>
… could be even more fine grained for better results ...
</nav>
</body>
</html>
The Rendition Mapping Document’s location is identified in the Container Document using an [OCF301] link element child of the root container element, where:
The following example shows the container.xml file for a multilingual EPUB Publication. The location of the Rendition Mapping Document is included in the link element.
<container version="1.0"
xmlns="urn:oasis:names:tc:opendocument:xmlns:container"
xmlns:rendition="http://www.idpf.org/2013/rendition">
<rootfiles>
<rootfile full-path="en/en.opf"
rendition:language="en"
media-type="application/oebps-package+xml"
/>
<rootfile full-path="de/de.opf"
rendition:language="de"
media-type="application/oebps-package+xml"
/>
</rootfiles>
<link href="renditionMapping.html"
rel="mapping[u]"
media-type="application/xhtml+xml"
/>
</container>
This section is informative
This section provides an informative model by which the Rendition Mapping Document could be processed by a Reading System. It does not address how or when a Reading System should switch Renditions.
The desired outcome of the Rendition Mapping Document’s mapping capabilities is to display content in the new Rendition that is equivalent to their location in the current Rendition, so that a user maintains their place during reading. To accomplish this goal, a compliant Reading System might follow these steps to reset the current Rendition when a change condition is triggered:
Note that what happens during navigation is largely a user experience issue, so a Reading System may choose to consider additional information than above to try to achieve a better outcome.
The schema for Mapping Documents is available at http://www.idpf.org/epub/renditions/multiple/schema/epub-rendition-mapping.rnc[v].
Validation using this schema requires a processor that supports [RelaxNG] and [XSD-DATATYPES].
Active members of the working group included:
IDPF Members
Invited Experts/Observers
[ContentDocs301] EPUB Content Documents 3.0.1
[DCMES] Dublin Core Metadata Element Set, Version 1.1.
[DCTERMS] DCMI Metadata Terms.
[HTML5] HTML5: A vocabulary and associated APIs for HTML and XHTML.
[MediaQueries] Media Queries . Florian Rivoal. 19 June 2012.
[OCF301] Open Container Format 3.0.1.
[Publications301] EPUB Publications 3.0.1.
[RelaxNG] ISO/IEC 19757-2: Regular-grammar-based validation — RELAX NG. Second Edition. 2008-12-15.
[RFC2046] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (RFC 2046). N. Freed, N. Borenstein. November 1996.
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.
[RFC3986] Uniform Resource Identifier (URI): Generic Syntax (RFC 3986). Berners-Lee, et al. January 2005.
[RFC3987] Internationalized Resource Identifiers (IRIs) (RFC 3987). M Duerst, et al. January 2005.
[RFC5646] Tags for Identifying Languages (RFC 5646) . A. Phillips, M. Davis. September 2009.
[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition). T. Bray, et al. 26 November 2008.
[XSD-DATATYPES] XML Schema Part 2: Datatypes Second Edition . Paul V. Biron et al. 28 October 2004.
[a]Makoto MURATA:
I think that this introduction has to be a bit weaker than now. Some requirements on adaptation (such as customizing names of heroes or heroines) are not covered by this spec.
[b]Makoto MURATA:
I think that EPUB 3 conformance of RSs and AHL conformance of RSs should be separated., and we should make this separation explicit. In my understanding, the EPUB 3.0.1 specifications collectively specify one class of conformance, which is a set of conformance requirements. This AHL spec should not change this class (otherwise, existing RSs will become non-conformant).
[c]Ori Idan:
It is not very clear that this section (2.2) speaks about metadata.xml
Also the name and the root element seem to confuse with the OPF metadata.
[d]Matt Garrish:
These conformance sections should only be read as starting points for discussion.
[e]Makoto MURATA:
I am not sure if this "MUST" is right. But we have first make clear the relationship between 3.0.1 conformance of RSs and conformance in this spec.
[f]Makoto MURATA:
I am not sure if "MUST" is right here. But to really make things clearer, we have to clearly define what is our conformance. A part of 3.0.1 conformance? Or another class of conformance?
Takeshi.Kanai:
There might be cases that Reading Systems are not able to support full range of attributes. For instance, it is not possible to evaluate rendition:lang if RS do not possess such user preference, and RS might support a few set of rendition:media. I think we should say those RS meet the conformance.
[g]Matt Garrish:
Adding this RS req similar to what we did for FXL in place of this prose:
Reading Systems should ignore foreign rendition selection properties.
What "foreign" is isn't exactly clear, as we don't control the content model. Anyone could drop another attribute in the same namespace, and we don't want to say it must ignore all attributes not defined in this specification, do we? (I'm not sure if future specs could make additions, but better not to block that off, I think.)
Feel free to disagree, as there may be better wording I'm not thinking of.
Makoto MURATA:
If some property is foreign, it should not be called "selection property". So, I would like to propose the following
Reading Systems shall ignore attributes that are not selection attributes as defined in 3.4.
Matt Garrish:
Should we include a modifier: "or defined by other IDPF specifications"?
This would add some extensibility.
[h]Makoto MURATA:
See other comments on conformance.
[i]Matt Garrish:
My assumption again, but we should state expected behaviour here.
Takeshi.Kanai:
It is a good point and it should be treated as false. But since expected behavior will be defined by rendition selection algorithms, I don't think it is necessary to mention about how "not all" affects to Rendition selection. I mean expected behavior should be the same with other "false" cases.
[j]Takeshi.Kanai:
This is acceptable for now, but I think it is necessary to discuss about how to merge recent FXL changes (scrollable?, I forgot the final decision, though) into this document.
Matt Garrish:
That's the rendition:flow attribute, which defines paginated, scrolled-doc and scrolled-continuous for overflow handling.
I think you'd need another attribute.
At the rendition level, the attribute is exclusive to reflowable since overflow FXL content is clipped.
But I suppose someone might create an FXL rendition for when only paginated is supported and reflowing when scrolls are supported, which would only be possible at this level.
Takeshi.Kanai:
Could be. So, the issue is whether we should introduce rendition:flow immediately or not. I would like to say NO and would like to see how rendition:flow will be used.
[k]Makoto MURATA:
Is this evaluated as true or false? Or, is this evaluated to be a numeric value representing priorities? What happens when second language is used?
Matt Garrish:
Also, how are region codes handled? And do we need to state evaluation is case insensitive?
[l]Takeshi.Kanai:
I think the property itself is good, but am wondering what will happen if a rendition requires multiple user preferences. For example, if a rendition has rendition:accessMode="textual" and rendition:layout="pre-paginated", but user's preference is "visual" and "pre-paginated", the rendition will be ignored even though it meets one of preference settings. In this case if accessMode would not been written in rootfile, the user could access to the rendition and it might be what the user wanted to read.
It might be necessary to solve this "between two stools" issue.
[m]Makoto MURATA:
I am wondering if we should have a repeatable element rather than an attribute.
1) Different elements can have different xml:lang, thus allowing automatic selection of such an element by RSs.
2) It becomes easier to introduce elements for BIDI and other textual markup. Best Practices for XML Internationalization (http://www.w3.org/TR/2006/WD-xml-i18n-bp-20060518/) is an old spec, but we should read it carefully.
[n]Takeshi.Kanai:
I think this is a discussion point. The original intention was that it enables Users to select an appropriate rendition. For example, we can put both K-12 contents and K-20 contents into one ePub file and I'm expecting K-12 or K-20 will be written in this field.
Makoto MURATA:
I also think that RSs should expose values of this attribute.
Matt Garrish:
I had asked similar in the context of our needing xml:lang and the response was that it was not for display. I think the response may have mixed up what I was asking.
I then have a couple of questions about this attribute:
1) how does the language of the text get expressed? We will need this for a11y, at least. We can use xml:lang, since validation requires stripping namespaced attributes, but we need to make clear that it should always be used.
2) should the attribute perhaps be called rendition:label? "description" is not as clear that it is for manual selection.
Takeshi.Kanai:
The issue #1 was addressed but has not yet reached a conclusion. Please see the original draft.
Basically, I agree with you and the language should be expressed with xml:lang.
As for #2, it seems the name was discussed in the F2F meeting. Actually it was rendition:title. I can't recall what made this change at that time, but I have no strong objections to your proposal. Let's decide it in a con call.
[o]Makoto MURATA:
Is the omission of this attribute non-conformant?
Matt Garrish:
Changed to should to match the optional nature in the package document for now.
[p]Makoto MURATA:
I think that this has to be "SHOULD".
Matt Garrish:
I made a "must" because the RS conformance is to ignore attributes not defined in this spec. That suggests when this spec is recognized it should take precedence, but I don't have a strong opinion.
[q]hadrien.gardeur:
I don't think that this is an absolute requirement.
It's good to have, but also raises many questions regarding the W3C and their specs.
[r]Hadrien Gardeur:
Could we make this consistent with CFI ?
In one case, the OPF is referenced in href, in the other it's in target.
Jim Lester:
I don't see a good way to make this consistent with the CFI, especially in the case where the URI in the href includes a media fragment (Note: The sample should probably include this variant as well)
Hadrien Gardeur:
Selecting a rendition is very similar to selecting a track in media fragments.
Jim Lester:
Sample Syntax?
Hadrien Gardeur:
Here's an example extracted from media fragment for tracks: rtsp://example.com/media#track=audio&track=video
Hadrien Gardeur:
Which could be something like: <a href=”../../images/page5.png#rendition=fxl” />
Makoto MURATA:
Should we use CFIs here? I see no advantages in using CFIs in rendition navigation documents. I see disadvantages: verboseness and and inability to reference fragments in non-default renditions. I propose not to use CFIs in this spec.
hadrien.gardeur:
Ideally, I would avoid CFIs too.
CFI is useful if we want to point precisely somewhere in a text but don't have an ID to do that. For the rest, we're better off with media fragments.
Makoto MURATA:
True. But do we need such ID-less text chunk for rendition mapping? Anyway, we cannot use CFIs for non-default rendition unless we invent another scheme.
hadrien.gardeur:
We can use CFIs with internal references to an OPF, so in this case, CFIs work with all of our renditions.
But I'd much rather avoid them, if possible.
[s]Brady Kroupa:
should this use hidden attribute?
[t]Brady Kroupa:
do we we need this?
Jim Lester:
No but it's possible, and instructive for the sample
Jim Lester:
The original question was about the use of an <h1> element. The new HTML restrictions for the Rendition Navigation document prevent it's use - so I replaced it with a comment.
[u]Jim Lester:
Is mapping the rel value we want to use? What are the other possibilities?
Hadrien Gardeur:
In a link, you usually use both the rel and the media type to understand the relationship with the current resource.
Here, the link says: "This is a mapping (rel) that uses XHTML (type)"
[w]Makoto MURATA:
This topic is in the EPUB 3.0.1 issue list .https://code.google.com/p/epub-revision/issues/detail?id=352&q=metadata.xml&colspec=ID%20Spec%20Status%20Revision%20Owner%20Summary
[x]Makoto MURATA:
IIt appears that we are not adding *additional* restrictions but rather introducing different restrictions. Am I correct?
Jim Lester:
Yes. The semantics are different than the nav doc case. For instance there is no 'order' in the maps, so using an unordered list instead of a ordered list makes more sense.