W3C home > Mailing lists > Public > public-publishing-sc@w3.org > April 2018

RE: agenda topic for June 4 call: formality of EPUB 3.2 approval steps

From: Bill McCoy <bmccoy@w3.org>
Date: Fri, 27 Apr 2018 07:46:27 -0700
To: "'AUDRAIN LUC'" <LAUDRAIN@hachette-livre.fr>, "'Dave Cramer'" <dauwhe@gmail.com>
Cc: "'W3C Publishing Steering Committee'" <public-publishing-sc@w3.org>
Message-ID: <107601d3de36$8b6e2c90$a24a85b0$@w3.org>
Yes I think "72h call for consensus" is totally OK for this, just like
anything else where we want PBG approval. If we don’t' have consensus then
of course we might need to take further steps including potentially a vote
but hopefully that wouldn't be necessary.

But that would then let us announce that e.g. "EPUB 3.2, a work product of
the W3C EPUB Community Group, has been approved by the W3C Publishing
Business Group to be published as a Proposed Specification". I think that
will have some marketing value as an interim milestone.

--Bill

-----Original Message-----
From: AUDRAIN LUC <LAUDRAIN@hachette-livre.fr> 
Sent: Friday, April 27, 2018 7:39 AM
To: Bill McCoy <bmccoy@w3.org>; 'Dave Cramer' <dauwhe@gmail.com>
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

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:46:42 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 April 2018 14:46:43 UTC