- From: Eran Hammer-Lahav <eran@hueniverse.com>
- Date: Sun, 1 Mar 2009 13:04:36 -0700
- To: "Patrick.Stickler@nokia.com" <Patrick.Stickler@nokia.com>, "julian.reschke@gmx.de" <julian.reschke@gmx.de>
- CC: "jar@creativecommons.org" <jar@creativecommons.org>, "connolly@w3.org" <connolly@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
I don't need a convincing argument. You do. HTTP 1.1 is widely deployed in web servers, proxies, caches, and clients. URIQA is not. The cost of getting the entire web to support a new HTTP method is huge, especially for a read-access oriented method like MGET which must be cacheable and accessible (natively) from the most common web platform (that is, JS, Flash, PHP, etc.). As I said before, I like the concept of MGET very much. But I think it fails certain requirements such as: 1. The ability to assign URI's to metadata. MGET doesn't help me when I want to express that B describes A. While B is usually used in conjunction with A, it is a discrete resource. Producing a representation of a descriptor when that descriptor doesn't have its own URI seems like a pretty bad violation of web architecture. 2. It fails at multiple levels of meta. If C describes B and B describes A, using MGET, all I have is a URI for A... I have no way of obtaining C. 3. I strongly disagree it complies with the Equal Access Principle [1]. In a previous email you listed all the issues in deploying URIQA and the workarounds and hacks needed to get it to work. I am unwilling and unable to go on a crusade to get URIQA adopted so that the community I serve will be able to use it. If you read my full proposal for Link-based Resource Descriptor Discovery [2], you'd know that none of the 3 methods proposed offer a complete solution. That's why I have 3. Criticizing Links by picking on a single form of link (header, element, host-meta patterns) is pointless because the first thing I said in my draft is that neither one is complete. I studies URIQA carefully when I performed my analysis and it failed my requirements. So far I have not heard anything new to pursued me otherwise. EHL [1] http://www.hueniverse.com/hueniverse/2009/02/the-equal-access-principal.html [2] http://tools.ietf.org/html/draft-hammer-discovery > -----Original Message----- > From: Patrick.Stickler@nokia.com [mailto:Patrick.Stickler@nokia.com] > Sent: Tuesday, February 24, 2009 9:24 PM > To: Eran Hammer-Lahav; julian.reschke@gmx.de > Cc: jar@creativecommons.org; connolly@w3.org; www-tag@w3.org > Subject: Re: Uniform access to metadata: XRD use case. > > > > > On 2009-02-24 19:00, "ext Eran Hammer-Lahav" <eran@hueniverse.com> > wrote: > > > I'll separate the two for my next draft and correct this. > > > > Adding URIQA support in many hosted environments or large corporate > deployment > > isn't simple. It sets a pretty steep threshold on adoption [1]. > > I've seen such comments before, but have never seen a convincing > argument. > > If you are going to be doing "semantic web stuff" and publishing > metadata > about resources, then you are going to have to do something more than > just > your plain out-of-the-box web server solution, both for serving the > metadata > and for managing/authoring the metadata. > > A "plug-in" solution like URIQA, which can be integrated into any web > server > either by a method redirection proxy or by having the server pass > unsupported method requests to it, is trivially easy to add. > > After all, how hard is it to e.g. add WebDAV to a web site? In most > cases, > pretty trivial. No difference for an approach such as URIQA. > > > I actually > > like the MGET approach a lot, but I can't sell it to 90% of my use > cases. > > Consider me an extreme pragmatists... > > > > EHL > > > > [1] > > http://www.hueniverse.com/hueniverse/2009/02/the-equal-access- > principal.html > > Well, I read it, but I don't see how URIQA conflicts with your "equal > access > principle", in fact, it seems to be quite in tune with it. > > Patrick > > > > > >> -----Original Message----- > >> From: Patrick.Stickler@nokia.com [mailto:Patrick.Stickler@nokia.com] > >> Sent: Tuesday, February 24, 2009 8:48 AM > >> To: Eran Hammer-Lahav; julian.reschke@gmx.de > >> Cc: jar@creativecommons.org; connolly@w3.org; www-tag@w3.org > >> Subject: Re: Uniform access to metadata: XRD use case. > >> > >> > >> > >> > >> On 2009-02-24 18:18, "ext Eran Hammer-Lahav" <eran@hueniverse.com> > >> wrote: > >> > >>> Both of which are included in my analysis [1] for the discovery > >> proposal. > >> > >> A few notes: > >> > >> The statement "Minimum roundtrips to retrieve the resource > descriptor: > >> 2" is > >> not correct for URIQA. Only one is needed. > >> > >> URIQA also supports self declaration. The descriptor returned can of > >> course > >> include statements about the descriptor itself, though typically the > >> descriptor would be a CBD by default, which would not. Still, no > reason > >> why > >> it couldn't. > >> > >> Not sure why you would consider "Scale and Technology Agnostic" a > >> negative, > >> since in real practice, if you have a server that is going to offer > >> authoritative metadata, you have to enhance the server in some > manner > >> (e.g. > >> to insert links, etc.) so being able to modularly add a component > which > >> doesn't intrude upon the existing core web server functionality, but > >> can > >> operate in an auxilliary fashion, satisfying requests for metadata > in a > >> manner not intrinsically tied to how representations are served, is > a > >> plus > >> in my book. And solutions such as link forces content publishers to > >> mint > >> extra URIs to identify the descriptors explicitly, when usually, > >> clients > >> don't care about the identity of the descriptor, they just want the > >> metadata. So again, "technology agnostic" = "modular" in my book, > and > >> that's > >> always a plus. > >> > >> Perhaps you should split URIQA from PROPFIND since your summary of > >> PROPFIND > >> does not correctly capture its properties, and suggests URIQA is > >> essentially > >> equivalent, which it clearly is not. > >> > >> Cheers, > >> > >> Patrick > >> > >> > >>> > >>> EHL > >>> > >>> [1] http://tools.ietf.org/html/draft-hammer-discovery-02#appendix- > B.2 > >>> > >>>> -----Original Message----- > >>>> From: Julian Reschke [mailto:julian.reschke@gmx.de] > >>>> Sent: Tuesday, February 24, 2009 1:45 AM > >>>> To: Patrick.Stickler@nokia.com > >>>> Cc: Eran Hammer-Lahav; jar@creativecommons.org; connolly@w3.org; > >> www- > >>>> tag@w3.org > >>>> Subject: Re: Uniform access to metadata: XRD use case. > >>>> > >>>> Patrick.Stickler@nokia.com wrote: > >>>>> ... > >>>>> Agents which want to deal with authoritative metadata use > >>>> MGET/MPUT/etc. > >>>>> ... > >>>> > >>>> Same with PROPFIND and PROPPATCH, btw. > >>>> > >>>> BR, Julian > >
Received on Sunday, 1 March 2009 20:05:22 UTC