Re: issue with relative URIs in the DOM

Shouldn't xml:base just trackl what the Infoset already does with base
URIs? A  base URI, however it's asserted, is inherited downward until a new
one is asserted. Whether that assertion reflects physical division of data
(entity) or logical (xml:base), it's still  a single value and a single
behavior.

At least, that's what I would expect to see.

Note that the Infoset and DOM have to agree upon whether base URIs are
early-binding or late-binding. This doesn't matter for a static parse; it
does matter if the Infoset is edited. Namespaces were deemed to be
early-binding; once a node's identity is set it may not be reset, and the
NS URI is considered part of that identity. The primary justification for
that decision -- that DOMs may subclass nodes based on the namespace they
belong to -- doesn't interact with base URI _UNLESS_ someone takes the
relative-namespace-declaration monstrosity back off the table.

The base URI of a synthetic document is an open question. Infoset says it's
a peripheral property avainable "if known", but doesn't say how to
determine whether it's known. I suspect the DOM would want to say that this
is a write-once property (ie, you can assert it once during document
initialization but never change it thereafter), and that it defaults to
null so we can recognize unknown as a distinct case.

> If you ran a document with external entities through an XSLT
> processor with even a simple copy transform, the resulting document would
> have lost all the entity boundaries.

That's as expected. If you run XSLT you're generating a new document based
on data retreived from the source material. There's no particular reason
the new doc _should_ retain its source context, unless you explicitly
create xml:base declarations to assert that context.(Wasn't being able to
do so when necessary one of the motivations behind xml:base's creation?)