- From: Jeff Jaffe <jeff@w3.org>
- Date: Tue, 30 Oct 2018 11:19:52 -0400
- To: "Johnson, Rick" <Rick.Johnson@vitalsource.com>
- Cc: Brian O'Leary <brian@bisg.org>, W3C Publishing Business Group <public-publishingbg@w3.org>, Ivan Herman <ivan@w3.org>, Laurent Le Meur <laurent.lemeur@edrlab.org>, Ric Wright <rkwright@geofx.com>
- Message-ID: <851b4fa2-356e-d96c-90ac-09486d61dc86@w3.org>
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> > *Date: *Monday, October 29, 2018 at 11:15 AM > *To: *Laurent Le Meur <laurent.lemeur@edrlab.org>, Ric Wright > <rkwright@geofx.com> > *Cc: *Brian O'Leary <brian@bisg.org>, W3C Publishing Business Group > <public-publishingbg@w3.org>, "Johnson, Rick" > <Rick.Johnson@vitalsource.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: *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 > > > 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, 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 > <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/ > 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 > > >
Received on Tuesday, 30 October 2018 15:20:06 UTC