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

Replying to both in one here:

Leonard:

The UCR use case review was an agreed action item from the call but I wanted to point out that since the WG has a broader set of participants than those involved in DPUB IG, including former IDPF members who worked on EPUB but were not previously in W3C, we shouldn't assume that the use cases from the UCR document are comprehensive. I believe it would be appropriate to also solicit additional use cases (without delaying work on the action item).

Daniel :

Obviously there are many examples of publications on the Web. But as your example illustrates, you had to invent a particular way to organize the "TOC" and semantics about the relationship of the html files in the "folder". That means it was not interoperable to assistive technology who may not be able to discover these things, as well as other agents.  Note that while you can make an ad hoc publication on the Web accessible at a micro level - so that e.g. that navigation affordance works according to WAI-ARIA - that doesn't mean that the assistive technology would necessarily recognize it as a full-fledged publication and provide publication-specific affordances - it will be just another web app.

Of course when I wrote "there is no definition" I mean, in the context of the WG role, that that there is no standardized interoperable definition. There are many ad hoc definitions, and that is a core part of the problem. Standards exist only to facilitate interoperability. By standardizing what a publication is on the Web we will facilitate interoperability at a higher level than is possible today (some specific use cases should fall out from the action item above, plus there will be others that we can't yet imagine).

Moving on from the question of whether such a definition is important to how we should achieve it. Certainly it could be possible to use URL path as a standard way to implicitly define a publication as a set of assets as it sounds like you are proposing with your reference to "folder". That is why I listed it as one of the three possible solutions, along with in-HTML mechanism and external manifest. 

But as you well know there are many cases where resources sharing a URL path are not logically related, and may not even exist in any "folder" in a file system but e.g. when resources are requested, representations may be retrieved from a database or even dynamically generated. My personal belief is that it is too late for us now to ex post facto define additional semantics based on URL paths, over and above the limited semantics already defined by the Web architecture (which have mainly to do with same-origin access restrictions).

And, even if we can use URL path to indicate a relationship among resources, that does not imply an order. A publication (in my view) is not simply a bag of resources, it must have an order of its top-level constituents. It has been suggested (Dave Cramer) that we could use alphanumeric sort order or some other naming convention as implicitly defining an order (a la CBZ). But to me this would further abuse Web architecture in which resource names are not necessarily semantically significant. Just because we have 1.jpg, 2.jpg, 3.jpg in a folder does not imply that the intended consumption order is 1, 2, 3. And this gest exponentially more complicated if the names aren't that simple. I believe trying to make standardize this kind of overlay semantics would have negative implications for internationalization.  So I am not a fan of this approach other than for the special case of index.html implicitly defining a publication with a single resource in its spine, which is already there.

As far as a JSON manifest being divergent from the Web, given that Web App Manifest exists as a JSON manifest it is hard for me to understand that having publications using a JSON manifest (particularly if it is unified with the former) to be any kind of divergence at all. Unless you are going to argue that somehow Web Apps work, within Web Platform Working Group, is not part of OWP. I'm not saying this is the way we must go, of course, but to argue that it would be improper to do so seems illogical. But I would certainly not see it as required - again for the special case of a publication with a single top-level resource in its spine, I believe we must handle that without requiring anything more than an index.html. But in the more general case where the top-level resources are logically peers, then we need something else. 

--Bill


-----Original Message-----
From: Leonard Rosenthol [mailto:lrosenth@adobe.com] 
Sent: Tuesday, June 27, 2017 6:05 AM
To: daniel.glazman@disruptive-innovations.com; public-publishingbg@w3.org
Subject: Re: PROPOSAL: scope of Web Publications spec should be minimized

This is why we agreed on the last call to start with the use cases from the UCR document, looking at each to determine which are WP vs. PWP and then which require a manifest.

Leonard

On 6/27/17, 12:46 AM, "Daniel Glazman" <daniel.glazman@disruptive-innovations.com> wrote:

    Le 26/06/2017 à 17:39, Bill McCoy a écrit :
    
    > 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). 
    
    The words above are already a source of disagreement because many see it
    as a "MANIFESTED multi-resource ordered collection of related content".
    I have myself published an online book in the form of several html
    documents and a toc. All in all, it's a folder, a navigation document
    (but the browser also offers a folder view I could have used), a
    dozen of plain html files, a stylesheet and a folder of images. No
    manifest, no metadata, and still it's a "publication" in the pure
    dictionary's sense of the term. From my POV, a web folder with a top
    URL is a publication. A single document on the Web is a publication.
    A web site is a publication. An EPUB is a publication. The only
    difference between an EPUB and the others is that we don't have (yet)
    the mechanism allowing to recursively crawl the dependent URIs from the
    uncompressed package's URI. If all of these are publications, maybe we
    don't need to define "publication" and we only need to specify what
    happens if the top URI targets a resource of a given kind.
    
    Finally, again from my point of view but with my BlueGriffon EPUB
    editor's hat on, anything that makes us diverge even super-lightly from
    the front-end Web (for instance requiring a JSON manifest) is a
    strategic mistake and will make browser vendors flee away. The OWP has
    everything we need to put metadata into html, svg or generic xml
    instances; we don't need extra stuff.
    
    </Daniel>

Received on Tuesday, 27 June 2017 14:28:34 UTC