Paul has volunteered (was Re: Overloaded URIs must GO!)

Didier PH Martin martind at
Mon May 31 18:37:08 BST 1999

Hi Jonathan,

Jonathan said:
	Aside from the evident fact that such practice goes against several
individial's internal sense of what is 'right' or 'wrong', this is the only
criticism I see of this practice. No one has offered a hard or practical
example of an actual problem this creates, aside from offending of the

Didier says:
Yes an other argument: location dependency. Let's say that in a near future
we want to use the URI to point to a "place" where the name space is
documented. Then

a) URL:
PRO:Already here, people are accustomed to it. Especially the URL based on
HTTP protocol. CON: It is location dependent. If the document is moved to an
other "place" we have to change the URL. All documents in the field pointing
to this URL are out of synch. we, reduced the document longevity.

b) URN:
PRO: it is location dependant. We can move the document to a new "place" and
the document is still in synch. We gained document longevity. CON:
necessitate a name resolver. The interpreter needs to include the name
resolution mechanism. Not well known from the Web community.

Argument I heard about not using URN. It is not there yet. Then what would
we say if we where hearing the argument against XML as "not there yet" :-))

The point is: if we need a URI, then let's use a URN then when we'll need
the URN to be resolved for a location, implementers could include a name
resolver in their code. What we gain, documentation could be "moved" and all
documents in the field having a reference to the URN are still valid. But
_cannot_ be the case for a URL.

If however we only need a URI that _will_ never be resolved into a location
then we can use anything that lower the probability of name collision.

Didier PH Martin
mailto:martind at

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

More information about the Xml-dev mailing list