Re: Hyperlinks and content negotiation

Mike Kelly writes:

> Smylers wrote:
> 
> > Surely even if HTML provided for this such developers would still be
> > hampered by URLs being passed around without content types (and
> > users not being used to them). ...
> 
> A 'cold start' request to a URI out of the context of a particular
> application flow should revert to the UA's generic Accept header. The
> significance of a URI is to identify a resource. There isn't a
> situation where the server risks serving the 'wrong' content in
> response to a given request,

A friend states over instant messaging that he can't see the 'subscribe
to feed' link on a poorly designed page.  I happen to spot it,
right-click on the link, choose 'Copy URL', and paste it into the reply
to my friend.  He clicks on the link in his IM client ... only to end up
loading a second copy of the page he started with.

So far as those two users are concerned, the 'wrong' thing was served.
That it happens to be a different represenation of the same underlying
content doesn't make the error any more acceptable.

> ... provided server's conneg logic is sensible.

Authors have collectively demonstrated that if there is a way to use an
HTML feature non-sensibly, somebody will do it.  So there's a balance
between adding a feature useful for experts and avoiding adding
something which many others will get wrong.  Particularly when, as in
this case, the potential failure mode is so drastic -- much worse than a
mis-styled element or similar.

(The extreme situation is if a feature becomes so mis-used that browsers
found they could make more content 'work' by ignoring the feature than
implementing it.)

Content negotiation could succeed if only those who know what they are
doing touch it, that typical authors aren't somehow tempted to start
playing with it.  That's possible, but not certain.  I don't know how
we'd gather data either way.

> > > There are use cases in which the distinction between a resource's
> > > representations are relevant to the flow of an html driven
> > > application, e.g. the difference to a browser between an atom and
> > > an html representation of a blog resource.
> 
> It is not that using separate URIs "doesn't work", just that it may be
> a sub-optimal for a particular system that would benefit more from a
> strictly standardized distinction between resources and
> representations.  A clear distinction between the two allows
> intermediaries to make valuable, automated assumptions about the
> significance of a request.

Please could you be more specific about these assumptions and their
value.  HTML5 is designed by finding problems that need to be solved
first, and then looking for solutions to those problems.

(In this case it sounds like content negotiation may be the only
solution to the particular problem, but for the rigor of the spec we
don't want to add features without being sure what they are for and that
they are the best way of solving the problem.)

> > In what way does it help for a cache to cache a blog's homepage and
> > feed labelled with the same URL compared with caching them with
> > separate URLs?
> 
> The benefits are realized in terms of automated cache invalidation.
> Modifying a resource should automatically invalidate all of its
> representations.

Thanks -- that makes sense.  You mention "assumptions" in plural above,
so I presume there are others?

> It's not a perfect solution to all problems - it's a trade-off.  If
> highly-efficient automated caching is more valuable to your system
> than being able to avoid the highly risky world of plain text URIs and
> grumpy twitter users, then there is an obvious choice to be made.

That sounds fair enough.  Do you have any evidence of the numbers of
developers who would choose the cache-invalidation advantage over the
plain-text URL advantage?

Unfortunately HTML5 can't cater for every valid requirement, so
generally doesn't add features that would be useful to only a very small
number of authors (for example HTML5 doesn't add a <ship> element,
despite some authors having a very valid requirement to distinguish
names of ships on their pages; mentioning ships simply isn't common
enough).

Cheers

Smylers
-- 
http://twitter.com/Smylers2

Received on Saturday, 17 October 2009 07:39:03 UTC