RE: Deep concerns about the future of EPUB

Just to be clear, I basically agree with everything Ric wrote here (and I
have a role in Readium project also).  We clearly have a lot of work to do
to improve the level and completeness of EPUB 3 adoption throughout
publishing and need to be quite thoughtful with further work on EPUB 3.x.x
to advance that goal. And, being more rigorous with things like requiring
implementations and test suites before finalizing specs should be strongly
considered. So I too thank Daniel Glazman for raising awareness on these
points.

The only thing I'm fundamentally in disagreement with Daniel on is his
contention that the only/best solution to this is to move EPUB 3.x.x
development into a WG immediately, including accepting wholesale the
entirety of the W3C Process for developing Recommendations. I don't see that
as a magical fix to the actual issues, and there are significant impediments
given the nature of EPUB 3 development to date and commitments made to the
industry in conjunction with the combination of IDFP with W3C. As a
practical matter, getting such as WG chartered could leave us 6 more months
in limbo. So I would much rather see the EPUB 3 CG (hopefully with Daniel's
active participation) nimbly determine how to rapidly and effective move
forward, with input and guidance from the Publishing BG, as per the
respective charters that are already developed and approved.

I also have a slight issue with some of Daniel's more alarmist/judgmental
language in his original email in this thread but that's a secondary point.

--Bill

-----Original Message-----
From: Ric Wright [mailto:rkwright@geofx.com] 
Sent: Thursday, December 28, 2017 7:26 AM
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>; Bill McCoy
<bmccoy@w3.org>; public-publishingbg@w3.org
Cc: 'Jeff Jaffe' <jeff@w3.org>; 'Tim Berners-Lee' <timbl@w3.org>;
eb2m-mrt@asahi-net.or.jp
Subject: Re: Deep concerns about the future of EPUB

I have been following this thread with great interest (Daniel, thanks for
raising this).  There are a lot of good thoughts and arguments on all
fronts.

That said, I tend to agree with many of the points Daniel has made here.
My perspective is from that of a Reading System developer/maintainer.
There are two key points I would make:

Support for all the varieties of EPUB:
A point I have raised a number of times is that adding new or changed
features to EPUB often sounds like a good idea, but as a RS, we *HAVE* to
support all variants and features from 2.0 to the latest - now and forever.
So incompatible or changed features are hugely problematic. At this point,
Readium supports virtually all of 3.0.1 but we havenıt even considered any
of the new features in 3.1 (weıre short-handed anyway, but even if we
werenıt...).  The net-net is that I, as director of Readium, want to see
what the value-added is of new features (and that they are being used)
before we invest the time and effort to support them.

Validation of Existing Implementations:
At this point, Readium supports around 90% of the features in 3.0.1 as
measured by the EPUB TestSuite. But that being said, this isnıt really a
very good metric.  The EPUB TestSuite is an excellent tool as far as it
goes, but it is significantly flawed in several ways. Here are three of
them:
1. Almost 40% of the features it tests are really browser-level
functionality. So it is not really testing the Reading System, but the
browser engine the RS is built on top of (I think RMSDK was the last RS that
built its own engine). This is important, of course, but a little misleading
as to what is being tested and how thoroughly.
2. The features are tested in a very atomic way, one isolated feature at a
time. This is understandable and the right way to start, but that vast
majority of bugs and issues Readium encounters are more complex
interactions, or odd variants of features.  I cannot offhand recall a single
bug we have encountered lately that was found through, or could be tested
with, the EPUB TestSuite.  To be clear, the TS is very valuable, it simply
doesnıt go anywhere near far enough.
3. There are few if any failure cases.  Or stress cases. The TS is so
constructed such that the tests are clean and well-behaved.  If only the
content we received from all and sundry were equally well-behaved. :-) The
TS should also be testing the RS to see how they handle errors.  In some
cases, the EPUB spec does in fact specify how errors or bad and/or illegal
content should be handled, but the TS doesnıt test these. One small example:
For reasons none of us who were there can recall, declarative SVG animation
is not allowed in EPUB files.  EPUBCheck dutifully complains about
(declarative) SVG animation, but the TS doesnıt test that such content is
ignored.  The overhead to disallow such content in a RS is quite large, so
Readium simply doesnıt bother and SVG animation works fine even though it
should be rejected.  Again, to be clear, the TS is an awesome batch of work,
it just isnıt enough.

My two cents, FWIW.

Ric



On 12/27/17, 4:23 AM, "Daniel Glazman"
<daniel.glazman@disruptive-innovations.com> wrote:

>Le 26/12/2017 à 19:02, Bill McCoy a écrit :
>
>> That being said I think you're engaging in a logical fallacy by 
>>claiming that a single mistake by the IDPF EPUB WG over a year ago 
>>implies that we must now radically rethink the way W3C Publishing@W3C 
>>groups are structured in general, as well as how ongoing development 
>>of EPUB 3 will be handled specifically.
>
>I respectfully disagree 100%. If the market is already unable to digest
>3.1 six years after the release of 3.0, when will it be able to digest 
>4.0, Web Publications, Portable Web Publications and more? Given the 
>EPUB 3 situation, any investment now on WP, PWP, EPUB4 is too early and 
>too expensive. The EPUB market is just unable to absorb a new spec 
>every three years. Our whole model is flawed.
>
>I suggest we take that chartered time to make a 3.x version conform to 
>regular W3C exit criteria, with a test suite and real implementation 
>reports, and reach W3C REC (instead of "Recommended Specification" IDPF
>designation) instead of diving into useless expensive blue-sky dreams.
>
>*THAT* would be *immensely* useful to *everyone*.
>
>Let me repeat myself on one important point: backwards-compatibility 
>requirements of EPUB increase as the EPUB market increase. They will 
>become mandatory soon. An ebook is an ebook is an ebook. Nobody wants 
>to maintain several technical versions of the same ebook for a given 
>technology, nobody wants to update (at a cost) ebooks published eons 
>ago that should just work, nobody wants to leave legacy reading systems 
>unattended because it could kill the ecosystem, and we're not even able 
>to get rid of our ugliest design choices any more. Hence my
>conclusion: EPUB is a dead end. A technological disruption will happen, 
>it's not a question of "if" any more but only a question of "when".
>
></Daniel>
>

Received on Thursday, 28 December 2017 16:48:21 UTC