Re: Problems I cannot get past with using relative URIs for identity.

-----Original Message-----
From: Ray Whitmer <>
To: <>
Date: Wednesday, May 17, 2000 6:08 PM
Subject: Problems I cannot get past with using relative URIs for identity.

>Some of the problems I can't get past with absolutizing namespace names,
>lead me to believe that it would undermine namespaces significantly:
>1.  The specification for URIs was designed for content retrieval,
>on legacy file systems, not for type identity.

Excuse me,  URIs were originally designed to identify -- the term
"Identifier" is used
for a reason. The actual properties of persitence and idenmtity are, for the
HTTP space,
the choice of the publisher, which has provided a lot of flexibility.

Remember there are also URI schemes such as uuid: and md5: which have very
different properties!

HTTP URIs should be thought of as names for which there is a widely deployed
distributed catalog system.  I rant continually at sites which change their
and point out that W3C has a space of HTTP URIs which are not changed.

> Hence, most of the real
>equivalence of URIs that people rely on is computed on the server, not on

For "computed on the server" read: defined by the publisher. This applies to
HTTP and FTP only.

> Since the primary function of URIs is to retrieve content,

This is your rhetoric.  Retreival is useful but identity is important too.
many schemes such as uuid: and mid: identify primarily and any URI-based
is added on afterward.

>retrieval functions usually never bother to ask about the identity of
>accessed by a URI.

There is in fact alot of HTTP aparatus to relate the different URIs which
are conected
and to talk about persistence, for cache control for example.

>The server just returns the proper content.  Hence, the
>spec only had to do simple enough concatenation for absolutization to allow
>the server to do the context-specific work of real resolution of the URI to
>specific resource.

To resolve the abstarct resource to a suitable HTTP entity as the HTTP
terminolgy goes.

>Namespace names are not primarily about retrieving resources, but rather
>identifying a namespace.  In this case, the simple absolutization rules
>possibly establish identity of namespaces, which users consider identical,
>if the spec did not need to fully absolutize them.

>For example, from a user's point of view, and probably most developers as
> with a relative reference to
>../fifth/sixth/seventh.html is the same as a reference to

You mean

> In this case, to use the argument of
>the day, the relative reference is a legal URI, but the RFC would resolve
>I suspect, as,
>is not at all the same identity.

You suspect wrong.

I don't know why you should think that users understood practice and the RFC
should be different.
The RFC defines how things actually work which is what users are all used to
(and happens to basically match algoirthms used in unix for decades).

>I think it would be improper for a
>theoretical modified namespace spec which dictated absolutization of
>URI references to mandate that these be treated as distinct names, when the
>server is allowed and expected by all to return the same resource.  If
>are, indeed references, then the server should be permitted to have the
>say on identity.
>Otherwise, we are not talking about absolutization, but only partial
>absolutization, which is a different interpretation of the URI from what
>happens when the URI is used to retrieve content, and is IMO bound to seem
>confusing and arbitrary to users.

I assume this idea of "partial absolutization" is based on the misconception
above. There is no such thing defined. There is only absolutization.

>2.  The flexibility of URIs does not seem to extend to absolutization.
>RFC-specified absolutization favors legacy unix file path syntax, throwing
>away CGI parameters, for example.  There should be different absolutization
>alternative protocols.

Absolutely not!  It is essential that the asolutization canbe done as a
simple string function without any knowledge of any specific schemes.

> With full absolutization required for any real identity
>matching, it mandates even more that the server be involved in any
>absolutization for identity purposes so it can handle different types of
>it knows about.

You are using the term absoluization in a manner different from the way it
has been used on this list.  I have seen no one argue for involving the
server in the processes. Many URI schemes don't have a concept of a server.

>3.  What is the meaning of an absolutized relative namespace name in
>or more concretely in DOM?  Is it the relative name, or is it the absolute
>name?  It cannot be both simultaneously.

On the contrary, very often systems aloow separate access to the actual
attribute value
and to the interpreted object.  xHTML editors typically preserve the choice
of relative or absolute URI used in a A HREF, but adjust the value when a
copy of the document is saved to a new URI.  I would suggest that this
behaviour be the norm.

> What is preserved when nodes are
>moved within the hierarchy -- the absolutized concept of type that is so
>important for specialized DOM implementations, or the relative info?   You
>could choose:

You are talking about an XML node moving within the DOM tree?
Or a document being moved through URI space?
In all cases the absolute URI should be presrved.  To preserve the choice of
relative URI or absolute URI is important in practice too.
I am hoping that the same code is going to be used for all URIs of course.

>a.  The DOM parser absolutizes and DOM effectively does not permit relative
>URIs, except as convenience.
>b.  Relative?  Do we really intend to have the validation rules and
>implementing classes change as a node moves in the hierarchy to another or
>they are saved in a different location?  It is very common to tie the
>implementing class and validation rules to the type.  Type will now be in
>flux, whereas DOM has traditionally considered the type constant for these
>reasons?  Are you willing to frequently re-absolutize the name so it can be
>c.  Absolute(ized): with relative preserved?  How is the relative path
>preserved in the nodes?  The relative specifier would be at best like the
>prefix which is considered syntactic sugar, which may be replaced by the
>serializer.  In this case, a serialized document would likely lose the
>nature of namespaces, so the relative properties of the namespace
>specifications could not be relied on for essential functionality (just
>a document becomes invalid according to DTDs when saved in canonical form).
>All the problems of prefixes arize again for relative URIs, for example an
>entity needs to know the base URI of the position in which it is
>or an absolutized URI can not be cmputed, which may be different in
>references, so entity hierarchies would have no absolutized URIs.  Do we
>want this additional complexity on namespaces?
>If so, perhaps another group should make a different naming standard for
>who just want namespaces, which could look like Java packages so no one
gets so
>confused to marry an arbitrary resource to the type declaration.

Please, if a server returns something when queried for the namespace
then that is now an arbitrary resource. The server is controlled by the
owner of the
name and the document returned is therefore definitive. It is not arbirary.

To use java class names I say what I said about FPIs.  If you really think
they solve problems
other URI schemes don't solve, then you can propose that they be a new URI
Then all new designes will be able to take advantage of them.

>5.  Once you have convinced everyone that namespaces should access
>how do you get consensus about what the function of the resource should be?

The function of the resource is to express information about the namespace.
This may involve amixture of languages some of which we have now and some we
invent as the technology evolves.

>And what do you do when multiple purposes conflict?

What multiple purposes, and can you give an example of conflict?

>That is the point of
>separation between syntax and semantics in the first place.

Oh, you mean that one schema document should not contain syntax-related and
semantic information?  That doesn't seem to be a problem to me.
Specification douments do.  Of course
one could separate them and refe to one from the other.

>  Data needs to be

I don't understad that remark in this context now the following pararaph.

> If I were doing this, I would get the same functionality from a
>separate PI, and not destroy the abstractness / generality of the data.
>you go mangling types to point to resources, it is hard to undo the damage,
>6.  It seems unnatural to tie typing information to default path of a part
of a
>hierarchy.  If I needed this type of relative typing, I would want to
>types to other types, not necessarily to where the user stuck a collection
>graphics files.  Relative of types can apparently already be accomplished
>using entities, which permits the architect to structure the relationships
>rather than forcing them to flow down the hierarchy with the default
>of, for example, graphics files.
>7.  I can count several times already that someone in a development or
>standards group has suggested using a URI as an identifier since this issue
>arose.  In the cases I have seen, people are now running screaming from
>URIs for anything besides a real retrieval pointer, having seen the baggage
>that brings with it if someone might want to relativize them in some
>fashion as is being done with namespaces.  I do not think this (IMO) bad
>practice of using relative URIs promotes the cause of URIs at all, and I
>recent repeated experiences to convince me of that.

Could you plese indicate the standards groups which have run screaming from

I would point out that the web is humming with relative URIs which lend
managability to huge amounts of the data.  Our own website would be
very much more difficult to manage without them.

>Ray Whitmer

Received on Thursday, 18 May 2000 18:37:03 UTC