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

Bill:
”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.”

Accessibility metadata is a big piece missing from web. And it is one of the most important piece for publishing, no matter it is WP or PWP or EPUB 4.
May be WCAG can fill the gap. But it does not look that it can happen so quickly.

With regards
Avneesh
From: Bill McCoy 
Sent: Monday, June 26, 2017 21:09
To: public-publ-wg@w3.org 
Cc: 'W3C Digital Publishing IG' ; public-publishingbg@w3.org 
Subject: PROPOSAL: scope of Web Publications spec should be minimized

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)