- From: Jonathan Rees <jar@creativecommons.org>
- Date: Mon, 29 Jun 2009 10:38:45 -0400
- To: Xiaoshu Wang <wangxiao@musc.edu>
- Cc: "www-tag@w3.org" <www-tag@w3.org>
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