Standardization of multiple-rendition publications

[KikkiZ]

Section

https://w3c.github.io/epub-specs/epub34/authoring/#sec-container.xml-rootfile-elem

Describe the problem

There is such a Note in this chapter:

Although the EPUB container provides the ability to reference more than one package document, this specification does not define how to interpret, or select from, the available options. Refer to [epub-multi-rend-11] for more information on how to bundle more than one rendering of the content.

This indicates that the EPUB3.4 specification is not clearly defined for epub publications with multiple rendered versions, and the document they reference also conflict with this specification. There are some other issues with this document.

• multiple rootfile selections are blurred
  When multiple rootfile elements exist under rootfiles, it indicates that there are multiple package documents for that publication. For multiple package documents, the specification does not specify which document should be the default document. This means that the EPUB library for spec-based operations relies on developer preferences rather than specifications when handling such cases. Of course, this issue is pointed out in the [epub-multi-rend-11] specification and addressed, but this is not a specification recognized by W3C and therefore has the potential to be overlooked.
• the number of <link> elements requires conflicts
  In the 4.2.6.3.1.4 subsection of this specification, it is mentioned that the link element has 1 or more, while in the 5.4.4 subsection of the [epub-multi-rend-11] specification, it is required that there can be only one at most.

All in all, the EPUB3.4 specification has a lot of ambiguity in the handling of multi-rendered version publications, which leaves room for future versions to expand, but it will cause a lot of confusion when using the current version. So I think these issues should be considered and addressed as soon as possible.

Describe the fix or new feature you propose

No response

[mattgarrish]

Unfortunately, there's been no interest from reading systems and little interest from publishers in supporting multiple renditions. The note you mention was previously part of the specification but was removed in 3.3 because of the lack of implementation. Multiple renditions was originally published by the IDPF which didn't have implementation requirements, but W3C process requires at least two interoperable implementations.

Attempting to define multiple rendition behviour normatively again without any buy in just leads back to the same implementation problem and having to remove it again from 3.4 when it moves to recommendation.

But specifically to the issues you've raised:

• For multiple package documents, the specification does not specify which document should be the default document.

No, not in the authoring specification. The reading system specification defines this behaviour:

"A reading system MUST, by default, use the package document referenced the from first rootfile element [epub-34] to render the EPUB publication."

• the number of <link> elements requires conflicts

I don't see a conflict here. The epub 3.4 specification does not define a use for links so it doesn't restrict how many there can be. The multiple renditions note doesn't say there can only be one link element, only that there can only be one link element that references a mapping document.

That said, I doubt any other technology but multiple renditions will make use of container links, so in reality links could be restricted to 0 or 1 link elements right now. But I would still leave the definitions the way they are since predicting the future is a fool's errand. If multiple renditions as defined in that note never gets support, then there's conversely a strong case we should eventually obsolete the links element.

[HadrienGardeur]

Multiple renditions came back in our discussions recently and we might bring them up at TPAC. Too early to say what we'll do though.

[rickj]

I continue to see zero interest in multiple renditions from education publishers

[mattgarrish]

Multiple renditions was supposed to be the fix for inaccessible fixed layouts and didn't pan out. I'm not hopeful things are different this time.

(Web publications also drove a stake into multiple renditions, as even though we never could find a consensus on what a web publication should be there was no desire to perpetuate that there could be multiple versions of them bundled together.)

[gregoriopellegrino]

Many of the publishers we work with use "handcrafted" solutions to offer users dual content viewing: fixed layout and reflowable, within specially developed reader apps. This is particularly true in the educational publishing sector.

In most cases, "synchronization" is managed at the pagelist level. Perhaps there is room for a more robust and common best practice that suppliers are required to follow?