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

Well, at least one browser vendor wants to see at least some FPWD before
committing to participate in this WG. So if we wait to even develop a straw
man, then we risk being stuck in Catch-22.

Anyway OWP != browser vendors and it is not rocket science that we will
need to define something that describes a publication in order to make
publications first class on the Web, and we have at least one existence
proof in Readium 2 work in progress as well as the prior work at IDPF and
W3C DPUB IG. So it seems hard to imagine that more analysis shed much more
light on that point.

But, I am meeting with one of the browser vendors in two hours and will
report back if there is anything I can share.

--Bill

On Mon, Jun 26, 2017 at 3:05 PM, MURATA Makoto <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.
>
>
> 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
>