We may by dealing with semantics but in the real world there is a difference between standards and paper specifications. Standards are tied to actual products and there are penalties for not adhering to them (as MS discovered when they licensed Java and didn't read the buried fine print).
Specifications simply list product features and components or attributes.Epub aspires to be a standard but the bodybthat drafted the specification did not tievit to any product nor is their any meaningful certification process that say; you either pass this test or you can't call it epub. Such a test must by definition require ecactly the same performance on all certified products. (DVDs are supposed to play the same way on all DVD players regardless of what code lies underneath; epubs display differently pretty much everywhere.)
A "standard" without a certification process and penalties for incomplete/improper compliance is just a specification in disguise. Without a meaningful certification process the ebook products that people can buy will follow the defacto standard set by adobe just as in the early days of PCs the standard for PC compatibility wasn't MS-DOS, but rather Lotus 1-2-3 and Flight simulator. If it ran those, it was deemed PC compatible and it stayed that way until MS finally asserted their control with MS-DOS 5. ("DOS ain't done until Lotus won't run", says the legend.)
Regardless of what the standards body says, in real world terms, adobe controls epub: If it won't display properly in ADE, it isn't "proper" epub in the eyes of the buying public. And since every eReader supporting ePub with DRM uses adobe code, everything else is up the creek; pay adobe its fees or try to convince the customers that the inconsistencies that *will* arise aren't your fault.
Heck, even licensing from adobe won't prevent that; just ask the folks with Hanlin-based readers...
Last edited by fjtorres; 10-26-2009 at 02:03 PM.