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

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 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