Re: Subgroup to handle semantics of HTTP etc?

noah_mendelsohn@us.ibm.com wrote:
> That's an interesting question.  How about if, instead of a clock, I said 
> the resource was "the current time in Boston"?  The current time in Boston 
> can be quite well conveyed in a message, I'd think, yet clearly there will 
> be different representations at different times.
>   
I actually supports 200 about that.  After httpRange-14, people think it 
is not O.K.  Because if they want to describe the representation of the 
time, such as the string or image, they need a different URI.  So, they 
think the clock must be implemented as a non-information resource. And 
303 redirect the clock to the text or image.  This is where i start 
having problem.

> No.  It says that if you wanted to, you could come up with a message that 
> would convey the essential characteristics.  It doesn't, at least in the 
> statement you quote, say the every representation must do that.  I think 
> we agree that negotiation is allowed based on language, say French and 
> English.  Let's assume that there is a press release written originally in 
> French, and translated into English to support access by both French and 
> English speaking readers.  Surely we don't think that the back translation 
> from English to French is unambiguous.  So, I've shown by at least that 
> counter example that, although the press release is well representable in 
> a message, not every good representation must suffice for fully 
> reconstructing the resource.  Now, you used the words *fully understand*, 
> and I confess I find them a bit ambiguous, but if you meant fully 
> reconstruct, I don't think the quote from WebArch requires that.
>   
This is exactly my point.  People think non-IR cannot 200 because the 
returned message can NOT *represent* what the URI identifies.  What I 
want to say is that the same goes to an information resource.  Then a IR 
or non-IR, whichever definition you want, should not behave differently.
> Now, I've never believed in the superiority of the current 200 semantics 
> to the degree that, say, Tim appears to.  I don't see why the Web would 
> have crumbled if 200 had instead been defined as:  I'm giving you some 
> 'representation' that will at least vaguely remind you of the resource, so 
> by all means return a 200 for a human being and when you send along her 
> picture!'  Still, we're down the road with a different definition for 200, 
> and I don't propose to change it.  I admit that it's a little incongruous 
> to say '200 is only acceptable if you could have given a full fidelity 
> representation of an object, but it doesn't mean that in this particular 
> case you have done so!'  Nonetheless, that's my understanding of the 
> current design.  For better or worse, it allows you to infer from the 
> status code something about the nature of the underlying resource.
>   
I think we, in fact, agree with each other.  I do not have problem with 
200.  I do have problem with httpRange-14 and 303.  I consider which 
respond code to use is an engineer issue but not ontological issue. 

But httpRange-14 mixes two different issues.  Hence, people start to 
wondering which kind of things are IR and which are not so they can 
implement it correctly.  For instance, your clock? Time? A Name? A 
Namespace? Ontology? 

What I hope AWWW to do is to scratch off the definition of IR.  Instead, 
to suggest a consistent view on the resource, i.e., URI denotes 
resource/things and there is no such thing as information resource.  
Also, AWWW also needs to emphasize that http-URI has no inherent 
relationship to the HTTP protocol. The latter is just one out of many 
possible *protocols* that you can ask for the information of a URI.  
What a user gets back from using HTTP to dereference an HTTP-URI is just 
*a* message, which content may help the client to understand more about 
the resource identified by the URI .  But to what degree it helps, a 
client has to open the message and check it for himself.

Regards,

Xiaoshu

Received on Monday, 22 October 2007 22:44:29 UTC