W3C home > Mailing lists > Public > www-tag@w3.org > March 2002

Re[2]: section 1, intro, for review

From: Chris Lilley <chris@w3.org>
Date: Tue, 19 Mar 2002 04:00:27 +0100
Message-ID: <7387616000.20020319040027@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:05 GMT