Re: LRDD Update (Resource Descriptor Discovery) and Proposed Changes

On Sun, Jun 28, 2009 at 11:13 PM, Xiaoshu Wang<wangxiao@musc.edu> 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.

Jonathan

(still ISSUE-53)

Received on Monday, 29 June 2009 14:39:24 UTC