Just require URLs

[W. Eliot Kimber]

Didier PH Martin wrote:

> interpretable documents.
> c) If we choose to use a URL for a name space identifier, we create location
> dependency to our documents, If we choose URNs, the documents are then
> location independent. Again, with some forward thinking, the name space

I would like to remind everyone that URLs are no more or less fragile or
"location
dependent" than URNs are. Both can be equally indirect.  This is same as
the bogus PUBLIC/SYSTEM distinction SGML makes: a pointer to a thing is
a pointer to a thing, and the degree of indirection you expect to have
behind it is both unknowable and irrelevant to the use of the pointer.
Adding indirection within the data representation mechanism (e.g.,
entity resolution in SGML, URN resolution on the Web) may be convenient,
but it is not a necessary prerequisite for having managable or
persistent names.  Persistence accrues from having persistent name
servers, which any HTTP server can be, given that there are any number
of ways to do indirect URI resolution within a server.  Therefore the
use or non-use of URNs is a technology choice to be made by resource
owners and should not be a policy requirement imposed by standards. 
[For this reason, XML is *wrong* to require that notations use public
IDs and not use system IDs, for example.]

The only thing you know about URNs is that they will always involve one
more level of indirection than the most direct URL. But the reverse is
not true.  That is, any URL could be just as indirect as any URN, and
therefore, just as robust.

Arguing about which form of name to use is a waste of time, because
what's important isn't the name but the thing at the other end of it.

What *is* important is the infrastructure in place for managing the
indirection you need to make the names you control managable. But this
issue is orthoganal to the URL/URN issue.

One of the things that the Topic Map discussion should have made clear
is that the idea of an "abstract thing" is bogus--there are only things.
You either have only the name for the thing, in which case the name *is*
the thing (because it's the only physical thing you've got) or you have
the thing itself (the physical storage object the URI resolves to).   

In other words, if you identify a namespace with a URI which cannot be
resolved to a resource (because no-one has defined the mapping from the
URI to some physical object), then the URI *is* the namespace.  That is,
the character string that constitutes the URI is the physical (and
therefore identifiable) resource that constitutes the namespace.
Fortunately, the physical manifestation of a namespace is undefined, so
any physical object will do to establish its identity, including a URI. 
If the URI can be resolved to a resource, then that resource establishes
the identity of the namespace.  It doesn't matter what the spelling of
the URI is, only that it exists.

Note that because there is no normative definition of what the
definition of a namespace is (in the way, for example, that a DTD is
normatively defined by the declarations in the DOCTYPE declaration or an
SGML architecture is defined by its documentation and meta-DTD), all we
can hope to get from the namespace declaration is establishment of
identity of name spaces.  That is, given two documents that both declare
the use of a namespace, do they use the same or different name spaces? 
Since the same object can be addressed by many pointers, I would
normally expect to get an object from each pointer and then see if I've
gotten the same object [Note that it is up to the storage managers for
the objects to determine and report identity--but that's inherent in the
way computers work--since we cannot physically see and touch storage
objects in most forms of media, we are dependent on the storage managers
to tell us what we need to know.]  If I can't resolve the pointer, then
all I have is the pointer itself.

If the true intent of the namespace mechanism is that the URI *is* the
namespace (in the sense defined above), then they have to *disallow*
resolution of the URI, otherwise, you cannot reliably establish
namespace identity because two different URIs could identify the same
resource. If the only objects you have are the URIs, then you know that
if two URIs are different that you have two different name spaces
(because the namespace objects, the URIs, are different).  If namespace
URIs can be resolved, then if you have two URIs, one of which you can
resolve to a resource and one of which you cannot, you cannot know
whether the two namespaces are the same or different because identity of
the one whose URI you couldn't resolve has yet to be established (URIs
cannot by themselves establish the identity of the resources they
address).

If you want to have namespaces for which the *only* physical
manifestation is the URI of the namespace, then there must be defined a
URN domain in which the URNs are their own resources.  It is not enough
to simply say "namespace URNs are not to be resolved", because the
namespace spec doesn't have the authority to disallow the resolution of
URNs.

Besides, it's bogus to have namespaces that are not documented in some
way, even if the namespace spec doesn't require it.  Without some
authoritative definition of the namespace, how can I know whether or not
I'm using it correctly. Therefore, there must *always* be some resource
for the name space and it is the responsibility of the namespace owner
to make that resource reliably addressible within its expected scope of
use. 

Cheers,

E.

-- 
<address HyTime="bibloc">
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.  eliot at isogen.com
2200 N. Lamar St, #230, Dallas, TX 75202
512.339.1400, www.isogen.com
</address>


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)