Re: PROPOSAL: scope of Web Publications spec should be minimized

(-cc the DPUB IG. The discussion is really in the WG and BG now.)

> On 27 Jun 2017, at 00:05, MURATA Makoto <eb2m-mrt@asahi-net.or.jp <mailto:eb2m-mrt@asahi-net.or.jp>> wrote:
> 
> Bill,
> 
> I am not even sure that "a multi-resource ordered collection of
> related content (aka publication)"  is a piece of the complete
> solution.  I doubt if it is a red herring.
> 
> I do not believe that enough analysis has been made especially from the
> OWP side, since browser vendors have not participated in the
> Publishing WG.
> 

Makoto,

I am not sure what you mean here; the Publishing WG has just started…

Additionally to what Bill said: Some of the browser vendor representatives have actually taken part of the DPUB IG discussions, too. Those discussions (over 100 open issues on Github at some points in time!) have significantly shaped the work of the DPUB IG and, as a consequence, the two input documents to this WG, namely the PWP Use cases as well as the PWP document itself. In other words, I believe you are a bit unfair to the work of the DPUB IG.

As Bill alluded to, some of the browser vendors wait for a more specific, more precisely scoped set of features. The goal of the WG is to provide those via a FPWD based on what we have worked on both in the DPUB IG as well as in the IDPF EPUB 3.1 WG. Let us concentrate on that now, and hopefully that will bring in other parties for a joint discussion.

Ivan


> 
> Regards,
> Makoto
> 
> 2017-06-27 6:48 GMT+09:00 Bill McCoy <whmccoy@gmail.com <mailto:whmccoy@gmail.com>>:
> Makoto, maybe you misunderstood the reasoning behind my proposal.
> 
> I completely agree that " 'a multi-resource ordered
> collection of related content (aka publication)' will not unify the OWP
> and EPUB worlds".
> 
> My proposal is based on the observation that in the decomposition of specs contemplated in our charter the Web Publications (WP) specification should not have the burden to fully unify the OWP and EPUB worlds: this is the job of everything that our new WG has to do, and that much of the unification will necessarily be in the PWP/EPUB4 realm. If we have to solve everything before we do anything we will not get started quickly, if ever, and then we won't get anywhere. So I propose that we do first cut at WP in an agile manner even though we realize in the end it will be only one piece of the complete solution. That will get us started and help keep things clean architecturally.
> 
> And plenty of analysis has already been done both on IDPF side (work that started during but did not end up part of EPUB 3.1) and W3C side (DPUB IG deliverables). So I fear "analysis paralysis" if we stay in that mode.
> 
> --Bill
> 
> 
> 
> On Mon, Jun 26, 2017 at 2:39 PM, MURATA Makoto <eb2m-mrt@asahi-net.or.jp <mailto:eb2m-mrt@asahi-net.or.jp>> wrote:
> -1
> 
> Although I think that the charter has to be revised for inviting
> browser vendors, I do not think that the  "a multi-resource ordered
> collection of related content (aka publication)" unifies the OWP
> and EPUB worlds.  I rather doubt if it is a re-engineering for the
> purpose of re-engineering.  We should rather begin with a thorough
> analysis of the gaps between the OWP and EPUB worlds,
> What does the Microsoft team for EPUB say about the gap?
> 
> Regards,
> Makoto
> 
> 2017-06-27 0:39 GMT+09:00 Bill McCoy <bmccoy@w3.org <mailto:bmccoy@w3.org>>:
> I thought the F2F was very successful but it seemed unclear coming out of it whether we are in consensus on the ideal scope of Web Publications (WP).
> 
> 
> 
> Ivan said several times in the F2F that "this is the Web" but I don't know that it fully sunk in. So I would like to make a modest proposal for a way to help us move forward in a focused manner.
> 
> 
> 
> I believe that the core gap in OWP that WP needs to fill is the lack of any definition of a multi-resource ordered collection of related content (aka publication). As such, I am not sure there is any other strong requirement for a Web Publication spec. The document outline created at the end of F2F to me seems to presume a much "thicker" spec particularly because much of the 2 days of discussion was about use cases for everything the WG needs to handle.
> 
> 
> 
> I propose that a guiding principle be that for WP nothing is needed unless it is explicitly required for the use cases for online Web publications BUT not required for the use cases for Web pages and Web apps. If something is not about online distribution through the Web - content hosted at URL(s) - it should be in PWP/EPUB4 spec(s) not WP spec (“P” in PWP stands for "portable" not "packaged") If something is applicable to Web pages and Web apps as well as Web publication it should be a general Web Platform capability. At least that should be our starting presumption in crafting the initial WP spec draft.
> 
> 
> 
> Thus for WP I am not sure we need anything except a means to define the collection of content (the publication) and a way to hang metadata on that collection, plus probably something about identification of publications. So, for agile development in MVP (minimum viable product) manner, I think we should affirmatively state that this is the assumption and draft accordingly. I.e. have a thin starting outline for WP spec, not a thick one.
> 
> 
> 
> So by way of example there should be no going-in expectation of a need for a security section in the WP spec, as WP is by definition “on the Web” so normal Web security model applies. There should be no going-in expectation of a need to say anything about scripting. Etc.  (we can be in parallel outlining PWP and move things like security and scripting there). I hate to say it, but there should not be a need to say anything about accessibility other than as it applies to the new things being specifically defined in the WP spec.
> 
> 
> 
> Maybe we’ll find that we need to relax this… for example something that we need for publications, both on the Web and distributed via other means, that while theoretically useful for Web apps and simple Web pages is not in the cards to get done by Web Platform WG in our timetable.  Maybe we’ll find that some PWP things have implications for WP-level mechanisms.
> 
> 
> 
> But these things to me should be well-considered exceptions to our general expectations. We shouldn’t start our drafting with an presumption that we are going to be putting things in WP that are logically overall Web Platform mechanisms or putting stuff in WP even though not directly relevant for “on the Web” scenarios because we want to make sure it flows “down” to PWP distribution means.
> 
> 
> 
> To me the only significant issue we need to wrestle with now in crafting a WP spec is whether the means of defining a collection of content is within HTML, as the privileged hypertext format of the Web, and/or an external data structure that is independent of content element format, and/or something implicit (such path elements of URLs) . If we agree on a minimal approach to WP I would hope that the WG can quickly move on to resolving this key issue so we can have a straw-man draft spec ASAP.
> 
> 
> If the WP spec thus becomes almost trivial – that would be something to celebrate! Not because the other things aren’t very important to the overall job of the Publishing WG – they are! But because a clean, modular architecture that doesn’t unnecessarily conflate things that don’t belong together will both help us get a faster start now, and serve us better in the long run.
> 
> 
> 
> --Bill (not writing here with Team or Readium hat on, just as a WG participant)
> 
> 
> 
> 
> --
> 
> Praying for the victims of the Japan Tohoku earthquake
> 
> Makoto
> 
> 
> 
> 
> --
> 
> Praying for the victims of the Japan Tohoku earthquake
> 
> Makoto


----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>