search

w3c / wpub

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

The URI, URL, and URN of a web publication #11

Closed dauwhe closed 6 years ago

dauwhe commented 7 years ago

This is another issue being extracted from #5, with the hope that we will focus on the matter at hand.

How do we identify and locate a web publication? We do not seem to have an agreement yet on whether a WP should be located by the URL of the manifest, or the URL of the first content document. I have a strong preference for the latter.

TzviyaSiegman commented 7 years ago

not to be too nitpicky, but I think we have agreed to use the term "address". We are not in the business of identifying anything ;-)

HadrienGardeur commented 7 years ago
  1. The "start" link and the "self" link are two different concepts that can be separately handled by a manifest. This way the self link can be exchanged in APIs or specialized UAs, while the start link is what the user is aware of.
  2. Many other technologies (including Web App Manifest and RSS/Atom) have a standalone machine-readable document that basic UAs do not understand or render in any specific way. Yet this has never been a problem for these technologies. Why would Web Publications be any different?
  3. While auto-discovery is a good thing, we can't force it and can't expect that the first content document will always contain a link to the manifest or an embedded manifest.
  4. If two publications have the same first content document, we still need an address for each publication.
  5. For a UA, it's much more convenient to have direct access to a manifest than to either have to extract an embedded manifest, or indirectly discover it through a link.
rdeltour commented 7 years ago

The "start" link and the "self" link are two different concepts

Right, good point.

While auto-discovery is a good thing, we can't force it and can't expect that the first content document will always contain a link to the manifest or an embedded manifest.

Why can't we? PWAs require that the app manifest is linked from the HTML (there's no spec, but it's the common documented practice, the "cow path"), why would Web Pub be any different?

For a UA, it's much more convenient to have direct access to a manifest than to either have to extract an embedded manifest, or indirectly discover it through a link.

For a browser, I'd say it's much more convenient to get HTML first.

HadrienGardeur commented 7 years ago

Why can't we? PWAs require that the app manifest is linked from the HTML (there's no spec, but it's the common documented practice, the "cow path"), why would Web Pub be any different?

They don't require anything. They give you the possibility to offer auto-discovery.

You're not required to include a link to a Web App Manifest from all resources of a Web App, you include a link whenever you want and/or need it.

For a browser, I'd say it's much more convenient to get HTML first.

Not for a browser who knows how to deal with a WP. The other browsers would never be aware of the existence of this manifest anyway.

rdeltour commented 7 years ago

You're not required to include a link to a Web App Manifest from all resources of a Web App, you include a link whenever you want and/or need it.

Right, but if you want to make the Web App Manifest actually used, you do need this link, right? Is there any implem which uses a Web App Manifest directly? (I'm not aware of any).

The other browsers would never be aware of the existence of this manifest anyway.

Exactly, that's why pointing to HTML first offers better graceful degradation.

HadrienGardeur commented 7 years ago

Right, but if you want to make the Web App Manifest actually used, you do need this link, right? Is there any implem which uses a Web App Manifest directly? (I'm not aware of any).

Sure, any API could rely entirely on Web App Manifest directly. For example an OPDS integration in a Readium-2 based UA. I can imagine many use cases that wouldn't require auto-discovery to exchange and display a WP.

Exactly, that's why pointing to HTML first offers better graceful degradation.

Do you point a RSS reader to a website first and then let it figure out how to discover the right RSS (they could be multiple links)? Of course not. It's exactly the same here.

Once again, the main issue here is that @dauwhe is mixing up two concepts together ("start" and "self").

As long as we have a standalone manifest (instead of an embedded one), it'll be accessible directly in a basic UA. This has nothing to do with using this URI as an identifier or not, and saying that the "self" link should be the URI of the manifest won't make the problem any worse or better.

HadrienGardeur commented 7 years ago

Since we've moved to separate issues, I'll quote a previous comment:

What we use as the WP identifier is deeply tied to how we represent and/or link to a manifest.

If a manifest is an external resource with its own URI:

  • it makes it easier for a UA to directly access and use the manifest
  • it also means that one way or another, this manifest could be accessed by a clueless UA that won't know what to do about it

If a manifest is embedded in HTML (most likely using Githubissues.

  • Githubissues is a development platform for aggregating issues.