Re: A new proposal (was: Re: which layer for URI processing?)

On Thu, 25 May 2000, John Cowan wrote:

> Jonathan Borden wrote:
> 
> > Is there a class of problems caused by relative URIs that isn't also caused
> > by un-normalized URIs?
> 
> Yes!  The fact that two apparently distinct absolute URIs (e.g.
> "http://one.example.com/foo" and "http://two.example.com/foo") refer to the same
> thing is a very different problem from the fact that apparently identical
> relative URI references (e.g. "foo" in doc1 and "foo" in doc2) refer to
> different things.
> 
> Nothing but confusion is gained by mixing up these issues.
> 

The two may easily be related, because if namespaces rely on the default document
location for a base of resolution, who knows where or how that will be produced
by different parts of the system, which doesn't much care as long as the
particular form retrieves the right file.

Control is lost over keeping a single representation of a namespace name that 
will match as soon as you use relative specifications and allow random effects
to bleed in from every-which way.

Let's say I double click on a file to view it, then I look it up in a catalog, and
then I get the name out of an xlink.  I may get the same filename in several 
different forms, that may or may not match the way the file name or related 
filenames are delivered in other parts of the system.  The proposal directly 
links element types into this sort of instability -- who knows if it can even be 
referred to by a URL, let alone being consistent between different equivalent 
filenames.

As far as the system is concerned, the names ARE equivalent, which it can prove,
so what does it care that the names are not identical when activated, potentially 
into the same space, using quite different mechanisms.  The intent of a system
filename is not identity.  It has other ways of establishing identity.

Ray Whitmer
ray@xmission.com

Received on Thursday, 25 May 2000 16:32:50 UTC