W3C home > Mailing lists > Public > public-publ-wg@w3.org > June 2017

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

From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
Date: Tue, 27 Jun 2017 16:49:40 +0900
Message-ID: <CALvn5EAci9c35-O644vV8NZPS=ASbE2JuUimD_4t5=0S7K=4Rg@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
Cc: Bill McCoy <bmccoy@w3.org>, W3C Publishing Working Group <public-publ-wg@w3.org>, W3C Publishing Business Group <public-publishingbg@w3.org>
Ivan,

Are there any W3C members which cannot join the Publishing WG
because of IPR concerns?  If this is the case, can the charter be
revised?

Regards,
Makoto


2017-06-27 16:18 GMT+09:00 Ivan Herman <ivan@w3.org>:

> (-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> 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>:
>
>> 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
>
>
>
> ----
> Ivan Herman, W3C
> Publishing@W3C Technical Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153 <+31%206%2041044153>
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>


-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
Received on Tuesday, 27 June 2017 07:50:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:49:04 UTC