Consider adding non-normative text to the OCF spec to better describe the state of multiple renditions

[BCWalters]

When developing a new EPUB parser/reading system, it's very difficult to understand which OPTIONAL features are broadly used. The concept of multiple renditions is one of the worst offenders of this. It would helpful to add a section or a paragraph explaining why multiple renditions exist and where and if readers and tools will ever encounter them--give new tool authors and reading system developers a better chance to make an informed decision about whether they should support features like this.

[JayPanoz]

FYI we (Readium) have had a discussion about multiple renditions not so long ago: https://docs.google.com/document/d/1-Yq2QP-GNHZwE1y6NO_KVD2zaQ0JB35_C0LJ8GzGhDA/edit?usp=sharing | cc @llemeurfr

Feedback was provided by authors who happen to use them, and 2 participants even implemented multiple renditions – but used their own flavor for ≠ reasons, not the spec per se.

[mattgarrish]

Isn't this sort of what epubtest.org was supposed to do?

I'm just not sure it's a good idea to put this in the specification. While I doubt we're about to see a flurry of support for multiple renditions, it's information that seems like it would be better maintained outside of revision cycles.

[BCWalters]

The spec serves two purposes:

1. It defines all things that are legal in any in EPUB file for the sake of validation/epubcheck/etc.
2. It helps people construct, transform or display real EPUB files and understand and decide features they should use or implement.

Historically, it does seem like epubtest.org tried to do the second of those things, but it just didn't do a very good job at it when it comes to providing understanding of features like multiple renditions (I don't mean to judge--for various reasons, it's extremely difficult to build and maintain an exteremely useful test suite like that).

Realistically, the EPUB community, and especially folks that are relatively new to working with EPUB would save huge amounts of time in their efforts if we pushed a few selective bits of guidance like this into the spec itself. While we never supported multiple renditions in Edge, we talked about them repeatedly, inspected EPUB files in public archives and our catalog to see if they were used, searched through various resources, and then repeated these discussions when new members or teams worked on various pieces of the reading system.

[dauwhe]

I find the whole situation confusing. EPUB 3.2 itself says that support for multiple renditions is optional:

An OCF Processor MUST consider the first rootfile element within the rootfiles element to represent the Default Rendition for the contained EPUB Publication. Reading Systems are REQUIRED to present the Default Rendition, but MAY present other Renditions in the container.

But most of what would make multiple renditions actually workable, such as a rendition selection mechanism, is in the Multiple Renditions spec, which is not part of EPUB 3.2.

The longest discussion of multiple renditions in 3.2 is in the non-normative overview doc:

In addition, multiple instances of a complete work can be delivered in a single EPUB Publication by defining multiple rootfile elements in the OCF container file (as described in Container File (container.xml) [OCF32]). These alternate Rendition fallbacks might be used, for example, so that a formatted graphic novel defined via a sequence of SVG pages can be accompanied by an accessible text version defined via XHTML.

In both places, I'd be fine with a note mentioning that many reading systems do not support multiple renditions. I'd be happy ripping them from the spec entirely, but that's not a task for the 3.2 revision :)

[mattgarrish]

But most of what would make multiple renditions actually workable, such as a rendition selection mechanism, is in the Multiple Renditions spec, which is not part of EPUB 3.2.

Right, because we've sort of flipped and flopped on support for other renditions of the content over the years. In EPUB 2, alternate renditions were identifiable by a different media type (e.g., PDF). EPUB 3.0 kept around the option to have multiple renditions, but was silent on what format they could be or how you would differentiate them. 3.0.1 changed it so that all the renditions have to be the same version, but again didn't get into selection.

In the meantime, people have implemented their own versions of rendition selection, which is why the features of the multiple rendition specification can't even be enforced. They're just a recognized way you could implement selection.

That's why EPUB Multiple-Rendition Publications 1.0 came into existence, with the idea that it might become part of OCF to fill in the gap.

But while rendition selection has some promise, it seems to be more an interesting theory than a widespread need. A lot of the complexity isn't even in the basic selection of one version over another, but in how to make switching between versions a reality. Rendition mapping documents are a nightmare, as who's going to wire up every "significant" location in one document to its corresponding place in another?

But multiple renditions "the specification" is just an extension, which is why I don't see the value of detailing its current failings within OCF, unless I've misread why "multiple renditions" we're talking about here. Why not detail the lack of implementation of all the other satellite specs, then?

I doubt we can do away with the facilities for implementing multiple renditions, as they're core to the OCF container, and there is supposedly an implementation of them out in the wild (not conforming to the MR spec). That's why any integration of the MR specification looked destined to be weak, anyway, as it couldn't require its practices be followed this late in the game.

But if the question is just should we note that the ingrained support for additional renditions in the OCF exists but isn't recommended, that would be fine with me.

[BCWalters]

I'd be happy adding either flavor of note:

1. Indicate that supporting multiple renditions isn't recommended
   or
2. Indicate that they're not widely supported by reading systems.

Either way, at least we'd be giving new readers to the spec an indication that they should probably spend their time on other things unless they're building an end to end ecosystem of content + clients.

[GarthConboy]

I'd generally side with Ben's #2 above (though could live with #1).

[mattgarrish]

What about a note like the following:

Although the EPUB Container provides the ability to include more than one rendition of the content, Reading System support for multiple renditions remains largely unrealized. Attempts to standardize rendition selection within EPUB have not improved support. Multiple renditions are only known to be implemented in controlled environments where the purpose and meaning of the renditions is established by the involved parties.

Authors and developers are advised to consider this reality before implementing support in workflows and reading systems. The ability to include multiple renditions is also not guaranteed in future major versions of EPUB.

Too dramatic?

[dauwhe]

That's the best thing I've read today!

[danielweck]

Fake news! Make EPUB3 Multiple Renditions great again!

Joking apart, sounds good to me ;)

[mattgarrish]

Make EPUB3 Multiple Renditions great again!

Sad!

(That it failed to go anywhere, that is... ;)

[BCWalters]

Sound good to me.

[avneeshsingh]

I think that notes about state of implementations should not be in the specifications. It may live in a separate document. Such notes can have cascading effect and discourage further implementations.

Yesterday we had discussions about attractive EPUB 3 features that can encourage DAISY members to move to EPUB world from DAISY world, and some of the group members stated that multiple renditions is one of the attractive feature for people with disabilities, and it is sad that reading systems do not provide good support for it. i.e. its an chicken egg question.

So we decided that we will gather some feedback from some DAISY members to evaluate utilization of multiple renditions.

[GeorgeKerscher]

Also, we know there are problems with fixed layout, and having a reflowable version would be great IMO. Also, some companies (that are now W3C members) do not accept fixed layout. Best George From: Avneesh Singh <[email protected]> Sent: Thursday, August 30, 2018 7:21 AM To: w3c/publ-epub-revision <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [w3c/publ-epub-revision] Consider adding non-normative text to the OCF spec to better describe the state of multiple renditions (#1066) I think that notes about state of implementations should not be in the specifications. It may live in a separate document. Such notes can have cascading effect and discourage further implementations. Yesterday we had discussions about attractive EPUB 3 features that can encourage DAISY members to move to EPUB world from DAISY world, and some of the group members stated that multiple renditions is one of the attractive feature for people with disabilities, and it is sad that reading systems do not provide good support for it. i.e. its an chicken egg question. So we decided that we will gather some feedback from some DAISY members to evaluate utilization of multiple renditions. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1066 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AG3HSMlyVS5mj9gIjHM0pXoVx1qXi6N7ks5uV-bVgaJpZM4VXnUB> . <https://github.com/notifications/beacon/AG3HSMRrpqnCaGRHnZDrmO0dAkw9oynbks5uV-bVgaJpZM4VXnUB.gif>

[GarthConboy]

Somewhat toned down per Avneesh's comments:

How about “Note that support for Multiple Renditions has received minimal implementation outside certain specialized controlled environments.”

[avneeshsingh]

We can explain it a little more (picking up from proposed text)
support for multiple renditions received minimal implementation outside specialized environments where the purpose and meaning of the renditions is established by the involved parties.

[dauwhe]

Closed via #1121