« 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:
> [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
>>>
>
>
> [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.
>
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 |
