W3C home > Mailing lists > Public > www-tag@w3.org > June 2009

Re: LRDD Update (Resource Descriptor Discovery) and Proposed Changes

From: Xiaoshu Wang <wangxiao@musc.edu>
Date: Mon, 29 Jun 2009 11:46:06 -0400
Message-ID: <4A48E1BE.9020401@musc.edu>
To: Jonathan Rees <jar@creativecommons.org>
CC: "www-tag@w3.org" <www-tag@w3.org>
Jonathan Rees wrote:
> On Sun, Jun 28, 2009 at 11:13 PM, Xiaoshu Wang<wangxiao@musc.edu> wrote:
>   
>> Jonathan Rees wrote:
>>     
>>> Xiaoshu,
>>>
>>> The architecture you advocate is plausible. The preferred architecture
>>> that I hear coming the TAG is a different one. The TAG obviously can't
>>> go back and change RFC2616 and expect anyone to listen, but it is
>>> required by charter to give architectural advice. You can follow it or
>>> not, that's your choice.
>>>
>>>       
>> Who said that we need to change RFC2616 to make it work?
>>     
>
> I sure didn't! You misunderstood. I meant to say that almost arbitrary
> use of content negotiation, such as what you want to do, seems
> technically OK according to RFC 2616, because it never says precisely
> what a "representation" is. The cool-uris-for-semweb opinion and
> httpRange-14 give specific good-practice-style advice that is supposed
> to discourage certain otherwise defensible uses of GET/200 and content
> negotiation. Technically speaking, any attempt to make a server stay
> within the TAG's advice would mean holding it to a contract that it
> didn't sign. The TAG doesn't have jurisdiction to change RFC 2616 to
> disallow things that are currently allowed. Therefore its advice,
> while some people may find it persuasive (especially in the
> linked-data world), is not rule of law but just a request for a
> certain "good practice". So it is the TAG who must persuade you, not
> the other way around. That's why I take your and Michael's email as
> requests for a piece of writing. The case hasn't been made clearly
> enough.
>
> I didn't want to defend either architecture just now, but don't you agree that
> 1. you are promoting one pattern of use of conneg
> 2. the cool-uris/httpRange-14/etc. advice promotes a different pattern
> 3. both patterns can seen as compatible with RFC 2616, and
> 4. the two architectures are just plain different?
> These seems terribly neutral and uncontroversial to me.
>
> But I should note that if you want a tweak to the syntax of accept
> headers you are asking for an extension to the HTTP protocol. That's
> easier than getting agreement to a restriction, which is what the TAG
> would like to do.
>
> If we can first agree on these basics, we can then put the two
> architectures side by side and see how well each meets various goals
> that we might have. The real difference between them might be a
> difference in what each is trying to accomplish.
>   
That is a very good summary.  But the question is: what is the problem?

If the problem is: let us find a way to uniform access to 
metadata/descriptor" etc. Then, I don't even know what the problem is, 
then how can we propose anything to do something about it?  Then, please 
define the "metadata/descriptor" first. 

I want to emphasize that I am not opposing people to use 303.  That is 
*their* design choice and I have no business to tell them what is best 
for them.  What I am opposing is the practice of proposing an approach 
based on ambiguous concept.  I came to conneg not because I prefer it 
but because it is the only choice.  All alternatives force me to ask 
questions that bring the questions themselves into questions.  That puts 
me in a forever loop but I need to get out of that.  I hope that TAG can 
understand that the latter is my purpose but not "conneg". 

Xiaoshu
Received on Monday, 29 June 2009 15:46:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:14 GMT