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)