« Return to Thread: LRDD Update (Resource Descriptor Discovery) and Proposed Changes
Re: LRDD Update (Resource Descriptor Discovery) and Proposed Changes
by Xiaoshu Wang
::
Rate this Message:
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@...> 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@...> wrote:
>>>
>>>
>>>> Eran Hammer-Lahav wrote:
>>>>
>>>>
>>>>>> -----Original Message-----
>>>>>> From: Xiaoshu Wang [mailto:wangxiao@...]
>>>>>> 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
>>>>>
>>>>>
>>>
>>
> 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@...> 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@...> wrote:
>>>
>>>
>>>> Eran Hammer-Lahav wrote:
>>>>
>>>>
>>>>>> -----Original Message-----
>>>>>> From: Xiaoshu Wang [mailto:wangxiao@...]
>>>>>> 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
>>>>>
>>>>>
>>>
>>
« Return to Thread: LRDD Update (Resource Descriptor Discovery) and Proposed Changes
| Free embeddable forum powered by Nabble | Forum Help |
