- From: AUDRAIN LUC <LAUDRAIN@hachette-livre.fr>
- Date: Fri, 27 Apr 2018 14:06:22 +0000
- To: Dave Cramer <dauwhe@gmail.com>, Bill McCoy <bmccoy@w3.org>
- CC: W3C Publishing Steering Committee <public-publishing-sc@w3.org>
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:06:49 UTC