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

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>
Date:  Monday, October 29, 2018 at 9:37 AM
To:  Brian O'Leary <brian@bisg.org>, W3C Publishing Business Group
<public-publishingbg@w3.org>
Cc:  "Johnson, Rick" <Rick.Johnson@vitalsource.com>, Ric Wright
<rkwright@geofx.com>, Ivan Herman <ivan@w3.org>
Subject:  Re: [External] My opinions about the future of EPUB 3.2
Resent-From:  <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> 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>
> 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>
>> Date: Monday, October 29, 2018 at 8:57 AM
>> To: Ivan Herman <ivan@w3.org>, Laurent Le Meur <laurent.lemeur@edrlab.org>
>> Cc: W3C Publishing Business Group <public-publishingbg@w3.org>
>> Subject: [External] Re: My opinions about the future of EPUB 3.2
>> Resent-From: <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>
>> Date: Sunday, October 28, 2018 at 10:45 PM
>> To: Laurent Le Meur <laurent.lemeur@edrlab.org>
>> Cc: W3C Publishing Business Group <public-publishingbg@w3.org>
>> Subject: Re: My opinions about the future of EPUB 3.2
>> Resent-From: <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> 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, the interoperability
>>> 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 <http://epubtest.org/>  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> 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/
>> mobile: +31-641044153
>> 
>> ORCID ID: https://orcid.org/0000-0003-0782-2704
>>  
> 
> 
> -- 
> 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