- From: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
- Date: Mon, 11 Aug 2008 16:18:38 -0400
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: wangxiao@musc.edu, Sebastien Lambla <seb@serialseb.com>, "T.V Raman" <raman@google.com>, john.kemp@nokia.com, www-tag@w3.org, kidehen@openlinksw.com
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