- From: Xiaoshu Wang <wangxiao@musc.edu>
- Date: Sun, 28 Jun 2009 23:13:48 -0400
- To: Jonathan Rees <jar@creativecommons.org>
- CC: "www-tag@w3.org" <www-tag@w3.org>
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? As defined in section 14.1 of RFC2616, the HTTP’s Accept header can be extended with an “accept-extension” field by appending sets of name-value pairs after the “accept-params”. For instance, the Accept: application/xml;q=1;d= “http//psidev.sourceforge.net/mi/rel25/src/MIF25.xsd” would allow a client to content negotiate the PSI-MI format. All that is needed is a standard convention for the token *d*, which I use it for short of (document-type). Xiaoshu > 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@musc.edu> 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@musc.edu> wrote: >>> >>> >>>> Eran Hammer-Lahav wrote: >>>> >>>> >>>>>> -----Original Message----- >>>>>> From: Xiaoshu Wang [mailto:wangxiao@musc.edu] >>>>>> 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 >>>>> >>>>> >>> >>
Received on Monday, 29 June 2009 03:14:36 UTC