- From: Jeff Jaffe <jeff@w3.org>
- Date: Thu, 3 Oct 2019 08:32:23 -0400
- To: AUDRAIN LUC <LAUDRAIN@hachette-livre.fr>, Ivan Herman <ivan@w3.org>
- Cc: Dave Cramer <dauwhe@gmail.com>, Garth Conboy <garth@google.com>, W3C Publishing Business Group <public-publishingbg@w3.org>
- Message-ID: <3bdb8b32-a4e4-62cb-a557-7c6aeb5dbb72@w3.org>
On 10/3/2019 3:28 AM, AUDRAIN LUC wrote: > > Hi, > > In PBG Tuesday call, we did speak of the necessity of a roadmap for > the future of EPUB and that this is being worked on in the EPUB3 CG. > It was also identified that any timeline would come after a clear roadmap. > > From the minutes : > > *Dave Cramer:* The CG is discussing its roadmap and how we want it to > evolve > > ----- > > *Avneesh Singh:* I see something missing in the spreadsheet > … how will EPUB change > … also relates to future roadmap > … suppose CG sends us on a roadmap that they think are essential > … but we are not able to move forward on them because they are not yet > mature specifications > … let us proceed and make decisions then > > *Avneesh Singh:* > … let’s work closely with EPUB3 CG and then determine a timeline > > As for the scenarios, I must admit I don’t understand why scenario for > EPUB number 2) is bearing some items that are already being > standardized on the Web Publication base, namely > > * (c) audiobooks, being the result of the PWG, > * (a) sequential art is already incubated by EDRLab and BDCoMa CG on > Web Publication, > * (d) bringing in some early Web Publications content : isn’t the > Web Publication note here for that? > I was merely listing areas which might provide requirements for a follow-on EPUB spec. It is conceivable that some function developed in one fashion ultimately gets swizzled and packaged in a different way. However, I was not taking a position that this was necessarily the case. > * > > At least the consensus from the PBG call is to let the EPUB CG work on > an EPUB Roadmap first. > > Another quote from the minutes : > > *Wendy Reid:* I said this in Fukuoka > … should a WG, not nec publishing, to handle the work of EPUB3 Rec Track > … because I don’t doubt things will change as we get privacy and > horizontal reviews > … what is clear is that EPUB3 does not succeed if it is not backwards > compatible > … any charter written must make backwards compatibility a requirement > … the perk is that we have a decade of incubation and implementation > … not like the problems we had with Web Publications where there were > not problems identified or implemented > … There is space for the CG > … ideas to get incubated and could be > … rigor of the standardization process will be good in the long run > … industry has made it incredibly clear is EPUB is what they want to > work on and what they want to sell > > I personally fully support this as the EPUB3 CG bears the maximum > representation of the publishing industry. > > Luc > > *De : *Ivan Herman <ivan@w3.org> > *Date : *jeudi 3 octobre 2019 à 08:09 > *À : *Jeff Jaffe <jeff@w3.org> > *Cc : *Dave Cramer <dauwhe@gmail.com>, Garth Conboy > <garth@google.com>, W3C Publishing Business Group > <public-publishingbg@w3.org> > *Objet : *Re: EPUB Rec track (Was Re: [minutes] 2019-10-01) > *Renvoyer - De : *<public-publishingbg@w3.org> > *Renvoyer - Date : *jeudi 3 octobre 2019 à 08:09 > > Let me add two more variables to the equation, continuing along the > lines of Jeff's scenario (2). > > I have heard that the current EPUB 3.2 document would need a strong > editorial re-write or even re-structuring, without touching the > technical content. If this is indeed correct, then it may make sense > to publish this re-written EPUB 3.2 as a Rec, that would then be a > starting point to 3.4, 3.5, etc. By doing so, it would be easier to > track changes later. Of course, if this is not the plan, i.e., any > change would start directly with the current document, then this > factor goes away. > > Another point: Jeff said: > > > If we believe that in three years there is enough meaningful content > for an EPUB 3.5, then I would not advocate taking EPUB 3.2 to REC. > > I wonder whether a more incremental model would not be a better > option, i.e., not to wait three years with a big set of changes but, > rather, publish new releases relatively often (say, every 12-18 > months) even with only a few new technical features. Some sort of a > more agile model, not unlike what is happening in the HTML land. > > Ivan > > > > On 3 Oct 2019, at 02:36, Jeff Jaffe <jeff@w3.org > <mailto:jeff@w3.org>> wrote: > > On 10/2/2019 6:10 PM, Dave Cramer wrote: > > On Wed, Oct 2, 2019 at 12:56 PM Garth Conboy <garth@google.com > <mailto:garth@google.com>> wrote: > > And... jumping the gun... > > Given your two scenarios, Jeff, I'd tend to lean toward > #2. :-) > > Jeff, do you think work on #2 should happen in the CG or in a > WG? Or CG first and then WG? > > For those on the thread who forgot what #2 is, let me re-produce > it here: > > 2. Let's assume that we collectively believe that there are > additional meaningful enhancements for EPUB that we expect to > deliver in the next three years. These could be sourced from > several directions: (a) Sequential arts (manga) requirements, (b) > some level of interop with Kindle, (c) bringing in some of the > audiobooks content into the core EPUB spec, (d) bringing in some > early Web Publications content, (e) natural evolution of the core > EPUB 3.0 spec which was already approved 8 years ago. > > If we believe that in three years there is enough meaningful > content for > > an EPUB 3.5, then I would not advocate taking EPUB 3.2 to REC. I > would > > prefer to put our energies into the new function. > > ..... > > to which Garth said - yes let's work on that, and Dave said that > the CG is developing some proposals. > > ..... > > Now comes Dave's question do we do that work in a CG or in a WG. > > W3C's general approach to such questions is that the work should > be incubated in a CG and standardized in a WG. > > When the work is still exploratory (incubation phase) it is too > expensive to put it in a WG. Teams will experiment rapidly with > different approaches; make many changes; and won't want the > overhead of doing that in a WG. > > But CGs lack the rigor of WGs. The work is not as well known, it > will not get the testing; horizontal review; level of patent > protection; and the imprimatur of the membership (AC) and > Director. So when the work reaches a greater maturity level it > should be transitioned to the REC track. > > A roadmap provides an expectation of which new capability will be > ready technically or needed by the marketplace on what schedule. > One (or several) Community Group(s) could "hang out a shingle" and > immediately start working on some subset of the workscope. The > Business Group could use the roadmap and assess when the work > should start transitioning to the REC track. > > I don't know the roadmap so I can't answer the question directly. > If some of the work is already mature/needed we could start a WG > tomorrow. If it all matures in two years we could plan to start a > new WG in two years. More likely, the work matures at different > paces. The BG proposes a charter (some months from now) outlining > the expected roadmap. Depending on how many distinct "traunches" > of function are involved - there could be a single EPUB 3.5 > deliverable proposed, or incremental 3.3, 3.4, etc. deliverables - > there could be different deliverables identified in such a charter. > > HTH > > Dave > > > ---- > Ivan Herman, W3C > Home: http://www.w3.org/People/Ivan/ > <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2FPeople%2FIvan%2F&data=02%7C01%7Claudrain%40hachette-livre.fr%7Ce26ef7fe030649cf5c8408d747c84da4%7Cf881a2c50a89483181b1c7846c49594d%7C0%7C0%7C637056797938195943&sdata=4wilVsldMdOS4GVeiSXlWAu65OtsTRz2pMRFmaEAoiU%3D&reserved=0> > mobile: +31-641044153 > ORCID ID: https://orcid.org/0000-0003-0782-2704 > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Forcid.org%2F0000-0003-0782-2704&data=02%7C01%7Claudrain%40hachette-livre.fr%7Ce26ef7fe030649cf5c8408d747c84da4%7Cf881a2c50a89483181b1c7846c49594d%7C0%7C0%7C637056797938195943&sdata=XKElNIDUe%2FSIyfXGepkRkxRumwyfBqIba2R%2Bgh5bZao%3D&reserved=0> >
Received on Thursday, 3 October 2019 12:32:28 UTC