W3C home > Mailing lists > Public > public-digipub-ig@w3.org > June 2017

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

From: Bill McCoy <whmccoy@gmail.com>
Date: Mon, 26 Jun 2017 14:48:33 -0700
Message-ID: <CAJ0DDbDZPtTPEL-ibu9SE-NEUnBrnG-tmuna9PGVw+Wvs7UZyA@mail.gmail.com>
To: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
Cc: Bill McCoy <bmccoy@w3.org>, public-publ-wg@w3.org, W3C Digital Publishing IG <public-digipub-ig@w3.org>, W3C Publishing Business Group <public-publishingbg@w3.org>
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

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.


On Mon, Jun 26, 2017 at 2:39 PM, MURATA Makoto <eb2m-mrt@asahi-net.or.jp>

> -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
Received on Monday, 26 June 2017 21:49:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:41 UTC