playOrder attribute in EPUB
| Project: | EPUB Maintenance |
| Component: | Validation |
| Category: | bug report |
| Priority: | normal |
| Assigned: | MGylling |
| Status: | completed @ 2.0.1 |
Jump to:
I have seen a number of files failing EPUBCheck because of the playOrder rules. I think these rules were not sufficiently studied and discussed before being imported from DAISY. As a result valid EPUB files of any meaningful length are almost impossible to hand-craft, because content editing forces one to renumber those - often for no good reason. My intent is to flag this as a big pain point in the spec so we can discuss it, I do not have a particular opinion on what should be done about it.
Description
Issue Id:
22
Resolution:
The proposed resolution is to amend the errata with an entry that makes the NCX playOrder attribute optional. This is a backwards compatible change.
- Login to post comments
Comments
#1
It's certainly a pain point for me. At least for the books we do, the playOrder values contain no information--they could easily be derived from the structure of the NCX.
#2
I agree, they provide no additional information. But they are only a minor annoyance, I can usually set them correctly with a regexp search&replace on vim.
#3
#4
I agree that playOrder is annoying (for ebook developers) and not informative (for reading systems).
#5
Agreed. Any work on this is extremely tedious.
#6
I agree that the playOrder imposes restrictions (read: pain) on EPUB creators without providing a value beyond what is expressed more unambiguously from the structure of the NCX.
#7
I understand that when epubs ship with NCX's that only contain a navMap, this attribute is completely useless, and causes grievance. The problem that playOrder is designed for is to allow swift current position updates when an NCX contains a navMap, a pageList, and several navLists.
Imagine a recipe book with a navMap for the chapter structure, a pageList for the print edition pages, and navLists for different types of recipes (one navList with all recipes of the book that contains chocolate, another navList for all recipes not containing gluten), etc. The user navigates (via the pageList) to page 535, and then via the UI invokes the "next chocolate recipe" action (which means: take me to the "next" entry in a particular navList). The question becomes: which entry in the given navList is the "next" in reading order?
Given playOrder, the reader implementation can achieve this navigation simply by navigating to the entry in the given navList which has a playOrder value equal to or higher than the value of the playOrder value of the pageList target corresponding to 535.
There are indeed other ways to solve to above (concretely: move forward in the content document until the current element is an element whose ID matches the fragment of the target URL in the given navList, if any) but for resource-constrained devices, they are more costly than the playOrder approach (which in the end has a negative impact on the user experience).
Anyway - that was to explain its original rationale. I see two alternate solutions here:
1) The ANSI/NISO Z39.96 (aka DAISY) spec is currently being revised [1],[2]. One of the revision targets is to modularize the NCX so that it can be customized for particular domains. In other words, in a coming revision of EPUB, we could create an epub-specific version of the NCX, that deals with playOrder in the way we prefer, as well as adding any other features that we may want (such as pageLists for different editions, which Mr Sorotokin has been asking for). In other words - the resolution now would be a future direction to "fix" the NCX in the next revision of EPUB.
2) Eventually do 1 above, but in the shorter term publish an errata that makes the playOrder attribute optional, and having spec prose that recommends using it when the NCX contains more than one map/list. In other words - the resolution now would be a hackish errata entry, and a future direction to "fix" the NCX in the next revision of EPUB.
Thoughts welcome.
[1] http://www.digitaltalkingbook.com/zw/Main_Page
[2] http://code.google.com/p/zednext/
#8
I can see the rationale for playOrder, and syncronization of reading location, page number and TOC entry is indeed a complex problem. Unfortunately playOrder is not a comprehensive solution: it does not cover all possible navigation scenarios in EPUB, for instance, a lot of times navigation happens through links or external (user-saved) bookmarks. In that case TOC and page number synchronization has to happen through content lookup - threre is just not much choice. And if I have to have that logic in my Reading System anyway, why would I use playOrder? I could possibly save some CPU cycles by syncing only to a page and determining TOC entry from that, but (a) it is complex logic and (b) only small percentage of ebooks have page number info. I think playOrder should be made optional.
#9
I appreciate getting a better sense of the utility of it, so thanks Markus.
But I also agree with Peter; I could achieve the same effect by simply calculating the order expressed in the navMap in memory. I suppose there are theoretically-large books and limited-RAM environments where that might be difficult, but as Peter says it's inevitable that some kind of dynamic lookup will be required when implementing any kind of user-driven navigation.
I think just changing it to 'optional' would solve most people's problems, which is validity.
#10
The proposed resolution is to amend the errata with an entry that makes the NCX playOrder attribute optional. This is a backwards compatible change.
#11
I second the proposal to make playOrder optional as it will not cause any problems with the conformance of existing ePub, as Markus notes.
#12
#13