Re: [External] My opinions about the future of EPUB 3.2

Luc,

I believe there is common ground between everything you have summarized (all of which I agree with), and the points I have been making.  Let me elaborate:

  *   There exists a need (some would say urgent) to clarify the confusion in the marketplace around ‘which version of EPUB to use’, especially when the conversation starts to align with the ISO discussion(s).
  *   Their appears (initially, and needs subsequent investigation) to be an opportunity to address this (and other needs) by moving 3.2 into a rec track.
  *   EPUB has always, historically, lived a dual life as both a distribution format, and a rendering specification.
  *   Addressing the needs of a distribution format have a (somewhat, and needs subsequent discussion) clear path that needs a strong marketing effort, supporting tools, and clear metrics for evaluation to motivate adoption in the marketplace.
  *   The BG could be the focal point for these efforts, and I am looking to foster a discussion on the merits of doing just that (taking 3.2 forward in a rec track).
  *   At the same time, there exists numerious (and well elaborated by many, and summarized well by yourself) reasons to also provide clarity around the rendering side of EPUB by reading systems.
  *   The proposals (to create detailed compliance levels in the spirit of the work done for WCAG, and to ‘fix the broken contract that bugs are evidence of’) are excellent, and could build on top of a 3.2 rec track specification.
  *   Much like the WCAG effort, this is a significant task, and should not hold up efforts to rec track 3.2, but should build on that work.
  *   IMO such an effort would require CG, BG, and WG efforts to accomplish (and the requesite recharting to do so).
-Rick


From: AUDRAIN LUC <LAUDRAIN@hachette-livre.fr>
Date: Wednesday, October 31, 2018 at 2:11 AM
To: "Johnson, Rick" <Rick.Johnson@vitalsource.com>, Laurent Le Meur <laurent.lemeur@edrlab.org>, W3C Publishing Business Group <public-publishingbg@w3.org>
Cc: Jeff Jaffe <jeff@w3.org>
Subject: Re: [External] My opinions about the future of EPUB 3.2

IMHO, I would state that interoperability IS a market issue, and reality is that today an EPUB that is perfectly conforming to the standard and thus perfectly distributable doesn’t necessarily operate correctly on some main Reading Systems.
It is an issue for final user who bought/lent the file, it is a business issue.

For the publishing industry, I totally support Laurent’s level of ambition : a compliance level of implementation, like the A, AA and AAA of WCAG a11y.
If we don’t bring interoperability on this ground, nothing will change.

I also fully support Dave’s view: “Bugs are evidence of a broken contract.”, “fixing what's broken is the only way I can think of to improve interoperability between publishers and reading systems.”
A specification is indeed some sort of contract between the content producer and the reading system.
Epubcheck is the checker between the file and the spec. Where is the tool to check the reading system toward the standards ? Laurent’s idea to renew epubtest.org as a “can I use“ for reading systems is a great one.

I hope that moving now under the W3C umbrella will give us PUBLISHING@W3C more visibility and power to improve our confidence in EPUB3 as a standard for the whole supply chain today.

Luc

De : "Johnson, Rick" <Rick.Johnson@vitalsource.com>
Date : mardi 30 octobre 2018 à 21:04
À : Laurent Le Meur <laurent.lemeur@edrlab.org>, W3C Publishing Business Group <public-publishingbg@w3.org>
Cc : Jeff Jaffe <jeff@w3.org>
Objet : Re: [External] My opinions about the future of EPUB 3.2
Renvoyer - De : <public-publishingbg@w3.org>
Renvoyer - Date : mardi 30 octobre 2018 à 21:03

I did not state that EPUB would be the proper tool for checking interoperability.  I said there would be dependencies on EPUBcheck in a scenario where we are looking to take 3.2 to a rec track, AND, where interoperability is defined only in the sphere of file distribution, not reading system implementations.

I remain in my belief that having interoperability of the file for distribution is an appropriate goal in considering a rec track for 3.2.  Encumbering that process by requiring  a single binary file to demonstrate interoperability between multiple reading systems is going to burden a rec track with market realities that will doom the process.

-Rick


From: Laurent Le Meur <laurent.lemeur@edrlab.org>
Date: Tuesday, October 30, 2018 at 9:05 AM
To: W3C Publishing Business Group <public-publishingbg@w3.org>
Cc: Jeff Jaffe <jeff@w3.org>
Subject: Re: [External] My opinions about the future of EPUB 3.2
Resent-From: <public-publishingbg@w3.org>
Resent-Date: Tuesday, October 30, 2018 at 9:04 AM

I don't agree that EPUBCheck is the proper tool for checking the interoperability we are looking for.

EPUBCheck is a validation tool, not an interop checker. This tool is there for a long time, EPUB files comply to its verdict, and still authors and publishers complain that they must test on several reading system to avoid very bad surprises.

-> Interoperability must be checked at the level of reading systems, not at the level of the EPUB files.

Note: if we define a feature interoperable when 2 reading systems implement it correctly, authors and publishers will still complain, and will be right to do so. We have to be more ambitious about the level of interop the industry need, if this is possible.

Is is really impossible to create compliance levels for reading systems, with a basic level applicable to any reader (with e.g. reflow only, images but no audio/video, pagination, support of links), plus a set of progressively more complex levels, each level getting a small set of features, features which the CG will have listed and described in the first phase of its work? I have already introduced this idea without getting any positive feedback, but no better alternative solution has been provided so far.

Laurent Le Meur
EDRLab




Le 30 oct. 2018 à 16:19, Jeff Jaffe <jeff@w3.org<mailto:jeff@w3.org>> a écrit :





On 10/29/2018 2:47 PM, Johnson, Rick wrote:
Jeff,

I believe that defining interoperability of the spec (on a feature by feature level) needs a more limited focus, which may differ from how the W3C has approached interoperability in the past.  What I am advocating for is interoperability of the spec for creation and distribution of a file, and to stop there (obviously highly dependent on EPUBcheck for this!).  Is it possible within the current process document (and common practice) to stop there, and avoid the discussion of ‘interoperability within the reading systems’ as a requirement?

I'm not sure I fully understand the question - but if I do - the answer is Yes.

W3C Recommendations specify some behavior, and to get to a REC level requires that the spec has been implemented interoperably.  Typically, we would like for test cases which validate at a feature by feature level that the spec has been successfully implemented.  I believe this is what you are referring to when you say interop for creation and distribution.

I'm not sure what you mean by "interoperability within the reading systems" - but I am interpreting that to be a sort of compliance and certification test whereby a standards organization certifies that an entire implementation (in this case a reading system) has implemented an entire spec.  That is generally beyond the scope of W3C Recommendations.





-Rick


From: Jeff Jaffe <jeff@w3.org><mailto:jeff@w3.org>
Date: Monday, October 29, 2018 at 11:15 AM
To: Laurent Le Meur <laurent.lemeur@edrlab.org><mailto:laurent.lemeur@edrlab.org>, Ric Wright <rkwright@geofx.com><mailto:rkwright@geofx.com>
Cc: Brian O'Leary <brian@bisg.org><mailto:brian@bisg.org>, W3C Publishing Business Group <public-publishingbg@w3.org><mailto:public-publishingbg@w3.org>, "Johnson, Rick" <Rick.Johnson@vitalsource.com><mailto:Rick.Johnson@vitalsource.com>, Ivan Herman <ivan@w3.org><mailto:ivan@w3.org>
Subject: Re: [External] My opinions about the future of EPUB 3.2
Resent-From: <public-publishingbg@w3.org><mailto:public-publishingbg@w3.org>
Resent-Date: Monday, October 29, 2018 at 11:14 AM



On 10/29/2018 1:30 PM, Laurent Le Meur wrote:
Whatever the business situation has been or will be, I learned from Jeff at the TPAC that to become a standard, each individual feature must be implemented twice, which could be a practical definition of interoperability. Hadrien reminded me that today.

But I don't find this exact definition in the new version of the W3C Process Document (Implementation experience).
https://www.w3.org/2018/Process-20180201/#implementation-experience<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2018%2FProcess-20180201%2F%23implementation-experience&data=02%7C01%7CLAUDRAIN%40hachette-livre.fr%7C103cf0e99955432e060b08d63ea2df5a%7Cf881a2c50a89483181b1c7846c49594d%7C1%7C0%7C636765266586015257&sdata=c6z7RqI5tA9MUmz8OErFy434tBtg88e3MqbmsrltZPc%3D&reserved=0>


Indeed, the process document is written in a way to give the Director flexibility.  We want to make sure that there is sufficient implementation experience - but each situation is different - so instead of having strict requirements, we list considerations that the Working Group and Director should think about.

The second consideration of Section 6.2.4 (which is neither necessary nor sufficient by itself), is the question whether there are independent interoperable implementations.  Generally, the Director is looking for positive answers to these questions!  If the answer to this consideration is - Yes - then the yields the oft-quoted two interoperable implementations.  If the answer is - No - a specification could still advance, but has a higher hill to climb.





Cordialement,

Laurent Le Meur
EDRLab





Le 29 oct. 2018 à 17:49, Ric Wright <rkwright@geofx.com<mailto:rkwright@geofx.com>> a écrit :

Sorry, my experience is that the booksellers will fight side-loading tooth and nail.  Your third paragraph is exactly what we tried to achieve at Adobe and it was, for all intents and purposes, a failure. The booksellers did not want it.  Perhaps it will be different this time around, but I am skeptical.

Ric


From: Laurent Le Meur <laurent.lemeur@edrlab.org<mailto:laurent.lemeur@edrlab.org>>
Date: Monday, October 29, 2018 at 9:37 AM
To: Brian O'Leary <brian@bisg.org<mailto:brian@bisg.org>>, W3C Publishing Business Group <public-publishingbg@w3.org<mailto:public-publishingbg@w3.org>>
Cc: "Johnson, Rick" <Rick.Johnson@vitalsource.com<mailto:Rick.Johnson@vitalsource.com>>, Ric Wright <rkwright@geofx.com<mailto:rkwright@geofx.com>>, Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Subject: Re: [External] My opinions about the future of EPUB 3.2
Resent-From: <public-publishingbg@w3.org<mailto:public-publishingbg@w3.org>>
Resent-Date: Mon, 29 Oct 2018 16:38:04 +0000

All reading systems independent from booksellers provide side-loading and therefore promote interoperability within the marketplace. Look at Bluefire reader, Lis-a reader, Bookari, Aldiko, FolioReader, FBReader, Bookeen, TEA or Tolino e-readers etc.

And some reading systems published by booksellers are also open to this (LEA Reader from Adilibre/Albin Michel comes to my head but they are certainly many others).

For a customer, being able to select one favorite app for its whole personal library is a great feature; and for booksellers, making so that customers choose their app (with a direct access to their catalog) should be a goal.

Cordialement,

Laurent Le Meur
EDRLab





Le 29 oct. 2018 à 17:11, Brian O'Leary <brian@bisg.org<mailto:brian@bisg.org>> a écrit :

If interoperability within the marketplace is never going to happen, I guess we can close up shop now.

On Mon, Oct 29, 2018 at 12:07 PM Johnson, Rick <Rick.Johnson@vitalsource.com<mailto:Rick.Johnson@vitalsource.com>> wrote:
On this point, it would be helpful to understand the definition (and example use cases) for interoperability here.  There are two very different possibilities in my mind (and probably more!):

  1.  Interoperability before reaching the marketplace: A content creator can deliver a file to any reading system for their ingestion, and ‘interoperability’ will allow them to create just one file for distribution.
  2.  Interoperability within the marketplace: A reading system can open content being distributed in the marketplace from another reading system.

The first is a logical goal.  The second is never going to happen!

Are there other options?

-Rick

From: Ric Wright <rkwright@geofx.com<mailto:rkwright@geofx.com>>
Date: Monday, October 29, 2018 at 8:57 AM
To: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>, Laurent Le Meur <laurent.lemeur@edrlab.org<mailto:laurent.lemeur@edrlab.org>>
Cc: W3C Publishing Business Group <public-publishingbg@w3.org<mailto:public-publishingbg@w3.org>>
Subject: [External] Re: My opinions about the future of EPUB 3.2
Resent-From: <public-publishingbg@w3.org<mailto:public-publishingbg@w3.org>>
Resent-Date: Monday, October 29, 2018 at 8:56 AM

These are all good points, but I guess I wonder what is driving the desire for interoperability?  Or perhaps more accurately, IS there any desire for interoperability?  As some of you are aware, I led the effort at Adobe with ADE, ACS4 and RMSDK.  One of the huge takeaways was that the customers for RMSDK and ACS positively didn’t WANT interoperability.  They all wanted to be in separate silos.  We had to fight hard to make them support side-loading, for example.

This is a slightly different aspect of “interoperability” since Adobe ensured that the underlying reading system (RMSDK/ACS) was fully interoperable.  But even then the vendors all wanted to create walls around their silo.

My point is that achieving interoperability will require some impetus for reading systems and publishers to ensure their solutions are interoperable.   What is that impetus?  Why will reading systems and publishers spend non-trivial time, money and opportunity to achieve interoperability?  If we can’t answer that then it seems like we are dead in the water.

Ric

From: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Date: Sunday, October 28, 2018 at 10:45 PM
To: Laurent Le Meur <laurent.lemeur@edrlab.org<mailto:laurent.lemeur@edrlab.org>>
Cc: W3C Publishing Business Group <public-publishingbg@w3.org<mailto:public-publishingbg@w3.org>>
Subject: Re: My opinions about the future of EPUB 3.2
Resent-From: <public-publishingbg@w3.org<mailto:public-publishingbg@w3.org>>
Resent-Date: Mon, 29 Oct 2018 05:45:39 +0000

Laurent,

I do not disagree with your analysis. Yes, the interoperability issue is the main challenge, regardless of where it is handled.

However, if the decision is that, at some point, the existence of a W3C Rec is required, there is no problem doing things in parallel, namely

1. the CG can work right now in defining the interoperability requirements, creating tests, etc
2. we (as a collective 'we' at this point) can start hammering out the details of what a Rec track work would mean, write a charter that provides the necessary and good arguments on why EPUB 3.2 should be a Rec track, how that would modify the direction of the current WG, etc. And, of course, the new charter should be accepted by the W3M management and the AC, which rarely goes without further discussion to find the right consensus.

Step (2) will require lots of time and energy. *If* we agree on the goal, there is no reason to wait for (1) to complete. Whatever the CG does in (1) can be input to a new WG for further work right away.

cheers

Ivan

P.S. Let me also add one more thing to your 2/ below. A Rec version of EPUB3.2 is not _only_ of interest in view of ISO. I think the Patent Policy protection attached to a Rec may be significant in future for implementors, as well as the guarantee to provide a public access to the specifications once and for all (which may be a hurdle for an ISO document).



On 24 Oct 2018, at 11:22, Laurent Le Meur <laurent.lemeur@edrlab.org<mailto:laurent.lemeur@edrlab.org>> wrote:

Hi,

To use the new WG motto: what is the problem we're trying to solve?

I see two problems to solve here:
1/ raise the level of interoperability of EPUB 3 reading systems
2/ get EPUB 3.2 standardized by ISO, in order to get Asian adhesion to this version of the standard.

Getting EPUB 3.2 standardized by the W3C is therefore not a solution to the problems; the fact is that resolving the first problem is required to get EPUB 3.2 as a rec, and getting EPUB 3.2 as a rec is a possible step in the resolution of the second one.

Therefore I propose to first tackle the first problem, theinteroperability issue.

For this purpose we need IMO to
a/ define what interoperability really means in our case; this is not so obvious, as there is a large diversity of reading systems (especially those based on browser engines, those with custom rendering engines, those with no visual engine (audio or braille UAs); we may have to defines different classes of reading systems and different interoperability levels.
b/ list every feature defined in EPUB 3.2, with their testing requirements. Be careful about what we want to test: do we (still) want to replicate the html/css "can I use"? for custom rendering engines, which implement a subset of CSS (and maybe HTML5), this could be necessary ...
c/ modify the existing (create a new) EPUB test suite, a set of EPUB samples which will help testing each features individually
d/ update the epubtest.org<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fepubtest.org%2F&data=02%7C01%7CLAUDRAIN%40hachette-livre.fr%7C103cf0e99955432e060b08d63ea2df5a%7Cf881a2c50a89483181b1c7846c49594d%7C1%7C0%7C636765266586025266&sdata=KW3%2B6uaiAfn1jLWGCjuxi3EZwtjW03jhuarXkov612Y%3D&reserved=0> service to handle the new test suite.

The Publishing CG seems to me the proper place for this work, as it has released EPUB 3.2 (and therefore is now free), can get help from everybody in the industry (BISG ...), and it does not require rechartering the WG.

It would be of tremendous help for the industry to get it done.

In parallel, we should try to assert the difficulty to get EPUB 3.2 directly prepared for ISO standarization (in men/hours).

Then and only then, after the main reading systems on the market have been tested against the new test suite, we will be able to assert the difficulty to get EPUB 3.2 standardized by the W3C (in men/hours), i.e. if there are two conforming implementations for each feature of the standard. This work can be made by the WG.

With this data, we'll be able to decide if direct ISO standarization is harder or simpler than W3C rec + W3C to ISO standardization.

During this period, the WG will be able to focus on an urgency for the industry: "WP and EPUB for audiobooks", which could even be released in 2019 maybe (because the spec is simpler that "WP and EPUB for any type of ebook"). And we may find the time to start working on "WP and EPUB for comicbooks" also. Without rechartering...

Cordialement,

Laurent Le Meur
EDRLab

Le 24 oct. 2018 à 02:11, MURATA Makoto <eb2m-mrt@asahi-net.or.jp<mailto:eb2m-mrt@asahi-net.or.jp>> a écrit :

Folks,

I read the draft minutes of the joint F2F of the publishing working group
and the publishing business group with interest.  (Ivan, special thanks
to your timely draft minutes! )  Here are my opinions about the future of 3.2.
...



----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2FPeople%2FIvan%2F&data=02%7C01%7CLAUDRAIN%40hachette-livre.fr%7C103cf0e99955432e060b08d63ea2df5a%7Cf881a2c50a89483181b1c7846c49594d%7C1%7C0%7C636765266586035267&sdata=7T7Imj40AXiWxDKdWaSVGcAPgEpYqLpVKIIUNCc77jc%3D&reserved=0>
mobile: +31-641044153
ORCID ID: https://orcid.org/0000-0003-0782-2704<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Forcid.org%2F0000-0003-0782-2704&data=02%7C01%7CLAUDRAIN%40hachette-livre.fr%7C103cf0e99955432e060b08d63ea2df5a%7Cf881a2c50a89483181b1c7846c49594d%7C1%7C0%7C636765266586035267&sdata=NTa67QChjFUYWogs6sDk8HbnlRcm3QYQLpVTk6odhNk%3D&reserved=0>



--
Brian F. O'Leary
Executive Director, Book Industry Study Group
232 Madison Avenue, Suite 1400
New York, NY 10016

(646) 336-7141 office
(973) 985-9880 mobile