- From: Rachel Comerford <rachel.comerford@macmillan.com>
- Date: Thu, 26 Apr 2018 11:28:56 -0400
- To: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>
- Cc: Bill McCoy <bmccoy@w3.org>, W3C Publishing Steering Committee <public-publishing-sc@w3.org>
- Message-ID: <CAESEvMzwWxQ0k8jgHmKSMfF4BRH26KgOZFv4Cy9AN6rf4mNU0Q@mail.gmail.com>
Tzviya's interpretation reflects my understanding of what we discussed as well... apologies if my minuting was misleading? Rachel Comerford | Senior Director of Content Standards and Accessibility | T 212.576.9433 *Macmillan Learning* On Thu, Apr 26, 2018 at 11:14 AM, Siegman, Tzviya - Hoboken < tsiegman@wiley.com> wrote: > Hi Bill, > > > > I think there may have been a misunderstanding. My take away from the > meeting was that Dave was all for having a formal approval period for EPUB > 3.2 and that the BG should definitely be a part of that approval. I don’t > think anyone is in disagreement about that. There is not a lot of precedent > in the W3C for this sort of structure, so I believe that Dave was saying > that we need to make up the process to some extent. > > I think a good agenda for the SC is to propose a process for BG approval. > I believe that is exactly what Dave was suggesting. Dave, will of course > correct me if I am misunderstanding. > > > > Tzviya > > > > > > > > *Tzviya Siegman* > > Information Standards Lead > > Wiley > > 201-748-6884 > > tsiegman@wiley.com > > > > *From:* Bill McCoy [mailto:bmccoy@w3.org] > *Sent:* Thursday, April 26, 2018 10:26 AM > *To:* 'W3C Publishing Steering Committee' <public-publishing-sc@w3.org> > *Subject:* agenda topic for June 4 call: formality of EPUB 3.2 approval > steps > > > > 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 > <https://www.w3.org/community/json-ld/>:” > > 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 Thursday, 26 April 2018 15:29:44 UTC