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

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

From: Bill McCoy <bmccoy@w3.org>
Date: Thu, 26 Apr 2018 07:26:15 -0700
To: "'W3C Publishing Steering Committee'" <public-publishing-sc@w3.org>
Message-ID: <0fb801d3dd6a$963e6620$c2bb3260$@w3.org>
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  <https://www.w3.org/community/json-ld/> 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 Thursday, 26 April 2018 14:26:43 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 26 April 2018 14:26:44 UTC