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: Sun, 28 Jun 2009 23:13:48 -0400
Message-ID: <4A48316C.6070002@musc.edu>
To: Jonathan Rees <jar@creativecommons.org>
CC: "www-tag@w3.org" <www-tag@w3.org>
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?  As defined in 
section 14.1 of RFC2616, the HTTP’s Accept header can be extended with 
an “accept-extension” field by appending sets of name-value pairs after 
the “accept-params”.  For instance, the

Accept: application/xml;q=1;d= 
“http//psidev.sourceforge.net/mi/rel25/src/MIF25.xsd”

would allow a client to content negotiate the PSI-MI format.

All that is needed is a standard convention for the token *d*, which I 
use it for short of (document-type).

Xiaoshu
> Rather than argue this conneg point yet again now, I will just say
> I'll do what I can in the coming months to ensure that the TAG's
> advice gets stated clearly enough that you and others can at least
> give it a fair hearing, even if in the end you don't agree with it.
>
> Best
> Jonathan
>
> On Sat, Jun 27, 2009 at 11:55 PM, Xiaoshu Wang<wangxiao@musc.edu> wrote:
>   
>> Jonathan Rees wrote:
>>     
>>> [less cc:]
>>>
>>> Tracker, I write this email primarily for you. This whole thread is
>>> about ISSUE-53 [1]. Current LRDD discussion bears on ISSUE-62 [2].
>>>
>>> Xiaoshu, you're essentially pressing the TAG again to make a formal
>>> statement on recommended use of conneg, as Michael Hausenblas did in
>>> February [3]. I'm sorry that this has fallen to the periphery of the
>>> TAG business heap. The best I can do now is to point you to the advice
>>> [4] that we gave to the Cool URIs for the Semweb editors, which agrees
>>> with Eran's reading.
>>>
>>>       
>> Yes.  I am pressing and I hope TAG can take it seriously.  I am not pressing
>> TAG to make a recommended use on conneg.  Conneg is there and people is
>> start using it.  I don't think AJAX community needs to ask TAG before using
>> conneg.  The mechanism is there, thanks to the well design of HTTP, we can
>> just use it.  What I am asking TAG to rethink httpRange-14 because it will
>> let us know how much nonsense that issue-62 as well as LRDD proposal is.
>>  (Sorry for my bluntness, but why waste time on propose something that you
>> cannot even define?)
>>
>> If we know that Information Resource does not make sense, then Generic
>> Resource does not make sense either because what is the definition of this
>> genericity?  As I have discussed in the manuscript "Is the Web a Web of
>> Document or Things?" (Going to be presented in IR-KR 2009,
>> http://ir-kr.okkam.org/workshop-program/irkr2009-proceedings.pdf), all these
>> concepts are based on a somewhat "one resource to one representation"
>> assumption. It is the same on "the uniform access to metadata".  What is
>> "metadata"?  If you cannot define it, do you honestly think that a proposal
>> will be of any use?
>>
>> The web is built on three things: URI, Resource, Representation.  There is
>> no fourth or fifth essential concepts.  Metadata,  generic resource,
>> information resource, whatever they are must be one of the three entities.
>>  Thus, you have to follow the design pattern of the first three entities and
>> then consider what we can standardize next for a more specific problem.
>> Without solving httpRange-14, proposing anything else is like building a
>> house from top and hope that all those design can consistently converge to a
>> solid foundation.  I don't think that is the way it works and I don't think
>> it can work either.
>>
>> Xiaoshu
>>     
>>> Jonathan
>>>
>>> [1] http://www.w3.org/2001/tag/group/track/issues/53
>>> [2] http://www.w3.org/2001/tag/group/track/issues/62
>>> [3] http://lists.w3.org/Archives/Public/www-tag/2009Feb/0074.html
>>> [4] http://www.w3.org/2001/tag/2008/02/28-minutes#item01
>>>
>>> On Thu, Jun 25, 2009 at 7:36 PM, Xiaoshu Wang<wangxiao@musc.edu> wrote:
>>>
>>>       
>>>> Eran Hammer-Lahav wrote:
>>>>
>>>>         
>>>>>> -----Original Message-----
>>>>>> From: Xiaoshu Wang [mailto:wangxiao@musc.edu]
>>>>>> Sent: Thursday, June 25, 2009 4:17 PM
>>>>>>
>>>>>> Now, given one information, you are proposing three mechanisms to
>>>>>> specify it.  Isn't it obvious that something is *fundamentally* wrong
>>>>>> about the proposal?
>>>>>>
>>>>>>
>>>>>>             
>>>>> No. That's like saying an HTML document should never repeat any of the
>>>>> links provided in the HTTP header, etc.
>>>>>
>>>>>           
>>>> Of course, it shouldn't.  In fact, no HTTP header should use URI except
>>>> the
>>>> Content-type, which unfortunately is not defined in this way.
>>>>
>>>>
>>>>         
>>>>> The reality is that there isn't any single solution that satisfies all
>>>>> the
>>>>> use cases we have. After over a year of debating it, this combination of
>>>>> three methods is the best we have come up with, and it works fine. Is it
>>>>> a
>>>>> beautiful solution with clean architecture? No. But it is the only
>>>>> solution
>>>>> we can deploy today and expect people to use.
>>>>>
>>>>>
>>>>>           
>>>> Define your "fineness"?  Making something works does not mean solving the
>>>> desired problem.  If you know the solution is not clean, you should not
>>>> that
>>>> it should not be proposed at this level because it will have long term
>>>> effects.
>>>>
>>>>         
>>>>> If you read the proposal, it clearly goes through the list of available
>>>>> methods and states why this approach was chosen.
>>>>>
>>>>>
>>>>>           
>>>> Nope.  Your evaluation on content negotiation is very vague and, in my
>>>> opinion, partial.
>>>>
>>>> Xiaoshu
>>>>
>>>>         
>>>>> EHL
>>>>>
>>>>>           
>>>       
>>     
Received on Monday, 29 June 2009 03:14:36 GMT

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