Rewrite renditions to publications

[mattgarrish]

Just an experiment at this point so we can review what the changes would entail, but there aren't that many required to effectively go back to where we started with EPUB 3.0:

• all instances of Rendition are rewritten to refer to the EPUB Publication
• the "Packages" section is dropped as that was more a creation to account for publications moving to the "EPUB 3.2" specification
• the requirements for packages become requirements for publications again, and the package document definition and publication identifier sections move up under "EPUB Publications"

The only place where anything substantive changes is the container.xml section, but even those changes are pretty minor so long as we aren't deprecating multiple rootfile elements. All we need to say is the first rootfile represents the package document for the publication. We can keep the requirement that if there are others they all must reference package documents of the same version, but otherwise we can leave the existing note that there isn't a broadly supported means of selecting. The links note only needs to say that we don't define any requirements for its use in this specification.

That leaves the Multiple Renditions specification as a viable option for those who want to pursue that technology. The framework for having them remains in place, but they are no longer an active consideration of the core specification.

Reading Systems preview
Reading Systems diff

---

Preview | Diff

[dauwhe]

This strikes me as exactly the right approach. Multiple renditions are not part of the EPUB core, but are something that can be done by extending OCF via multiple root files.

[murata2makoto]

The term "rendition" continues to appear many times. Most of them occur as part of key words, and they cannot be removed. Other occurrences of "rendition" also exist. I am not sure if this rewrite is more understandable. It certainly has potential incompatibilities.

[mattgarrish]

The term "rendition" continues to appear many times.

Only as the namespace for the fxl properties, which can't be changed. There isn't a link between the prefix and multiple renditions.

It certainly has potential incompatibilities.

Could you elaborate?

[murata2makoto]

For example, is "The Package Document is an XML document that consists of a set of elements that each encapsulate information about a particular aspect of the EPUB Publication. These elements serve to centralize metadata, detail the individual resources that compose the Package and provide the reading order and other information necessary to render the EPUB Publication. " in the proposed rewrite of EPUB 3.3 correct? Elements in a secondary Package Document are not necessary for rendering the first Package Document.

[iherman]

I agree that the document is way more readable this way. The "rendition" terminology really makes the current spec difficult to read. I would therefore be in favor of the change (and yes, there may be some rough edges, like the one raised by @murata2makoto).

However...

That leaves the Multiple Renditions specification as a viable option for those who want to pursue that technology. The framework for having them remains in place, but they are no longer an active consideration of the core specification.

I want to understand what this exactly means. I believe that, looking at #1436, there is no consensus of removing the feature from EPUB 3.2. What would this "Multiple Rendition" specification mean? I see some alternatives:

1. have a separate rec-track document alongside the content, RS, and A11y
2. as above, but not as a rec-track document but as a note (i.e., becoming non-normative)
3. have a separate section in (probably) the RS document about multiple rendition (t.b.d whether normative or informative) with maybe some words/hints somewhere in the Content document

It is not clear to me whether the multiple rendition part should be normative. Seeing the very low number of implementations if it is normative we would have difficulties to pass the CR bar. Ie, (2) or (3) remain the alternatives. At this moment I do not have a clear opinion which of the two.

[murata2makoto]

@iherman

I support your second alternative, which is to create a WG note.

[mattgarrish]

Elements in a secondary Package Document are not necessary for rendering the first Package Document.

Right, but this is where the multiple renditions specification comes in. It should be where the concept of renditions are fully explained. As it is, it still refers to 3.0.1 where the terminology is defined, so that document should still stand alone. But republishing it as a note with more information about the "default rendition" and the alternatives is fine with me.

As I said in the issue, I'm fine with keeping the framework in place, but I don't think where we've ended up with spillover of concepts between the documents helps anyone.

[iherman]

If we decide to go along this PR's lines, and we opt for my second option above (which, after some thoughts, is my favourite) then I think we should create a first draft of that note asap, and publish it alongside the FPWD of the spec. Otherwise, our message would be misunderstood and some may think that we plan to completely remove multiple rendition from EPUB 3 (which, looking #1436, is probably something we shouldn't do).

[iherman]

The issue was discussed in a meeting on 2020-12-04)

• no resolutions were taken

View the transcript

2. Removing multiple rendition from core spec

See github issue #1436.

See github pull request #1438.

Wendy Reid: multiple rendition is not widely implemented, and people have mentioned that references to it complicate understanding of the core spec
… we can remove references to it from the core spec, and have it live as a satellite document outside the spec

Dave Cramer: I think of multiple rendition as an extension of epub only. The way we've had to write the spec because of this remote possibility has degraded the readability of the spec
… and multiple renditions have always been optional
… therefore multiple renditions should be epub adjacent, but not a core aspect

Ivan Herman: Referring everyone to the discussion in the PR
… some Japanese RS and content does use it
… Matt's PR: Took the core spec and removed references to multiple rendition from the text. Not removing the technical possibility of having multiple renditions.
… it may not have been clear from the PR that the intention was to have guidance about multiple renditions exist in a separate document
… we are not removing anything that was previously possible under the spec, just editing the spec to make it more readable

Garth Conboy: i support getting language about multiple renditions out of the core spec, while still allowing the possibility of multiple renditions

Gregorio Pellegrino: from an a11y point of view and a EU a11y act point of view, multiple renditions could be a way to meet requirements. Therefore multiple renditions make take on a greater importance in future.

George Kerscher: I do a11y test for RS and I can see testing multiple renditions being a nightmare
… could we somehow indicate to ebook buyers that an alternative reflow version of a given fxl ebook is available, and meet the EU a11y requirement that way?

Dave Cramer: we don't want to deprecate anything
… also what is in the core spec about multiple rendition right now, alone, is not sufficient to implement multiple renditions
… because the spec is silent on rendition selection
… moving all the language about multiple rendition into a satellite wouldn't negatively impact compatibility with EU a11y
… having a satellite spec might even draw more attention multiple renditions (people who are interested in using it can just go to that separate document)

Avneesh Singh: I've definitely seen multiple rendition in action. e.g. with Readium
… re. the EU a11y act, the act doesn't require guidance about multiple renditions to be in any specific document
… we would be okay even if the EU mandates multiple renditions

Hadrien Gardeur: although multiple renditions have been supported by Readium for a long time, we haven't actively worked on it for a long time. Its more a proof of concept
… since it seems like the only thing we have at our disposal to address the EU directive is multiple renditions, we've been focusing on it. But it might not be the only way. Maybe there is another way to address the requirements of the EU directive
… maybe there could be a less involved, more streamlined way to meet the EU directive requirements

Tzviya Siegman: +1 to looking for better solution than MR for EUAA

Wendy Reid: +1

Dave Cramer: See reference of a standalone IDPF document

Zheng Xu (徐征): as long as we don't have a new OPF or anything that require us to implement a new parser, RS implementers should be satisfied
… nor would publishers want to implement new packages that may or may not be backwards compatible

Garth Conboy: for right now we can go with Matt's PR, and 6 months form now, if the EU directive requires us to bring it back in, then we can consider that step

Ivan Herman: I propose not to come to any resolution at this point. We should wait until next week where the Japanese contingent will be in attendance, esp. as a lot of the comments on the issue were regarding Japanese RS, content

Avneesh Singh: +1 to Ivan, we need to listen to Japanese community

Garth Conboy: maybe we can come to an interim resolution now, and then revisit it next week with our Japanese members

Avneesh Singh: agree that we can still alter course after we receive more clarification about how the EU directive impacts us
… in June 2021

Proposed resolution: Close issue #1436 and merge PR #1438 to remove mentions of multiple renditions in the core specification (Wendy Reid)

Tzviya Siegman: Tzviya: One of the goals of this group is to make FXL accessible, in which case we won't need Multiple Renditions for a11y

Garth Conboy: +1

Tzviya Siegman: +1

Zheng Xu (徐征): +1

Matthew Chan: +1

George Kerscher: +1

Charles LaPierre: +1

Brady Duga: +1

Wendy Reid: +1

Ivan Herman: +1

Avneesh Singh: +1 in principles, but better to do editorial improvements

Juliette McShane: +1

Hadrien Gardeur: +1

Wendy Reid: we're just collecting votes in the record this week
… we're not resolving this week. We'll wait for additional discussion next week with our Japanese members.

---

[murata2makoto]

Multiple renditions are used by BPS for accessible textbooks. An EPUB textbook contains a print-replica rendition for mimicking the original printed textbook as well as a more accessible rendition as a collection of reflowable HTML documents. Rendition mapping is used for allowing students to switch from the print-replica rendition to the accessible rendition (and vice versa) without losing the current position.

I think that this usage scenario is very sensible and advanced. It is a reality in Japan. Does anybody have a better scenario for making textbooks accessible without throwing away sophisticated layouts?

It is true that the current EPUB 3.2 is less readable due to multiple renditions. But this is because of backward-compatibility requirements as well as inappropriate use of HTML for rendition mapping, IMHO.

What we should do is to improve multiple renditions. Pretending multiple renditions do not exist in EPUB 3.3 makes EPUB 3.3 a bit more readable for those who would like to ignore multiple renditions, but this does not really solve problems. For those who care multiple renditions, EPUB 3.3 will become less readable.

[iherman]

Pretending multiple renditions do not exist in EPUB 3.3 makes EPUB 3.3 a bit more readable for those who would like to ignore multiple renditions, but this does not really solve problems. For those who care multiple renditions, EPUB 3.3 will become less readable.

I do not agree. The proposal is not to ignore multiple rendition; it is to separate that feature into a dedicated document. This helps both the readers of the spec who do not care of multiple rendition (which is the overwhelming majority of the readers!) but also who want to use the feature because, instead of trying to read between the lines of an already complex spec, can find some details on that feature in a dedicated place. I must admit I do not see the problem with that.

[murata2makoto]

@iherman

also who want to use the feature because, instead of trying to read between the lines of an already complex spec, can find some details on that feature in a dedicated place.

Here we disagree.

For example:

These elements serve to centralize metadata, detail the individual resources that compose the Package and provide the reading order and other information necessary to render the EPUB Publication.

in EPUB 3.3 will have to be interpreted like:

These elements in a Package Document serve to centralize metadata for the rendition represented by this Package Document, detail the individual resources that compose the rendition and provide the reading order and other information necessary to render that rendition of the EPUB Publication.

I think that this interpretation is hard.

[mattgarrish]

in EPUB 3.3 will have to be interpreted like:

Not really. EPUB 3.3 would be a return to 3.0/2.0 lineage and no one claimed those were confusing documents. The wording simply becomes:

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

For the vast majority of producers, an EPUB publication is, and will only ever be, what the one package document represents. We've built a house of cards by adding "renditions" and "packages" too late into the EPUB core when few people will ever need to worry about why this is even possible. The fragility of the specification and difficulty in keeping it consistent are greatly enhanced by trying to maintain these concepts.

As I mentioned above, the multiple renditions specification can clarify that this first package document represents the "default rendition" to which it explains how to access others. That's what we hacked into the core specs in 3.0.1 to try and build this in the first place, so moving it all to the multiple renditions document doesn't realistically change anything. It should make everything much simpler again. Only the people actually interested in multiple renditions need to be aware of the issues surrounding them.

I'm slowly working on another pull request that will add that missing context.

[mattgarrish]

Let's also not lose sight of the fact that multiple renditions has awkward workarounds due to its lateness in creation that would likely never make it a good fit in the core. Because EPUB has a long-established history of one package document being the publication, the whole notion of "publication metadata" had to be hacked on top of the existing framework that prioritizes the first package document as the publication.

The less we have to drag the average producer into this world of renditions the better.

[murata2makoto]

@mattgarrish

the whole notion of "publication metadata" had to be hacked on top of the existing framework that prioritizes the first package document as the publication.

I agree that this is one of the worst parts of multiple renditions. I wonder if we paid too much attention to imaginary backward compatibilities of reading systems at that time. Of course, it is too late to fix this in EPUB 3.X.

Not really. EPUB 3.3 would be a return to 3.0/2.0 lineage and no one claimed those were confusing documents. The wording simply becomes:

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

I still do not like "necessary to render the EPUB publication".

We might want to explicitly say that an EPUB publication is allowed to contain multiple package documents but EPUB 3.3 does not define the semantics of multiple-rendition publications.

[mattgarrish]

We might want to explicitly say that an EPUB publication is allowed to contain multiple package documents but EPUB 3.3 does not define the semantics of multiple-rendition publications.

Right, this is one of the sticking points I see in reverting back to the 3.0 wording. We have to avoid the "exactly one" requirement of a package document without re-introducing "packages".

But each "rendition" is one rendering of the publication, so it is true that a package document defines a rendering of the publication. It's just not the only one possible. We can certainly make that clear.

(And to re-iterate, the rewrite here is still a work in progress, hence why I only labelled it an experimental branch. I still need to give it a more thorough read.)

[mattgarrish]

I also think we have a significant incompatibility with multiple renditions in the OCF spec. The very last paragraph of the container.xml section says:

OCF Processors MUST ignore foreign elements and attributes within a container.xml file.

There's no clear explanation of what constitutes a "foreign" element or attribute in the specification, but given that we've used the requirement to strip attributes from other namespaces from the container.xml file to validate multiple rendition attributes, the only logical conclusion here is we require reading systems to ignore rendition selection.

This statement dates back to the 3.0 revision, but OCF 2.0.1 only required reading systems to ignore unrecognized elements and attributes.

[GarthConboy]

I think Matt's proposal is an excellent one -- retaining multiple renditions (as it is a rarely used feature, retaining backwards compatibility), but also making our main specifications much more readable and understandable. We can discuss further on our next call -- that is why we voted last week, but did not formally resolve.

[murata2makoto]

@GarthConboy

I think that we need text before making a decision.

[iherman]

@GarthConboy

I think that we need text before making a decision.

I do not think so. It is perfectly fine for the WG to take a resolution in principle, considering this PR as a first step. Obviously, the final text will have to be reviewed along the lines of the problems you raised (and others that may still come), but I have not seen any arguments so far to fundamentally question the general lines. We are still far from a final spec. Actually, if a FPWD is published including this approach it would give a clear signal to a wider community to comment and draw attention to possible other inconsistencies that may occur. We have then about a year to get to a technically final (ie, CR) version...

[murata2makoto]

@iherman

I'm still worried that this change hides problems rather than addressing them. Accessibility via multiple renditions is a good thing in general. Are we going to make it less visible in EPUB 3.3 because most people are slow adaptors?

I can live with a decision if it promises to allows multiple renditions clearly.

[llemeurfr]

@murata2makoto is still worried, so to move the balance, I'll comment that I'm in favor of @mattgarrish proposal, already endorsed by several other members of this group. It is possible to find a wording in the core spec that does not put any focus on multiple renditions, with a companion document which details how multiple renditions can be created. It's a matter of careful wording and I'm 100% confident that Matt will find it.

The argument of accessibility is imo insufficient:

First, to my knowledge, the DAISY format does not support multiple renditions (with the EPUB 3 definition).

Second, specialized producers of publications for the blind have already difficulties moving from the DAISY format to EPUB 3, therefore moving from single renditions (in DAISY) to EPUB 3 (synchronized) multiple renditions is quite a high wall to go through.

Third, we should not take the EU Accessibility Directive for more than what it is: high level requirements, where "rendition" is a generic notion: an alternative publication is, at such high level of semantics, an alternative rendition. TTS is also an alternative rendition. And I would be surprised if National laws issued from the Directive are much more specific in their wording.

[murata2makoto]

@llemeurfr

Multiple renditions are already used by commercial digital textbooks in Japan. Several commercial companies are involved. I am not aware of any alternative scenarios for switching from fixed-layout and reflowable (and accessible) layout (and vice versa) without losing current positions.

[iherman]

The issue was discussed in a meeting on 2020-12-11)

List of resolutions:

• Resolution No. 1: Remove mentions of multiple renditions from the core and reading systems documents, close issue Remove multiple renditions from EPUB 3.3 #1436 and merge PR Rewrite renditions to publications #1438.
• Resolution No. 2: Publish Multiple Renditions as a Working Group Note.
• Resolution No. 3: Publish Overview as a Working Group Note.

View the transcript

Content:

• TOC

---

Matthew Chan: Topic 1: Multiple Renditions.

See github issue #1436.

See github pull request #1438.

Wendy Reid: this is continuing the discussion from last week.
… the suggestion is to remove references to multiple renditions from the main document of the spec.

Dave Cramer: the possibility of multiple renditions has always been in epub.
… but has not achieve a lot of uptake.
… i'm not aware of any major RS that supports it.
… with those references in the spec, the precision of the language required becomes cumbersome.
… it also gives casual readers of the spec the impression that multiple renditions is more prevalent than it is.
… Matt G's idea is to have those references to multiple rendition moved from where they currently are (scattered throughout the spec) into a satellite document.
… Matt G has already started this process of editorializing the spec.
… the satellite would be a WG note, and not a Rec track document.

Garth Conboy: there is at least one RS that supports it, so it makes sense to still keep multiple rendition functionality in the spec.
… that's why I am in favor of Matt G's direction.

Shinya Takami (高見真也): multiple renditions are currently used in Japan, mostly for educational purposes.
… but I agree with moving the multiple rendition specific portion of the spec to a separate document as long as this means that multiple renditions are not deprecated.

Dave Cramer: Readium also had some support for multiple renditions.
… at the time Microsoft was working on epub support in Edge.
… as part of that process, they found some oddball things in the spec that they found confusing.
… if another browser were to ask for advice on supporting epub today, I would recommend that they not support multiple renditions.

Marisa DeMeglio: wish we could go back to 2008 and reverse the decision to support multiple renditions.
… support is kind of mess right now.

Brady Duga: the first thing that we tell you about epub in the spec is something about multiple renditions, I can see how that is confusing.

Garth Conboy: +1.

Proposed resolution: Remove mentions of multiple renditions from the core and reading systems documents, close issue #1436 and merge PR #1438. (Wendy Reid)

Shinya Takami (高見真也): +1.

Marisa DeMeglio: +2.

Toshiaki Koike: +1.

Garth Conboy: +1.

Brady Duga: +1.

Masakazu Kitahara: +1.

Resolution #1: Remove mentions of multiple renditions from the core and reading systems documents, close issue #1436 and merge PR #1438.

Wendy Reid: to keep all the documents together, Ivan has proposed that we publish the multiple renditions piece as a note.

Dave Cramer: here is a link to the old IDPF version.

Dave Cramer: See Old IDPF Version of the multiple rendition spec.

Proposed resolution: Publish Multiple Renditions as a Working Group Note. (Wendy Reid)

Garth Conboy: +1.

Matthew Chan: +1.

Wendy Reid: +1.

Marisa DeMeglio: +1.

Brady Duga: +1.

Ben Schroeter: +1.

Shinya Takami (高見真也): +1.

Masakazu Kitahara: +1.

Resolution #2: Publish Multiple Renditions as a Working Group Note.

Wendy Reid: one of the other documents we have to publish is the overview note that ties everything together.

Wendy Reid: See Draft Overview.

Proposed resolution: Publish Overview as a Working Group Note. (Wendy Reid)

Wendy Reid: +1.

Brady Duga: +1.

Toshiaki Koike: +1.

Shinya Takami (高見真也): +1.

Wendy Reid: this is the overview document that is the introduction to the spec.

Masakazu Kitahara: +1.

Matthew Chan: +1.

Garth Conboy: +1.

Resolution #3: Publish Overview as a Working Group Note.

[iherman]

I guess Figure 1 should also be changed/simplified.

[iherman]

I guess Figure 1 should also be changed/simplified.

I have just created:

https://docs.google.com/drawings/d/1Gv-inOCWyZq_i1mzrjOlOC-A52QPeCqdvtcX2zZAmiY/edit?usp=sharing

[mattgarrish]

I'm closing this PR and will open a new one to discuss possible final text for inclusion.