OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: URI's in namespaces

[ Lists Home | Date Index | Thread Index ]
  • From: Paul Prescod <paul@prescod.net>
  • To: "'XML Dev'" <xml-dev@ic.ac.uk>
  • Date: Thu, 25 Nov 1999 16:46:01 +0100

"Jeffrey E. Sussna" wrote:
> Not to rouse the fitfully sleeping namespace beast, but I can't get it out
> of my mind. In particular, I have a dumb question:
> If the namespace facility designers were adamant that a namespace identifier
> doesn't necessarily point to any actual schema, then why did they use URI's
> as namespace "targets". The whole notion of URI implies that there's
> something (i.e., the resource) out there. But a namespace is not inherently
> a pointer (regardless of whether you can access the thing pointed to). Why
> not just make namespace targets ordinary XML names?

There is a reason. I claim it is not a good enough reason, but there is
a reason nevertheless.

 * in order to globally differentiate names we need a globally managed
 * we could use phone numbers, but they aren't very "Internet friendly"
 * the next obvious choice is domain names
 * the problem is that in a domain the size of ibm.com (or aol.com!!),
you could still have clashing names
 * but AOL already has an infrastructure for managing its URI namespace
 * so if we use URIs, we can build on that infrastructure

I feel that there is an intrinsic flaw in this whole argument.

The reason we traditionally manage our URI namespace is because we want
to manage the description of retrievable resources. Therefore, if we USE
our pre-existing URI infrastructures then we will always come up with
URIs that look suspiciously (and confusingly) like URLs. They will
always be based on domain names and we know that domain names change

If we DO NOT use these infrastructures, then we can come up with more
persistent, less confusing namespaces, but then we've lost the whole
benefit of using URIs! For instance, there is no reason that we should
use http://www.w3.org/1999/XSL/Transform instead of the less confusing
www.w3.org.1999.xsl.transform since neither one really follows the W3Cs
website structure ANYHOW.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Like most religious texts, the XML 1.0 spec has proven itself 
internally-inconsistent, so we're going to have to invent some kind of 
exegetical method now to show how it's really all an allegory." - Anon

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS