Re: Deep concerns about the future of EPUB

Le 26/12/2017 à 14:24, Siegman, Tzviya - Hoboken a écrit :

> Hi Daniel,
> 
> 
> I am probably not the person you were hoping to hear from first, but I
> was co-chair of the 3.1 WG, and I co-chair the Publishing WG, so I have
> some strong opinions. 

Hi Tzviya. I am not hoping for one person's answer in particular.
The situation is critical and has to be handled by everyone
consensually.

> I think you raise some excellent points. One thing to keep in mind as we
> consider the way the EPUB and Publishing ecosystems work is that most
> books and publications are saleable (at least for now). This adds a
> layer of complexity to the ecosystem. It is not insurmountable, but it
> exists.

Sorry, this is not the main problem. The main problem is the lack of
software updates on reading systems. Some RS in the wild are even too
old to be updated to a recent rendering engine.

>   - why is 3.1 such a failure?
> We have not yet released a version of epubcheck that supports 3.1. We
> are short on developers and/or funding. If we do not get one or the
> other, it will never gain any traction. 

I think that played a minor role, really. Judging from my talks with
the publishing industry all around the globe, people were just not ready
to move to 3.1 while their migration to 3.0 was only starting. The lack
of 3.1 epubcheck is a minor extra disturbance.

>   - why didn't the understandable warnings above serve as showstoppers?
> I am partially to blame for this, but at the time, Murata-san's concerns
> about 3.1 seemed to be more about it being a lot of work than it being a
> show stopper. The EPUB WG voted on the issue and agreed to move forward.

The february 2016 letter seems pretty clear to me.

> We cannot affect industry-wide adoption any more than the W3C can make
> sure that all websites are WCAG AA compliant. Some of the goals of 3.1

This is not a valid comparison. The Web is backward-compatible, EPUB is
not at all.

> I believe it is, but we have to gain an understanding of what backward
> compatibility means and with which systems we will comply. For example,
> will we retain epub:switch, invented for EPUB 3 but supported almost
> nowhere or use MathML's native altimage?

Your question contains its answer, IMHO. EPUB should *not*, under any
circumstance, add anything special to content documents. Rendering
engines' vendors will never implement it. Every time we've put extra
stuff or extra constraints to EPUB content documents, we ultimately
faced painful consequences.

>   - why is EPUB making any kind of recommendation on content documents?
> Going forward, we hoped not to. But, that puts a wrench in your
> statements about backward compat. Doesn't it?

I don't think so. Backward compat is about making a recent RS read an
old ebook.

>   - how do we define workable exit criteria for specs that do represent
>     interoperable implementability and ensure market openness?
> As long as we're in W3C, we have the same implementations rules as
> everyone else (2 implementations).

I disagree. Here are the exit criteria for DPUB-ARIA 1.0:

  For this specification to be advanced to Proposed Recommendation, it
  has to be proven that roles defined in this specification have
  sufficient usage by the target communities. More specifically, it has
  to be documented that each Digital Publishing Role is used (at least
  in preliminary prototypes, not necessarily in full production yet) by
  two, independent document author/publisher as a means to structure
  document

This is not an implementation report, this is a usage report and that's
entirely different. These exit criteria do NOT ensure interoperable
implementability and they're not based on a test suite.

</Daniel>

Received on Tuesday, 26 December 2017 14:16:00 UTC