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 02:16:12 +0100
Message-ID: <13181360812.20020319021612@w3.org>
To: Paul Prescod <paul@prescod.net>
CC: www-tag@w3.org
On Tuesday, 19 March, 2002, 01:43:09, Paul wrote:

PP> From my point of view,
PP> the Web has one fundamental universal feature and that is the URI. The
PP> question that faces us, in my opinion, is whether there should be
PP> alternate addresing models. For instance if I go to XMethods, I note
PP> that every web service there has its own addressing model.

PP> The ATM location database accepts zip codes and produces ATM locations.
PP> None of its ATM locations are universally addressable because they don't
PP> have URIs.

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> Kazoo accepts phone numbers and produces XML person records. None of its
PP> person records are universally addressable because they don't have URIs.

PP> GeoPinpoint accepts IP addresses and returns locations. None of its
PP> results are ...

Ditto for those. tel:+1-555-123-4567 and geoip:127.0.0.1 (just to add
an edge case).

PP> Now can anyone make a case that these applications are richer or better
PP> because they invented proprietary address spaces? Under what
PP> circumstances is a proprietary address space an advantage?

Its hard to justify, I agree. It doesn't get easier to justify by
giving them URIs, though. To really help, they have to be
dereferencable, otherwise they are mere syntactic fluff.

Although I agree that anonymous resources without URIs are a problem,
particularly for linking to them or into them. The results of
client-side XSL-T processing are a case in point.



-- 
 Chris                            mailto:chris@w3.org
Received on Monday, 18 March 2002 20:18:02 GMT

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