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 15:28:00 UTC