Re: Proposal for charter changes, in view of the formal objections by Vivliostyle & Disruptive Innovation

Hi Daniel,

Thanks for the comments. Before editing the draft further, some questions/clarifications below…


> On 24 Apr 2017, at 11:52, Daniel Glazman <daniel.glazman@disruptive-innovations.com> wrote:
> 
> Le 21/04/2017 à 11:53, Ivan Herman a écrit :
> 
>> Daniel, Florian, everyone
>> I would hope that these changes form a good basis to resolve the issues around the formal objections, and are acceptable to everyone.
> 
> Thank you Ivan. My review of the proposed changes:
> 
> 1. the Input Documents' list still misses html and CSS! I strongly
>   suggest comparing the list and the Normative and Informative
>   References of EPUB 3.1. The potential allowance of non-XML html
>   alone (with its namespace issues) makes the html spec a major input
>   document.
> 
> 2. I still wish Input Documents were divided into Normative documents
>   (RECs or non-W3C Standard documents) and non-normative ones, thanks.

In some sense, these two bullet points belong together, so this is a question on both.

While I am not opposed to add CSS & HTML, I would try to understand the logic of it as well as your second point. In my mind, the list of input document are those that may directly influence the final shape of the Recs published by this WG. To take an example, Web App Manifest may become the basis of the manifest work that this WG may decide to write (eg, a manifest for WP may become an extension of the Web App Manifest). However, the Web _content_ specs, ie, HTML, SVG, CSS, are _used_ by a WP but there is no goal of, say, extending those specifications, at least not in this WG (there may be requested extensions but those should be raised in the, eg, CSS WG). In this sense I believe there is a fundamental difference in listing HTML & co. as input documents, and I would like to understand your thinking.

(I take your point that WP would probably rely on HTML5 as opposed to XHTML5. But that does not necessarily change any deliverables for a Web Publication insofar as the starting position is to accept whatever is done on the Web at large, without any unnecessary restrictions…)

As for the specific request in section 2: again, I am not sure I understand what you mean. It so happens that none of the document are, _at this moment_, published standards. Or do you mean which of these documents will _become_ normative references and which will not in a final Publishing Rec? Well… I am not sure we know, and hardcoding this in a charter seems to restrict the flexibility of the Working Group.

> 
> 3. the ETAs for Deliverables seem more "plausible". And as Bill told me,
>   the goal is to have "plausible" ETAs in the Charter, even if they're
>   eventually not met for various reasons. This WG will have a
>   Membership that's not used to our Test Suites, our harness
>   environments and tools. The Test Suites for EPUB 4 alone will be a
>   *huge* effort. The Implementation Reports too.

I understand all this, and this is something the WG management will have to take into account from the start. However, as you very well know, even setting the charter for 3 years is (and will be) a push by W3M. I do not think it would be acceptable to make it longer; I would prefer to keep it that way for now (hoping that W3M _will_ accept a three year charter).

> 
> 4. the change about BG/WG relationship is fine by me, thank you.
> 
> 5. I still don't think it's a good strategy to keep the possibility
>   of having our own Packaging spec; IMHO, a better one would be to
>   make the WG, as first-class user, contribute directly to
>   Packaging-on-the-Web in a joint effort. Willing to compromise on
>   the proposed change, though.

The problem is: at this moment there is a _very_ high level of uncertainty as for the fate of the Packaging spec in the WP WG. The official spec[1], as well as the github repo[2], has not changed for two years. The only activity that we know of is happening on a private repository [3] which looks, at first hand, more of an open discussion list and not a new document (some members of the IG have been following that discussion). Ie, it is very very uncertain at this point what will (or will not) happen. AFAIK, none of the browser manufacturers have committed to this deliverable, although [3] shows that there is at least some interest at Google. Even if it happens, it may be a very stripped down version which may require some additional quirks to make it usable for more than just Web Applications. Honestly: nobody knows. That is why I believe such a placeholder _is_ necessary even if, I agree, the final document (if necessary) may be a 1-2 page spec altogether.

At this moment issues to the packaging spec are at the following places in the charter:

- listed as an input document
- explicitly listed as a topic in the liaison with the WPWG as a subject of work
- the entry in the deliverables

To be very honest with you, also in view of the current uncertainties with the packaging spec, I have difficulties to see what else we can do in terms of this in the charter; we cannot, I believe, commit ourselves to a work whose very fate is still in question (and has been for several years). Do you have any specific proposals as an alternative?


[1] http://w3ctag.github.io/packaging-on-the-web/
[2] https://github.com/w3ctag/packaging-on-the-web
[3] https://github.com/dimich-g/webpackage


> 
> 6. I'm still not sure about the second half of last paragraph of the
>   Scope section. As I said in my AC review, it seems to me far too
>   binding for something that should be decided by the WG's Membership.
>   EPUB is at crossroads, and deep technical changes having no
>   functional impact, for simpler and better implementations, are
>   feasible. I certainly do NOT want to shut that door.
> 

Can we try to be a bit more specific? I presume you were looking at the text

"it is also critical that a next generation of EPUB, currently referred to as EPUB 4, retain the specificity, portability, predictability, accessibility, and internationalization required by the publishing ecosystem while benefitting from the improved features and functionalities offered by Packaged Web Publications. EPUB 4 must not be in conflict with Web Publications; it must be a type of Web Publication that provides the predictability and interoperability that this ecosystem has come to rely on."

Which aspects do you think are shutting a door to? It would greatly help me to understand if you could give me a specific problem you feel may lead to issues.

Thanks

Ivan


> Thanks.
> 
> </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