href="foo"

  Just like
  	<a href="foo">...</a>
  shows different target URIs at the bottom of your browser
  window, depending on the base URI of the document where
  your browser found it.

Actually my browser doesn't do that, but I know what you mean.

but that expansion of the relative URI is not done by the parser (XML
or SGML) it is done just when (if) the system needs to detect which
resource is being referred to.

The literal interpretation takes the same approach with namespace
names. The parser doesn't expand the relative URI, but when (if)
some process does require to dereference the namespace name as a URI
then of course the base is taken into account at that point.

The namespace mechanism needed a way of allocating unique names.
Taking the URI of some resource was just taken as a mechanism to
obtain those names. Using that as an excuse to produce an
entirely new type of XML document whose effective names depend on
context is totally unacceptable (and such documents would be
essentially unusable and a source of confusion for ever).

Given that XML spec makes explicit that the document entity being
parsed need not have any name at all, and that it is so perfectly
reasonable to make parsing part of a pipe of other in memory
operation, or to download an XML file to a local disk before
processing it, having element names depend on context is just
completely unacceptable thus while forbid option looks rather like a
compromise for a committee, it or the fixed base option, are the only
possible alternatives so far suggested if the (preferable) literal
option is rejected for some (as yet unexplained) reason.

David

Received on Wednesday, 7 June 2000 18:05:24 UTC