Re: A little courtesy, please

On Wed, 24 May 2000, John Cowan wrote:

> Jonathan Marsh wrote:
> 
> > To bring Namespaces into line with the expected handling of relative URIs
> > means that each document must have a base URI at all times, which is
> > currently not the case.
> 
> Most documents *do* have base URIs, unless they arrive at the parser using
> a raw TCP socket, or on the standard input, or something like that.
> Documents which don't have base URIs can't usefully contain relative
> URI references of any sort, not just relative namespace names.

In some domains, they all do, whereas in others, none do, and it is easy for
a fragment of a document living on a disk to quickly become part of a message 
across a socket in ecommerce.

The document URI is by no means the only meaningful base URI.  xml:base, as 
inadequate as it may be, is one of many possible ways of having alternate
base URIs.  There is much more context to a document than its current location.

The current location is probably a good base in some cases for related 
document-like content such as external entities.  But, please make a stronger 
case that it (or xml:base) is a good base for the identity of relative 
namespace references.  That is what was never in the namespace specification,
and cannot IMO be soundly implied.

> > Is making something as fundamental as element names context-sensitive a good
> > design?  I don't see how it could be, and David Carlisle has done a good job
> > of providing examples and scenarios of the dangers involved.
> 
> "Sharp tools cut."  Is it really a problem if something dangerous is allowed?

Broken things also cut you on their sharp edges.  If this sharp edge represented
the cutting edge of some great tool, and I could banish it from my environment,
when it wasn't right, I'd feel differently.  I suppose standard language could
be adopted throughout specs for "no relative namespace URIs allowed here".

> > So if we absolutize for the sake of URI consistency, we also have to forbid
> > relative URIs so that names are indepedent to changes of document location.
> 
> But if you happen to *want* names that are dependent on document location?

There is another important place where there is no real base URI.  When the
document is in memory, such as in DOM.  So we adopt the base URI of the 
most-recent source or target, and doing Save As or moving nodes in the 
hierarchy changes the identity of the nodes?

You can do nearly the same thing with entities, but in a controlled fashion.
You can create simple unique identifiers that will not collide, but where the
root is only explicitly changed.  Unlike relative URIs, entities are immutable
in a DOM, they don't change during Save As, and they apply globally throughout
the document instead of being specific to a location.

> > Of course, if we forbid, we no longer have to absolutize.  Absolutization
> > and forbidding amount to essentially the same thing.
> 
> A fundamental difference is that absolutizing is a "quiet change", whereas
> forbidding is noisy: existing documents get orphaned, as opposed to
> existing systems starting to malfunction in unexpected ways.

I do not see absolutizing as quiet.  It causes lots of ambiguity about at
what point a name is relative, at what point it is absolute, and with respect
to what base, and can cause huge instability with nodes adopted from any 
source which one does not control.  At every point, you have to worry
whether moving the xml into a new location will break it.  Or you ignore 
them and break everyone who tries to use them.

Ray Whitmer
ray@xmission.com

Received on Wednesday, 24 May 2000 18:15:18 UTC