Re: [URN] [Fwd: "U stands for Uniform"]

David G. Durand (david@iris.dynamicdiagrams.com)
Wed, 21 Jan 1998 16:31:54 -0500


From: "David G. Durand" <david@iris.dynamicdiagrams.com>
Message-Id: <9801211631.ZM22887@iris.dynamicdiagrams.com>
Date: Wed, 21 Jan 1998 16:31:54 -0500
In-Reply-To: Larry Masinter <masinter@parc.xerox.com>
To: uri@Bunyip.Com, urn-ietf@Bunyip.Com
Subject: Re: [URN] [Fwd: "U stands for Uniform"]

On Jan 21, 11:37am, Larry Masinter wrote:
> Something is "appropriate" if it has a defined meaning. If it's not defined,
> then you shouldn't use it. If it is defined, then you can. Whether or not it
> is defined is not an issue for the syntax, it's an issue for the semantics.
> (We should take the word "semantics" out of the title of (b), since
> the body of (b) talks entirely about syntax. I am not proposing any
> other change to (b) than to change the title.)

This seems quite good. URIs must (practically speaking) have the current rules
for "/", "?", "#", etc. because those rules are already embedded in our
software and standards. This does not mean, as you point out, that _every_ URI
must use these features. It cannot use _those characters_ except in the ways
that they are already used.

>.....

> It's *important* that all URI processing software be assured that the URI
> processing software knows that it doesn't have to first look up the scheme
> before it does syntactic processing of "#", "?" and "/". We have to make
> it CLEAR that those syntactic elements are completely scheme independent,
> and the processing of them can be independent of whether the scheme is really
> "urn" which has different rules of semantics.

Right. URNs will be deployed much more readily if they fit in the same
syntactic slots where URLs do currently. This is more important than an "ideal"
syntax for URNs (which may look uglier when special characters need to be
eascaped).

> Hiding the distinction by having two documents, one of which doesn't even
> mention those elements would be WRONG.

Yes.

A good set of arguments as well. Let's not delay URNs just because unification
with URLs may give us syntactic options we can outlaw later.

And, as I said before, any URN that _can_ be resolved to an XML resource,
_should_ be usable with an XML fragment identifier. XLL (XML linking)
essentially depends on this. We even want to define the meaning of query
strings for XML documents, because we want to have a standard for server-side
fragment distribution.

Of course, some namespaces can't necessarily use any of these things. In
particular this is true for namespaces that aren't resolvable to data, like
many cataloging and metadata related URNs, e.g. for authors, artists, archival
sites, etc.

If a URN namespace definition doesn't define a meaning for features like
hierarchy and fragment-IDs, then they would only be legal if another standard
(with reason, presumably) did define such behaviour.

------------------------------------------+----------------------------
David Durand                 dgd@cs.bu.edu| david@dynamicDiagrams.com
Boston University Computer Science        | Dynamic Diagrams
http://www.cs.bu.edu/students/grads/dgd/  | http://dynamicDiagrams.com/
                                          | MAPA: mapping for the WWW