« 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:
> On Sun, Jun 28, 2009 at 11:13 PM, Xiaoshu Wang<wangxiao@...> 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
> On Sun, Jun 28, 2009 at 11:13 PM, Xiaoshu Wang<wangxiao@...> 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.
>
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
« Return to Thread: LRDD Update (Resource Descriptor Discovery) and Proposed Changes
| Free embeddable forum powered by Nabble | Forum Help |
