- From: AUDRAIN LUC <LAUDRAIN@hachette-livre.fr>
- Date: Fri, 27 Apr 2018 14:38:41 +0000
- To: Bill McCoy <bmccoy@w3.org>, 'Dave Cramer' <dauwhe@gmail.com>
- CC: 'W3C Publishing Steering Committee' <public-publishing-sc@w3.org>
Good ! I assume and will do that the PBG [EPUB ROAMAP] TF will have at some point a "72h call for consensus" to all members of PBG ` Luc Le 27/04/2018 16:34, Ğ Bill McCoy ğ <bmccoy@w3.org> a écrit : >Thanks Dave for clarifying. +1 to the plan to use IDPF designations. And I >don't actually think this "contradicts" the general CG process document >per >se - referring to the output generally as a Report and using that >template, >while still terming it, depending on stage, a "Proposed Specification" or >whatever seems fine and it's totally consistent with how the JSON LD-1.1 >"Report" also refers to itself as a "Recommendation". > >It's a fine point but the IDPF process had a gate of Board approval to get >to Proposed Specification status, i.e. the IDPF EPUB WG couldn't >unilaterally declare that. Similarly perhaps we should ask the BG to >formally OK that milestone when the CG feels it's timely (this SC was >originally a proxy for IDPF Board but now that we've recast it as a >coordination group it would seem more appropriate to leave that decision >in >the hands of the BG as a whole). > >--Bill > >-----Original Message----- >From: AUDRAIN LUC <LAUDRAIN@hachette-livre.fr> >Sent: Friday, April 27, 2018 7:06 AM >To: Dave Cramer <dauwhe@gmail.com>; Bill McCoy <bmccoy@w3.org> >Cc: W3C Publishing Steering Committee <public-publishing-sc@w3.org> >Subject: Re: agenda topic for June 4 call: formality of EPUB 3.2 approval >steps > >Hi Dave, >Nice take ! >Luc > > >Le 27/04/2018 13:38, Ğ Dave Cramer ğ <dauwhe@gmail.com> a écrit : > >>Sorry for top posting, but it seems appropriate. What I was trying to >>express the other day is that the W3C rec-track Process (with a capital >>"P") does not apply to community group work. When questions of process >>arise, one must look at the CG charter[1]. We find: >> >>> For consistency with EPUB 3 development to date, and to make it clear >>>that EPUB 3 work in this CG is not Recommendation-track work according >>>to the full W3C Process, the expectation is that historical IDPF >>>designations for specification maturity shall be utilized (³Public >>>Draft², ³Proposed Specification², ³Recommended Specification², and >>>³Informational Document²). >> >>This does contradict the general community group process document [2], >>where specifications produced by CGs are known as "Community Group >>Reports." And it gives no details on what each of those terms mean. >> >>I'd propose that when the community group decides that EPUB 3.2 is >>essentially complete and ready for wide review, we can have a "proposed >>specification" phase, where we solicit feedback from everyone we can. >>After incorporating this feedback, we can propose a final version of >>our report, ask for the blessing of the business group, and collect >>Final Specification Agreement [3] committments from CG members. >> >> >>[1] https://www.w3.org/2017/02/EPUB3CGcharter >>[2] https://www.w3.org/community/about/agreements/ >>[3] https://www.w3.org/community/about/agreements/final/ >> >>Thanks, >> >>Dave >> >>On Thu, Apr 26, 2018 at 10:26 AM, Bill McCoy <bmccoy@w3.org> wrote: >>> Hi, >>> >>> >>> >>> Dave Cramer in last BG call said that he thought we should not have >>>any particular formality around the interim approval steps for EPUB >>>3.2 (such as IDPFıs Proposed Specification) to avoid folks getting >>>confused between W3C CG work product and WG work product. >>> >>> >>> >>> I would like to revisit this and ask the SC to agree where the >>>responsibility should be for deciding this and related questions about >>>the formality of EPUB 3.2, so I would request we add this to our >>>agenda for June >>> 4 (unless itıs clear from email that there is an obvious consensus >>>and no discussion is needed). >>> >>> >>> >>> To me, this question belongs primarily to the BG not the CG since the >>>BG has the responsibility to address business-level ecosystem needs >>>as well as oversight and approval responsibility for the work product >>>of the CG. Of course the BG shouldnıt be allowed to burden the CG >>>excessively but it seems to me the BG should have the main voice in >>>deciding how we need to promote and market EPUB. And approval of >>>specifications is a key part of that promotion and marketing. Dave >>>you may in fact have intended to provide a BG perspective >>>representing Hachette Book Group, since it was during the BG meeting, >>>but this wasnıt clear (at least to me) given your co-chair-ship of >>>the CG. But since it wasnıt an explicit agenda topic I didnıt want to >>>chime in on it in our limited time. >>> >>> >>> >>> If we agree that this is a BG decision then I would propose to add a >>>topic for approval steps for EPUB 3.2 for the next BG call and >>>perhaps have some email about that en route. >>> >>> >>> >>> Because, I believe Daveıs plan to avoid any formality is contrary to >>>the business needs for a stable and reliable EPUB specification, both >>>in general and based on the current need to crisply move past the >>>EPUB 3.1 snafu. I agree with Dave and others that EPUB 3.2 is >>>inherently not that important in the sense that what we need to be >>>promoting is EPUB 3, but the fact that the latest extant version of >>>EPUB 3 is problematic and that the organization that developed it no >>>longer exists or supports it is a weak point. That work has started >>>on what may be an EPUB 4 further confuses things. Iım told there were >>>people at last Frankfurt saying ³EPUB 3 is dead² and thatıs troubling. >>> So I think itıs critical that EPUB 3.2 be seen as a real thing not an >>>ad hoc product of an ad hoc group. And the arrangement between IDPF >>>and W3C was explicitly designed to facilitate this. The BG oversight >>>and approval of the CG work on EPUB 3 revisions was intended to >>>function in a directly analogous manner to the AC approval of W3C >>>specifications produced by WGs, and the membership approval of IDPF >>>specifications. Both approval processes include approval of interim >>>versions not just a blessing of the final work product. >>> So I think that we should do likewise and have at least one interim >>>approval gate by the BG en route to finalizing EPUB 3.2, and do some >>>PR around the hopefully positive result. >>> >>> >>> >>> Yes we should avoid confusion about the CG work product being the >>>same as a W3C Recommendation but this seems like a minor concern >>>especially since we will be using the CG document template a la [1], >>>something weıve already agreed on and that I donıt propose to >>>revisit. >>> >>> >>> >>> Daveıs overall approach seems to be based on an argument that since >>>CGıs donıt have any particular process requirements that therefore we >>>should not impose any. But this is both contrary to the IDPF-W3C >>>understanding as well as a logical fallacy. That some (maybe most) >>>CGs are very ad hoc about their processes doesnıt imply that we must >>>be also. That there are no particular process requirements for CGs >>>doesnıt imply that we canıt have any, it only means that we are free >>>to do whatever makes sense to meet the overall goals. >>> >>> >>> >>> And while Iım not suggesting that we invent a new report template I do >>>think >>> we can and should get creative in maximizing EPUB 3.2 being seen as a >>>³real >>> specification² equally if not more vetted and valid than anything >>>previously >>> produced by IDPF. If we donıt do this, we risk further muddying the >>>waters >>> which again with 3.1 being problematic would be extra bad. And as Iıve >>>said, >>> we need to show that EPUB 3 is alive and well and being well maintained >>> within W3C. >>> >>> >>> >>> If we quickly do an ISO standard based on 3.2 and/or a W3C >>>Recommendation a >>> la JSON-LD, then that will of course help. But in either of these paths >>>we >>> will not want to create forking. We donıt want a 3.2 from the CG that >>>is >>> merely viewed as fodder for an ISO standard or W3C Recommendation, we >>>would >>> want these outputs to be completely compatible. So that still argues >>>for >>> focus on EPUB 3.2 being dependable, not the result of an ad hoc >>>process. So >>> to me the more ³window dressing² we can put around this to maximize the >>> perception of dependability, the better. Of course I donıt propose that >>>we >>> overly burden the CG, but I donıt think that for example bringing at >>>least >>> one interim draft to the BG for approval would do so (and again doing >>>so is >>> arguably an implication of having the approval responsibility per the >>> IDPF-W3C deal as embodied in the respective charters). >>> >>> >>> Re: naming, I donıt necessarily have a great answer but I also think >>>this >>> deserves more discussion. We are in agreement to use the CG Report >>>template >>> which makes it very clear in the preface that the results are not a W3C >>> Recommendation but JSON LD 1.1 [1] very clearly calls itself a >>> ³Recommendation²: ³This document is one of three JSON-LD 1.1 >>>Recommendations >>> produced by the JSON for Linking Data W3C Community Group:² >>> >>> So I think itıs fair game for us to do likewise, adopt IDPF naming, or >>> whatever the BG thinks will best serve the goal. So if we called the >>>final >>> result a ³Recommendation², then we could call the interim milestone >>> something accordingly. We should perhaps investigate what JSON-LD 1.1 >>>did. >>> >>> >>> >>> Again while I have a personal perspective here on whatıs best for the >>> ecosystem and W3C, my main goal in sending this email is to clarify >>>whether >>> this group feels that this should be a BG decision and if so to get it >>>in >>> the stream to be an explicit agenda topic there which I think deserves >>>a bit >>> more than just Dave saying in passing what he wants to do as CG >>>co-chair. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> --Bill >>> >>> >>> >>> >>> >>> [1] https://json-ld.org/spec/ED/json-ld/20180215/ >>> >>> >>> >>> >>> >>> >> > > >
Received on Friday, 27 April 2018 14:39:07 UTC