Thread: element "u" not allowed anywhere
View Single Post
Old 04-23-2014, 03:46 AM   #35
Rev. Bob
Wizard
Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.
 
Rev. Bob's Avatar
 
Posts: 1,760
Karma: 9918418
Join Date: Feb 2013
Location: Here on the perimeter, there are no stars
Device: Kobo H2O, iPad mini 3, Kindle Touch
Quote:
Originally Posted by Toxaris View Post
There is a lot that can be interpreted in different manners. Some are minor (auto margins), but some are major and handles structure. Good specifications and standards should not leave room for interpretation. It should be clear what is and what isn't correct.
You're equivocating between two meanings of the term interpret.

EPUB has specs, expressed as DTDs, that exactly define the permitted structure. That's a statement of fact; that's what a DTD exists to do, and both EPUB 2.0.1 and EPUB 3.0 have one. In a conflict - a validation error - between a given EPUB and the spec it claims to follow, the DTD is right, literally by definition. In that sense, there's no fuzziness, no room for "interpretation" in the first sense - there's just Correct and Not Correct.

The "interpretation" you're talking about is the second sense, on the rendering side, which is about how a given engine processes a document, and there are several reasons to allow fuzziness on that side. For instance, an audio rendering engine (remember, DTB stands for Digital Talking Book!) has no use for visual instructions, and is therefore free to disregard them.

The rendering engine exists to convert a standard-format document into something usable on whatever hardware is running that engine, and since there's all sorts of different hardware out there, that means we need all kinds of different trade-offs. That has implications that go both ways, though; just as an author can't rely on colors for emphasis because audio and grayscale devices exist, those devices should also have some way of indicating that those cues exist. A valid document should never break a rendering engine; if it does, the engine is faulty. However, an invalid document is by definition broken, and while it's good for engines to be tolerant of minor errors, an author should always assume that any invalid content will break in some engine, somewhere, that didn't build in that level of fault tolerance.

Both parties play a role, and the author's is to make sure that they provide clean content that is well-formed and as easy to process as possible. Doing so means the document works for the widest audience, and that's never a bad thing.
Rev. Bob is offline   Reply With Quote