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 !
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

This archive was generated by hypermail 2.3.1 : Friday, 27 April 2018 14:06:50 UTC