W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

Persistent caches - was: Are *relative* URIs as namespace nemes considered harmful?

From: Tim Berners-Lee <timbl@w3.org>
Date: Wed, 17 May 2000 18:57:56 -0400
Message-ID: <00dd01bfc093$46e93f80$b0ec5c8b@ridge.w3.org>
To: "Pawson, David" <DPawson@rnib.org.uk>, <xml-uri@w3.org>
Abstract: A rant about names, addresses and fpis, followed by agreement with
David P
about the actual way to make this work in real software.

-----Original Message-----
From: Pawson, David <DPawson@rnib.org.uk>
To: xml-uri@w3.org <xml-uri@w3.org>
Date: Wednesday, May 17, 2000 3:16 AM
Subject: RE: Are *relative* URIs as namespace nemes considered harmful?


>>Note that I'm not arguing for any solution at this point, just
>>trying to
>>clear away the underbrush.  This for two reasons: a) almost
>>everybody has
>>an entrenched position here, and b) I'm the point man for the problem,
>>qua editor of the Infoset, which is the primary place where
>>the eventual
>>decision will get expressed.
>
>Borrowing from Norm Walsh, the debate seems to centre on
>names and addresses, [1].

<rant>Norm's first reference is to my rant [2] about the illusion involved
in
naively dividing identifiers into "names" and "addresses".
His paper suggests taking the XML community from the state of
having a global namespace with an international body managing
its delegation hierarchy and a set of time-tested protocols to manage
its distributed catalog service to a state which Internet folks will
recognize as the "/etc/hosts" level of civilization.  (When the
Internet was very young, my best beloved, then there were not very many
nodes on it.
They had names and numbers and unix machines had a file called /etc/hosts
which contained a list to convert from names to addresses. The problem of
maintaining this file led to the creation of the  Domain Name System.  Now
you can relive the early days with  catalog files to map between the names
and addresses of your favorite things).  In fact of course the catalog file
format
could be used for mapping from the definitive (http: or uuid etc)  URIs for
your favorite resources to the ones on your local disk.
But Norm prefers using that non-URI namespace, the FPI. Because why use a
great big deployed system when you
only have a little problem?.... </rant>
[2] http://www.w3.org/DesignIssues/NameMyths

FPIs are not in the universal information space of the web.  This means they
are not as powerful.
They cannot be used in so many ways. If the social conditions (control,
persistence) are things
this community really likes, then it would be quite simple to define a URI
scheme fpi: which
would fix this.  That could easily become a W3C activity - so long as they
could be justified
as giving something which existing URI schemes don't.

>If names are intended, then the string
>value of an absolute uri is sufficient (ignoring the uniqueness debate).
>If addresses are required, then a local resolution via a catalog would
>suffice to convert the name into an address. A global solution
>would then be available via the web without the catalog usage.


Yes. This is true.   Many of the people I talk to assume this is the case.
Some browsers keep such a catalog already, with actual local filenames
completely hidden from the user.  I would recommend this solution for
XML software in general.

Making a generic API for this would be a useful technique.
(An XML file format for the persistent cache directory -- catalog --
would of course be useful). You can do this with a proxy.
I have the messages from this achieve currently available
to my machine and I am offline.  There is a catalog file somewhere.
(I strongly recommend that the user interface for such a thing allows
users to chose the level of persistence and availability they want for
a given resource, but not have to worry about the filename under which
is kept on the local machine.)

Tim BL

>Regards, DaveP
>
>
>
>
>
>[1]
>http://www.arbortext.com/Think_Tank/Norm_s_Column/issue_three/issue_three.h
t
>ml
>
Received on Thursday, 18 May 2000 02:33:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:42 UTC