Hallvord R M Steen wrote:
I've built two-three websites that use content/language negotiation
and I now consider it an architectural mistake to rely on negotiation
because the URLs no longer uniquely identify the variants I in many
scenarios need to identify. It's OK-ish to do it as a pure format
choice where the server and UA just agree on using the PNG or GIF
version for an <IMG> tag. For links *users* (and FWIW search engines,
validators and other agents) may interact with it's however a big
mistake to move away from one URL per variant of a resource. In light
of my content negotiation experiments and experience I'd say an Access
attribute in HTML would be harmful to the usability of URLs.
As a URL user (web browsing human, HTML author, linker, bookmarker,
E-mail-with-links author) I often want to be sure about what variant
of a resource I link to. To be explicit about this across scenarios
requires explicit URLs with language and type information.
Agreed. I think the assumptions underlying content negotation are
flawed, and thus the mechanism itself is flawed and causes confusion and
inconvenience when used in practice. The sentiment underlying this
proposal seems to be that HTTP content negotation would work fine if
only the pesky browsers would support it, but I think there are
deeper-rooted problems than simply a lack of browser support.
I think a better solution is to publish the HTML version with attributed
hyperlinks, like this:
<link rel="alternate" type="application/pdf" href="document.pdf">
or, if you prefer:
<a href="document.pdf" rel="alternate" type="application/pdf">
PDF Version
</a>
This way clients can discover the alternative representations, but the
alternative representations are all directly addressable so you can link
to a specific representation. This approach is used in practice
successfully today to make available Atom representations of HTML pages
across the web. Atom feeds are arguably the best example of a successful
completely-RESTful API that we have today, so this approach is proven
to work.
In future, once IETF has finished specifying this, it may also be
possible to do this in the HTTP response headers for non-HTML resources:
Link: <document.pdf>; rel="alternate", type="application/pdf"
(or something similar)
...and some other document formats such as Atom already provide
equivalent linking constructs that you can use today.
