RE: Question about the On Linking Alternative Representations TAG Finding

Good post, but just to correct the terminology . . .

> From:  T.V Raman
>
> Richard,
> Thank you for adding value to the TAG finding I wrote with the
> insights you have raised with this discussion -- see my summary
> below.
>
> I think the key insight in all of this is what you put very well:
>
> A URI is a resource --- a generic resource has multiple
> representations --- and in turn, each representation has  a URI.

s/representations/variants/g

>
> The question you ask is an interesting one, and in terms of Web
> Architecture in this regard, I've usually managed to preserve my
> sanity in the last 15 years by following the maxim "dont look
> more than one level deep in a recursive pattern".
>
> As  a case in point, you could recreate this puzzle  on an axis
> different from content-type --- e.g. language. So take a generic
> resource U, do language negotiation,
> U has alternative representations U_1, U_2, ..U_n. Further let's

s/representations/variants/

> now pull in content-type as well and  assume that each of the U_I
> above are available in more than one content-type. Now, which
> axis goes first in the process of resolving a resource to a
> particular representation -- language or content-type? In cases
> where the matrix  language-X-contentType is fully populated, and
> where that matrix is symmetric, order does not matter. But in all
> other cases, the order in which these axes are resolved will make
> a difference.
>
> Returning to your final question, where the user-agent does
> content-negotiation, indicates a preference for one type, but
> asks by URI for the other, I would say respect the URI. I dont
> claim this to be *correct* in any sense, other than that I would
> break the tie this way. Reasoning: The client, by asking for a
> URI that directly resolves to a given representation has

s/representation/variant/

> essentially bypassed content-negotiation.
>
> Another way to arrive at this conclusion with respect to
> best-practice, and one that I believe the finding would benefit
> from is:
>
> If publishing a generic-resource, make sure that the URIfor that
> generic resource does not collide with the URI for any one of its
> representations.

s/representations/variants/

>
> At the time I wrote the finding, I did not assert the above
> because that would actually fly in the face of general practice
> on the Web, which is to let the URI for the generic resource also
>  serve as a proxy (alias) for the most commonly asked for
> representation.

s/representation/variant/

>
>
> In cases where the most commonly catered for client is a Web
> browser with a live human at the other end,
> I believe this practice of aliasing the URIfor the
> generic-resource with the URI for the HTML version is still a
> better choice from a user interface perspective, as well as for
> avoiding one additional network round-trip.
>
> So perhaps one option is to slightly water down what I asserted
> above as might be useful to add to the finding --- and say that
> if the user-agent sends preference about content-type, then
> ... As you rightly point out, web browsers have always sent
> accept: */*  so any user-agent that sends a more refined accept
> header can be  viewed as being something more modern than a
> legacy Web browser.



David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.

Received on Wednesday, 6 August 2008 16:57:50 UTC