« Return to Thread: LRDD Update (Resource Descriptor Discovery) and Proposed Changes
Re: LRDD Update (Resource Descriptor Discovery) and Proposed Changes
by Jonathan Rees-3
::
Rate this Message:
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.
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
>>>>
>>
>>
>
>
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.
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 |
