RE: Deep concerns about the future of EPUB

> Again, to be clear, the TS is an awesome batch of work, it just isnıt
enough.

It never really had aspirations to be the thing you want it to be, too. I
don't recall any reading system developers were even heavily involved in
putting it together. Its ambition was to test some essential rendering
issues that were poorly supported in EPUB 2 or new to EPUB 3 to kickstart
and improve support in the early days. It then morphed with the BISG support
grid, further taking it into the territory of a caniuse-like input.

Matt

> -----Original Message-----
> From: Ric Wright [mailto:rkwright@geofx.com]
> Sent: December 28, 2017 10: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 19:08:33 UTC