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: 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>
Message-ID: <D7090229.E09E4%laudrain@hachette-livre.fr>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 April 2018 14:39:08 UTC