10 July 2013
This article is a high-level commentary on why ePub3 is dismal failure, and why it is both unnecessary and a failure in 2013. This article is linked with the E0 launch strategy.
I have received a number of critical, corrective and supportive comments on this post. It has been heavily edited to include the suggested changes. It now reads substantially differently from the "first edition". Thanks all for the fact checks and corrections.
This dicussion Continues in the post: July 2013 Was EPub3 Month
EPub3 has failed, but digital publishing will be stronger because of it. I'd like to make some high-level comments on why EPUB3 is unnecessary, in advance of the soon-to-be-launched E0 packaging format.
If you are interested in the back-story you can read about E0 on the E0-blog and on the EPUB-NG Google Groups discussion forum here. We have also posted on the E0 format subject previously. Infogrid Pacific is not a direct contributor to the E0 specification, but we are using our digital content practioner strengths to allow it to be evaluated and tested. We have ePub3 production, distribution, deliver and reading solutions.
The reason for this article is as a lead-in for a lot of exciting stuff we are about to release on E0. Yes that used to mean ePub Zero, but because EPUB is a trademark we now need to think and say E0 means eBook Zero.
any specification needs to go through implementation, testing and feedback
We think is that any specification needs to go through implementation, testing and get feedback (following the lessons learned by the W3C). Rather than pile features into written specifications the important dimension is to "hasten slowly" with implementation feedback. For that there has to be an implementation! We did that with ePub3. In fact we were the first, we gave feedback, we were slapped down.
The implementation/feedback loop is in fact is many times faster than writing unworkable specifications and hoping they are implemented.
Readium and iBooks is what most people think of when they think of ePub3. In their own different ways both are specification implementation failures. Both do a reasonable job with reflowable content and handle a few of the easy to implement TOC, Landmarks, Page TOC features. With fixed layout both fail miserably to address the real treasures in the spine properties.
Because of the market failure of ePub3 to be adopted at all, or correctly by anyone, there was a serious market requirement for a re-evaluation of the business of eBook distribution formats. The result. E0. That was done by independent, thinking and concerned individuals who understood the IDPF was simply getting it all wrong.
It is important to fight for a particular ideal with a clear sense of right and wrong. With E0 the publishing world is fighting against the mainstream IDPF player that cannot, or does not want to see, their wrong is wrong.
an active counter-culture must be actively considered and reviewed by the market
It is a fact that a specification that engenders an active counter-culture must be actively considered and reviewed by the market. With ePub3 we are seeing the same effect as the unworkable XHTML 2.0 specification (dropped for HTML5). The inevitable result is a return to reality, basics and creating a specification that is relevant, works and addresses market needs.
The modularization of the ePub3 specification does not make it real if there is no implementation and feedback.
E0 was both timely and a publishing world-wide need. While "Another format" upsets a lot of people we are in a generation of look-alike ideas, where even start-ups are not disruptive. Like XHTML 2.0, ePub3 has some good ideas, totally drowned by proprietary, limiting and publisher business threatening silliness. Hence the inevitable need for a reality check, a new format and a reboot of the current thinking.
It's hard to define this type of failure. The committee authors are possibly well-intentioned but survive in a strange, isolated, Schema, echo chamber world.
Historically, there's been a close connection between Adobe and the IDPF. Bill McCoy, the executive director, used to work for Adobe. Nick Bogaty (executive director from 2002–2007) now works for Adobe. Peter Sorotokin (until recently an Adobe employee, now with Google) has been a driving force in all the EPUB working groups.
While the Adobe dominance worked in 2007, the tablet driven Apple upper-hand came forth in 2011 with the iPad human-robot user-base and made a substantial change to digital reading.
More to the point, EPUB was written by reading system developers, with very little participation by publishers, authors, human readers or other interested parties. A lot of the complexity of EPUB came from making life easier for reading system developers and by making life harder for content creators, the theoretical main-players.
And it's mostly the same people as before...
The redundant manifest is just one example—computers are quite capable of determining which files are in the zip folder, and can easily determine their content type.
And it's mostly the same people as before—Peter Sorotokin, Garth Conroy, Brady Duga, Bill McCoy (who is a big influence technically even though he's the executive director now).
Interestingly Apple has had a fairly minimal presence in the actual EPUB3 working group, and have no employees on the IDPF board of directors. They were mostly one of the elephants that's weren't in the room. They were a huge influence on FXL, because they implemented it before the spec existed (as it should be done). They did it in a reasonable way, with essentially pure HTML+CSS and a minimal set of metadata. Their update to ePUb3 FXL in iBooks was very well done.
EPUB3 is creating fragmentation, rather than minimizing it
It is interesting to see how Apple delicately picked the good from the specification and the features they wanted to use while leaving the cruft behind.
The business aspects of the ePub3 specification weaknesses and the failure and irrelevance have been discussed in detail by others more expert than myself in many articles and posts. Here are a couple of examples:
The core point is ePub3 has just missed the technology boat the world is currently riding. The IDPF have been gum-flapping the word advancement, while talking about ePub2 backward compatibility. Is that an Oxymoron?
Nearly all EPUB3 reading systems, if they exist at all, offer only partial support for the specification. EPUB3 is creating fragmentation, rather than minimizing it. This almost appears to be an agenda. Parts of it are so complex that they will never be implemented, and certainly never be supported in production environments when that is required. Essentially no one is actually creating and distributing EPUB3, even though it's been nearly two years.
ePub3 should have been a quantum shift in digital content packaging
EPub3 is significantly irrelevant in the fast changing digital content world because it has stopped being a packaging and reading system specification and now sets content prison rules.
What is horrifying is the "CSS Profile", where EPUB3 picks and chooses which small bits of CSS it deigns to support. It would appear not forbidding all of EPUB3 is the same as supporting all of EPUB3. This was the Adobe story for not supporting the CSS display property in ePub2 and destroying the presentation potential of so much content. Their response? It's not in the specification (because our rendering engine doesn't support it). We are in the same loop.
Books and book structure are a minor and simplistic subset of digital content, addressed adequately by ePub2. Therefore the reluctance by most publishers to change to ePub3/same but different. On the surface the 2013 EPub3 is the same as the 2007 ePub2 with a bit of a make-over that doesn't seem matter. EPub3 should have been a quantum shift in digital content packaging to match the speed at which change is needed.
Infogrid Pacific has supported ePub3with the AZARDI reading system, sophisticated production tools and online tutorial resources. As mentioned before and as a leading edge practical implementor we also discovered very early on the stupidities and nonsense factors built into the specification, have commented appropriately and have been criticized harshly and punished.
The specification was released in October 2011. We released AZARDI supporting ePub3 on the 21 November 2012.
Apparently we have to be an ignored voice as we are outside the IDPF. We haven't "joined" the IDPF because it is relatively expensive and there are no tangible benefits for a small company. There are any number of small companies who apparently like their name on the IDPF list even though they are not allowed or can't contribute anything.
While AZARDI is the only real, available ePub3 reading system available anywhere, and Infogrid Pacific have produced the largest set of available supporting ePub3 potential demostration documents, ePub3 testing documents and tutorials and transparent reading system design documents we can see politics is more important than facts.
I do find Bill McCoy's zealotry in defense of EPUB3 to be troubling with his attacking any comments that are critical of EPUB. There appears to be an agenda; it's a Big Brother Censorship thing that trys to use the "power-of-office" as a threatening force. Where is the dialogue? Apparently ePub3 is absolutely perfect.
As it is we have real-world users of AZARDI ePub3 in over seven countries with more than 250 thousand users in formal implementations, not counting the over 150,000 informal downloads. Interestingly those numbers are small compared to the AZARDI ePub2 downloads in 2009.
The ePub3 failure has ultimately been good for publishing. Let me explain.
The debate that has emerged is "Is ePub3 relevant" or are Apps, Web Apps or pure HTML5 a better option. Obviously everything is correct. EPub3 could have a place as do Apps, Web Apps and pure HTML5. EPub "any number" works against these options due to its backward look view of content and with its awkward and business crippling OPF file. The packaging itself has little value.
For publishers who are creating their ebooks on the desktop and not using a reasonable production method that preserves the value of the content nothing matters. Do what you do. Junk in, junk out. Pay the toll to Adobe/Apple.
The value of ePub3 is that the files must be HTML5 (the full spec is assumed). Everything else is noise so E0 had to be born.
Amazon is out of this particular discussion. The KF-8 format and the Kindle tablet is orders of magnitude sadder than ePub3.
Obviously production houses around the world have to instantly fall into line and state how they produce the best KF-8 files available. Publishers say thank you. But KF-8 is trivial. So trivial it is embarrassing to admit we produce the best KF-8 stuff around.
We really need mediocre eBook formats to see the noisy minor market of eBooks limp forward a mediocre notch in a mediocre reading system. When something like KF-8 defines the digital content state of the art in 2013, publishers need to weep!
The E0 objective is to release the potential of digital content, not shackle it
What cannot be understood is how truly bad KF7 (.mobi) is. Amazon must be aware of thousands of significant bugs at this point, and they clearly have a policy to never fix them. Who can understand the reasoning? Dishwashers and street sweepers around the world take more pride in their work than Amazon management does.
Another question: what about Inkling? Something like $US100 million has been invested in them; most of it from Google? Quite interesting, since Google now employs most of the core EPUB authors (Garth Conboy, Brady Duga, Peter Sorotokin). In some sense they're doing exactly what iBooks Author does—take the HTML5+CSS+JS idea and cut it free from EPUB packaging and constraints.
But remember our soon to be released test suite is just that. An invitation for feedback (to the E0 project) and improvements. The E0 objective is to release the potential of digital content, not shackle it.
The creative geniuses of the world do not need Amazon or IDPF limiting and constraining defining rules, laws, dictionaries, fixed/reflowable content and a lot of other nonsense processing. Publishers need this 2005 DocBook crowd to just go away. The world needs an HTML5 framework that works now!
EPUB3 adoption has always been 18 months away for the last two years. It is a mysterious shifting target.
Easy. We care about the mechanics of this stuff. Infogrid Pacific is a small organization in the massive publishing business. Perhaps it is that small size, depth of experience and independence that gives us a clarity of view. We are practioners, we have our clients, we want to deliver value. We don't want to win format wars. We don't want to be the biggest company in the world. But we don't want to eat nonsense either.
We have AZARDI, without question the most specification compliant ePub3 reader currently in existence. We directly say what we can and cannot do. We support the ePub3 specification because it is the specification of the day and we support it very well. We support it because it allows us to package and deliver highly interactive education, training and learning content at a fraction of the price of Apps. But even the small guys like Infogrid Pacific have to speak against something that is so obviously wrong.
The E0 specification has done everything in which ePub3 has failed. A simple package with more sophistication and usefulness than ePub3. A simple, forward looking complete solution with more elasticity and flexibility than ePub3 will ever be able to deliver.
Make sure you keep in touch for the very big, very significant E0 announcements to come shortly. That means reading system, test cases, sample books. Implementations, testing, feedback. You know, everything the IDPF does understand or care about!
Even more importantly. Test and give feedback. That is the point of the exercise.
Posted by Richard Pipe
Start a real digital content strategy with
The complete digital publishing content management and production solution.
Available as for Small and Medium publisher:
IGP:Digital Publisher is also available as a full site license purchase.
Use one master XHTML file to instantly create multiple print, e-book and Internet formats.