- From: George Kerscher <kerscher@montana.com>
- Date: Thu, 20 Apr 2017 08:41:00 -0600
- To: "'Ivan Herman'" <ivan@w3.org>, "'Daniel Glazman'" <daniel.glazman@disruptive-innovations.com>
- Cc: "'Bill McCoy'" <bmccoy@w3.org>, "'Garth Conboy'" <garth@google.com>, "'W3C Publishing Business Group'" <public-publishingbg@w3.org>, "'W3C Digital Publishing IG'" <public-digipub-ig@w3.org>
Dear All, Ivan wrote: "Obviously, whatever we do under the heading of WP must and will flow into what EPUB4 will be, ie, separating it as a different concept from EPUB4 can just be considered as a modularization of concerns and documents. EPUB4, in this respect, would be "just" an appropriately packaged WP with, possibly, more stringent requirements on, say, accessibility (and maybe other things)." George clarifies: First, I would expect WP to be first in class in accessibility. Secondly, a packaged form derived from the WP would get the accessibility from the WP; it is impossible to automatically generate a packaged form and add accessibility, if it were not there in the first place. Best George -----Original Message----- From: Ivan Herman [mailto:ivan@w3.org] Sent: Thursday, April 20, 2017 4:15 AM To: Daniel Glazman <daniel.glazman@disruptive-innovations.com> Cc: Bill McCoy <bmccoy@w3.org>; Garth Conboy <garth@google.com>; W3C Publishing Business Group <public-publishingbg@w3.org>; W3C Digital Publishing IG <public-digipub-ig@w3.org> Subject: Re: Comment on "Call for Review: Publishing Working Group Charter" Daniel, (This is also a reply to some other comments that came in later; a night has passed since this mail:-) To avoid any misunderstandings: these comments are mine and do not represent, at this point, the W3C staff, let alone the W3C Director. > On 19 Apr 2017, at 17:10, Daniel Glazman <daniel.glazman@disruptive-innovations.com> wrote: > > Le 19/04/2017 à 16:21, Bill McCoy a écrit : > >> +1 to the renaming of the IG documents. >> >> It’s a nit but I would recommend naming that captures a bit more >> actively the spirit of the documents, since terms like “reflections”, >> “contemplating”, “deliberations” (not to mention “ruminations”) are >> pretty passive and really don’t connote anything. E.g. I could suggest: >> “Envisioning Web Publications”, or “Motivation and Requirements for Web >> Publications”, or “Vision and Background for Web Publications” or >> something along those lines that would give someone reading the title a >> bit more of a clue as to the content. > > I would call them "/dev/null". > > As I said in my charter review, I'm not even sure we need these > documents on the REC track in the WG and I'm not even sure 2.5 years > for 4 deliverables currently listed in the Charter is realistic. > > I could probably, with big efforts, understand why we have Web > Publications there, because we have this model [1] where we design > generic Web Publications and functionnally derive EPUB from there. Why > we have Package Web Publications - while the W3C has another place > working on Packaging on the Web - is a mystery to me. We should just > adopt what they do and liaise with them or we will end up with a one > liner spec: "a PWP is a WP packaged according to the Packaging-on-the- > Web spec". I also note that since Packaging of Web resources is > chartered by one WG already, we can't charter it in the Publishing WG > if we deal with Web resources ourselves, which we clearly do. I would prefer, for a moment, to separate the WP and the PWP part in this discussion. 1. Let us look at the issue of WP. First of all, although I believe your reference to the IDPF meme was more meant as a sarcasm, it is actually serious. Yes, WP is not only meant for electronic books; it is also meant for other type of publications that should be first class entities on the Web. (And not necessarily packaged!) My personal favourite, due to my own past, is the world of scholarly publishing that has, so far, ignored any development in EPUB, but where there is a major change happening towards real Web based publishing. The WP Use Case and Requirements document lists a number of issues that, in my view, justify looking at WP in general. In many respect, that work is the same, in terms of the goals, as the browser-friendly manifestation work that occurred in the now defunct IDPF EPUB 3.1 Working Group (whose results would also flow into the work). Obviously, whatever we do under the heading of WP must and will flow into what EPUB4 will be, ie, separating it as a different concept from EPUB4 can just be considered as a modularization of concerns and documents. EPUB4, in this respect, would be "just" an appropriately packaged WP with, possibly, more stringent requirements on, say, accessibility (and maybe other things). Although it has been discussed elsewhere on these (and other) mailing lists, we indeed have to make it clearer that the DPUB IG's WP document is _not_ some form of an early FPWD for the Rec track work, and was never meant to be. I also believe we have some sort of a consensus now that this should be made clear (beyond what the charter already says when characterizing the input document) by publishing those documents as IG Notes asap, with a different title to make the separation clear. If you (or anybody else in the list) have proposals on how to reinforce this intention and the role of those documents in the charter text beyond these steps, please tell us. Anything that helps to dissipate the sources of possible confusions help. 2. PWP. You know what? If PWP is not necessary in terms of a separate Rec, I would be the first to be happy. *If* the generic work in the Web Platform WG produces a Web Packaging format that fully suits the needs of publishing, then I am happy not to do anythings. But… can you be sure at this point? That work has been dragging on for many years and has just been reinvigorated a few months ago. Even if (which I sincerely hope) that work leads to a closure as a Rec, we cannot be sure either that it will also work *as defined* for publishing; it may be mostly focusing (just as web manifests do) on Web Applications, and we may have to *extend* it (e.g. by adding some more metadata or specific requirements) to suit publishing. Of course, we will have to work with the WPWG to avoid these discrepancies (and we do have a liaison in the charter for that reason) but, at this point, my feeling is that we just do not know. So… we should regard the PWP spec as a placeholder in the charter; we will do a separate Rec on that one if, and only if, it is indeed necessary depending on the technologies available on OWP. I would personally be happy to to add this remark/comment into the charter attached to that entry in the list of deliverables if that helps clarifying the role of that deliverable. B.t.w., the charter does refer to the packaging work (as part of the liaison with the WPWG) and it also makes it clear (I hope) that we do _not_ do any work that is done elsewhere: "It will be the task of the Working Group to identify those requirements that are not yet fully covered by the current environments based on the Open Web Platform, and would therefore need further work, while re-using existing technologies developed by other Working Groups as much as possible and practical." (first paragraph of the 'goals' section). > > In my opinion, the Deliverables section should be (EPUB4 prose > rewritten by yours truly): > > EPUB 4 > This specification defines the next version of EPUB, a distribution > and interchange format for digital publications and documents. It > should generally be a functional superset of EPUB 3.1. Functional > round-tripping to/from EPUB 3.1 considered highly desirable. > > DPUB-ARIA Module 2.0 > This specification extends the DPUB-ARIA Module 1.0 specification, > adding terms for a more complete coverage of publication-related > terms. Its primary input is the full set of terms defined by the > EPUB 3 Structural Semantics Vocabulary but other, similar > vocabularies will also be considered. > > Period. IG's WP and PWP remain fine as Input Documents (and I note > Ivan agrees they should be Notes). See above. It was never meant in any other way... > > And that's an already agressive and ambitious plan for 2.5 > years only. I'm not sure the weight of the needed Test Suites and > the work to collect Implementation Reports is correctly estimated > by everyone here. Without them, no REC. I am perfectly aware that it will be a tall order. We will have to organize the Working Group _from the first day_ in such a way that test suites and testing in general would be defined along the way. Your experience with the CSS WG would be invaluable in this respect, actually, and I hope you will give us a helping hand. At the moment, the charter is set to 2 1/2 years. If Disruptive Innovations officially requests to extend it to, say, 3 years, W3M may just accept it. That would require to change the milestones; at the moment, the CR phase is set to be a year, we can then have a year and half. *Personally* I would have no objection on this at all. I hope these help... Cheers Ivan > > [1] https://is.gd/qkd6Lh > > </Daniel> > ---- Ivan Herman, W3C Publishing@W3C Technical Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704
Received on Thursday, 20 April 2017 14:45:22 UTC