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:06:22 +0000
To: Dave Cramer <dauwhe@gmail.com>, Bill McCoy <bmccoy@w3.org>
CC: W3C Publishing Steering Committee <public-publishing-sc@w3.org>
Message-ID: <D708FAC4.E09AF%laudrain@hachette-livre.fr>
Hi Dave,
Nice take !

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/
>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
>> 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
>> formality of EPUB 3.2, so I would request we add this to our agenda for
>> 4 (unless itıs clear from email that there is an obvious consensus and
>> 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
>> to me the BG should have the main voice in deciding how we need to
>> 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
>> in on it in our limited time.
>> If we agree that this is a BG decision then I would propose to add a
>> for approval steps for EPUB 3.2 for the next BG call and perhaps have
>> 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
>> 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
>> has started on what may be an EPUB 4 further confuses things. Iım told
>> were people at last Frankfurt saying ³EPUB 3 is dead² and thatıs
>> 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
>> manner to the AC approval of W3C specifications produced by WGs, and the
>> membership approval of IDPF specifications. Both approval processes
>> approval of interim versions not just a blessing of the final work
>> So I think that we should do likewise and have at least one interim
>> gate by the BG en route to finalizing EPUB 3.2, and do some PR around
>> 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
>> 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
>> impose any. But this is both contrary to the IDPF-W3C understanding as
>> as a logical fallacy. That some (maybe most) CGs are very ad hoc about
>> processes doesnıt imply that we must be also.  That there are no
>> process requirements for CGs doesnıt imply that we canıt have any, it
>> means that we are free to do whatever makes sense to meet the overall
>> And while Iım not suggesting that we invent a new report template I do
>> we can and should get creative in maximizing EPUB 3.2 being seen as a
>> specification² equally if not more vetted and valid than anything
>> produced by IDPF. If we donıt do this, we risk further muddying the
>> which again with 3.1 being problematic would be extra bad. And as Iıve
>> 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
>> 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
>> 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
>> overly burden the CG, but I donıt think that for example bringing at
>> 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
>> deserves more discussion. We are in agreement to use the CG Report
>> 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
>> 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
>> result a ³Recommendation², then we could call the interim milestone
>> something accordingly. We should perhaps investigate what JSON-LD 1.1
>> 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
>> this group feels that this should be a BG decision and if so to get it
>> 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
>> Thanks,
>> --Bill
>> [1] https://json-ld.org/spec/ED/json-ld/20180215/
Received on Friday, 27 April 2018 14:06:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:53:21 UTC