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

-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