- From: Xiaoshu Wang <wangxiao@musc.edu>
- Date: Sat, 27 Jun 2009 23:55:08 -0400
- To: Jonathan Rees <jar@creativecommons.org>
- CC: "www-tag@w3.org" <www-tag@w3.org>
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 Sunday, 28 June 2009 03:55:51 UTC