Re: Question about the On Linking Alternative Representations TAG Finding

All --

Several thoughts.

Sent now because my long analysis keeps getting longer, the more
complications you all throw in -- complications which, it seems to
me, serve well to obscure the basic principles, but do not change
the final answers.

Might I suggest perusal of RFC 2295 "Transparent Content Negotiation
in HTTP" [1] and RFC 2296, "HTTP Remote Variant Selection Algorithm --
RVSA/1.0" [2], which go into the nuances in substantial detail?

Among other gems which may help resolve the current confusions,
I offer [3] --

   4.6 Retrieving a variant by hand

       It is always possible for a user agent to retrieve the
       variant list which is bound to a negotiable resource.  The
       user agent can use this list to make available a menu of all
       variants and their characteristics to the user.  Such a menu
       allows the user to randomly browse other variants, and makes
       it possible to manually correct any sub-optimal choice made
       by the automatic negotiation process.

The way you've outlined things, Richard, we can *not* retrieve the
variant list -- and that breaks RFC, and I suggest it also breaks
Web Architecture, which you deem distinct from RFC.


Some other key points, not all from the above RFCs --

+ Not all Resources have URIs, but anything with a URI assigned to
  it is *definitively* a Resource.

+ A Representation of a Resource may not have its own URI, and
  thus may not be easily indirectly referenceable.  Nonetheless,
  that Representation *is* itself a Resource.

+ Any Representation with a URI is *unequivocally* a Resource.

+ We can Describe Resources.

+ We can Describe Representations.

  + In both cases -- MIME type?  URI?  Web-transmissible?  Encoding?
    Language?  These are all descriptors.  There are others.

+ Whether the thing behind a URI should be labeled and treated as
  a Resource or a Representation changes depending on the transaction
  at hand.  Most importantly, what did the (User) Agent ask for? This
  includes URI, Accept: header, Language, and other attributes of the
  request.  The URI denotes the Resource.  The others all describe the
  Representation requested -- which *may* *appear* to be the Resource,
  if all attributes of the request match the Resource, itself.

+ A negotiation is *at least* but is *not limited to* a single Request
  and a single Response.  A negotiation may include dozens or even
  hundreds of Requests and Responses.  (oh, no, not more R words!)

+ *Transparent* content negotiation is not all there is to *HTTP*
  content negotiation.

+ Transparent negotiation may be preferred for many reasons, but
  is not the best answer in all cases -- particularly not where
  ambiguity exists as to what the Best Response might be from
  the Server.

+ "Transparent" negotiation was so-named "because it makes all
  variants which exist inside the origin server visible to
  outside parties" [4]


Richard, you have suggested that HTTP Con-Neg is not like ordering
something in a restaurant.  Indeed, the way *you* treat Con-Neg, it
is not.

However, I suggest that it *should be* like ordering something in
a restaurant.

If a customer asks for something and the kitchen can't deliver, the
kitchen should say so -- and in best case, the kitchen should offer
some list of options that it considers reasonable substitutes.  The
kitchen may also choose to pre-emptively include what it thinks the
customer will select from that list, but the list is most important.

The customer can then determine whether one of those substitutes
will suffice, or ask for something else entirely.

The customer should not need to ask first "do you have water as liquid?"
or "what forms of water do you have?"  Asking for "water as liquid"
implicitly asks the first, and implies the second.  (Why does this
sequence sound familiar?  Oh, yes, HTTP/1.0!  Ineffic)

The kitchen cannot know why the customer wants liquid, as opposed to
either solid or vapor -- but the kitchen can say "I have no liquid,
but I do have solid and vapor."

The customer can then request, "orange juice, liquid" because they
were thirsty -- it was the liquid that was important.  But if the
kitchen simply delivers a glass of ice because "it's the best we
have" with no option to get something else -- the customer will
leave, and not come back.  Nor should they return.

The kitchen is responding with their best guess at what the customer
wants -- but the kitchen is *wrong*.

The analogy may seem forced to you, because of your own background
and experience, but it seems entirely natural to me.  Further, I fail
to find an analogy (forced or otherwise) which fills your suggested
model, and *that* suggests that your model is broken.

I will grant that the User Agent (Web browser or otherwise) may not
always be able to make the best decision based on what the Server
returns as an alternatives list -- but that is why transparent
negotiation is only *part* of HTTP Con-Neg.  Humans may be enlisted
to make the nuanced choice, and work may then proceed.

Be seeing you,

Ted




[1] http://www.rfc.net/rfc2295.html

[2] http://www.rfc.net/rfc2296.html

[3] http://www.rfc.net/rfc2295.html#s4.6

[4] http://www.rfc.net/rfc2295.html#p4




-- 
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Evangelism & Support         //        mailto:tthibodeau@openlinksw.com
OpenLink Software, Inc.      //              http://www.openlinksw.com/
                                 http://www.openlinksw.com/weblogs/uda/
OpenLink Blogs              http://www.openlinksw.com/weblogs/virtuoso/
                               http://www.openlinksw.com/blog/~kidehen/
    Universal Data Access and Virtual Database Technology Providers

Received on Monday, 11 August 2008 20:20:21 UTC