RE: addressable identifier?

> It seems that there are more people leaning towards external manifest

 

It tends to make the most sense when there are multiple primary resources (just not loving that term yet). In the case of a single-document publication, finding an external manifest to discover the page you were at is the only page seems like a redundant exercise. But then, extracting the script data and converting it to json maybe offsets any potential optimization embedding affords. (It's tempting to think up over-optimizations.)

 

If a driver of embedding is file minimization, though, are there many scenarios where a publication will actually be a single resource, and what does it even matter? Taking a web publication offline isn't influenced by this, and packaging to make portable will potentially make all publications a single file. No one seems overly concerned about scripts or css files being external.

 

Matt

 

From: Hadrien Gardeur [mailto:hadrien.gardeur@feedbooks.com] 
Sent: July 27, 2017 2:55 PM
To: Cole, Timothy W <t-cole3@illinois.edu>
Cc: Romain <rdeltour@gmail.com>; Laurent Le Meur <laurent.lemeur@edrlab.org>; W3C Publishing Working Group <public-publ-wg@w3.org>
Subject: Re: addressable identifier?

 

On the Web, even in a Semantic Web / RDF context, the idea of canonical has just not held up well in most general contexts, in spite of the fact that you do see canonical as a value for many link rel attributes. Persistence of URL(s) for a Web Publication is critical, but Web resources, like people, in spite of our preferences, may be known by more than a single, canonical identifier (name).  I would argue we may not want to make a single canonical URL a core requirement - though we certainly could encourage it as a best practice. 

 

If we don't, we'll still need a way to figure out that two URIs are basically serving the same manifest for a given publication.

 

 

The HTML versus non-HTML manifest URL raised earlier in this thread could potentially also be dealt with more as a matter of serialization and composition than as a one or the other binary choice.  For a UA wanting HTML, the URL pointing to the manifest could result in an HTML representation that embeds the manifest, e.g., as a script type="application/json" or type="application/ld+json. This representation (if the publisher so desired) could then also include/embed  by reference the 'primary' resource, so that to a Web browser user it looks like he or she has received the content of interest right away.  Machines reading this HTML would see the manifest in addition to the primary resource, or could just request the manifest only through content negotiation (if the publisher wished to offer this option or if we make manifest serialized a specific non-HTML way a minimum requirement).

 

This has been discussed on Github previously: content negotiation is by far the most elegant solution, but we also can't expect that we'll always have that option available.

 

For the manifest, there's no clear consensus yet between:

* external manifest as a JSON representation
* embedded manifest in a HTML document (probably using script)

It seems that there are more people leaning towards external manifest, but Florian Rivoal for example has advocated in favour of an embedded manifest in an HTML document.

 

 

As said, we have options here, I would just not want to be overly prescriptive when not required.

 

We do have options, but having too many options can always be confusing. We need to agree at least on how the manifest will be accessed (external or embedded).

 

Hadrien