- From: Chris Lilley <chris@w3.org>
- Date: Tue, 19 Mar 2002 04:00:27 +0100
- To: Paul Prescod <paul@prescod.net>
- CC: www-tag@w3.org
On Tuesday, 19 March, 2002, 03:10:00, Paul wrote: PP> Chris Lilley wrote: >> >> ... >> >> Okay, but with a flourish I can produce the URI >> zip://atm.example.org/06902 or, worse, zip:06902 but just because >> these now have URIs does not lessen in any way their proprietary >> nature, and the second one is probably not dereferencable either. PP> Okay, but PP> 1. Why would anyone do such a thing? People know that non-HTTP URI PP> schemes have a massive barrier to acceptance. That was kinda my point; you posited the presence or absence of URI as a test of Webness. I was disagreeing, and arguing for at least resolvability. So, I agree, doing such a thing makes no difference whatsoever (which is why I described it as mere syntactic fluff,or something). However, it did produce a URI, which (your argument seemed to indicate) made all the difference. PP> 2. If you define your interface in terms zip: URIs, XML documents and a PP> REST-y zip: protocol, I can easily compete with you by defining an PP> alternate interface in terms of http: URIs, XML documents and the HTTP PP> protocol. You will be forced to support HTTP also just to compete. PP> Whereas, if you hide your data model behind a non-REST interface, PP> building an HTTP bridge to it could be a huge challenge. No argument there. PP> 3. Even a proprietary URI scheme is better than an arbitrary RPC PP> interface as long as it supports GET, because it is possible to add PP> dereferencing for a new URI scheme to (let's say) the whole JVM or all PP> .NET applications through well-documented component interfaces. Um. Perhaps, but see your point 1) above PP> So you PP> could get both an XSLT engine and a browser written for the JVM to have PP> access zip: data for the price of one component, not two. If these new PP> schemes actually arose as often in practice as they do in theory I could PP> imagine some slick APIs where an application would have a private cache PP> of handlers, and then fall back to the runtime library, which would fall PP> back to the operating system. So if you could find a handler for any of PP> Mozilla, or XPCOM or Linux you would be able to access zip: data. I'm PP> fairly confident that this stuff only works today for GET, not PP> PUT/POST/DELETE. Allof which is true and possible, and sure, I would like to teach my computer to dial tel: urls when I click on them. But I was not arguing *for* such schemes, merely pointing out a flaw in what you seemed to be proposing as an axiom. -- Chris mailto:chris@w3.org
Received on Monday, 18 March 2002 22:02:17 UTC