search

w3c / wpub

W3C Web Publications
https://w3c.github.io/wpub/
Other
78 stars 19 forks source link

Differentiating the primary entry page URL from the publication address #458

Open BigBlueHat opened 5 years ago

BigBlueHat commented 5 years ago

Finally following up the action I took in https://github.com/w3c/publ-wg/issues/48 (because I haven't been able to locate my earlier draft...). This partly relates to #453.

The beginning of the Primary Entry Page section begins with this text:

The primary entry page represents the preferred starting resource for a Web Publication and enables discovery of its manifest. It is an [HTML] resource that is returned when accessing the Web Publication's address, and MUST be included in either the default reading order or the resource list.

If a Web Publication address ended in a / and the primary entry page were served as the default resource (per the above), then the Web Publication address could be /moby-dick/ while the primary entry page's URL would be /moby-dick/index.html (or similar).

This does presume that the URL scheme (and the servers providing responses) can also provide such a "default resource" which itself would have it's own URL.

An alternative to requiring that Web Publication addresses end in / would be to require a fragment identifier be included in the publication address. However, those cannot be dictated by anything other than their content. That said, if the manifest were required to be embedded, it would already have an id which referenced the "binding material" (i.e. the manifest) of the publication.

In which case, the URL's would be /moby-dick/index.html#publication as the publication address (assuming <script id="publication"> in the PEP) and /moby-dick/index.html for the URL of the PEP. This does have the added possible value that one could attempt to do "direct" discovery (rather than using <link rel="publication" href="#publication">) when such a URL is used.

So...I'd propose we consider two options:

Using the URL of an un-embedded manifest has no fallback mechanism and would result in the display of a JSON to the human reader using current UAs (if it displayed at all). Whereas, both the above options would still result in the display of the Primary Entry Page.

iherman commented 5 years ago

Issue #327 has already been discussed and closed, and the WG decision is that an embedded manifest is RECOMMENDED but not REQUIRED. We should not re-open an issue unless new problems/use cases, etc., came to the fore.

I think the only option we should discuss is the first, i.e.,