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

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.


Regards,
Makoto

2017-06-27 6:48 GMT+09:00 Bill McCoy <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>
> 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>:
>>
>>> 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