Richard Tobin a écrit :
The base URI for resolving a relative URI reference in an XML
document is the base URI of the element it appears in, and that (in
the absence of xml:base attributes) is the URI of the external or
document entity containing the element.
So if a document at
http://example.org/doc.xml uses an external
entity foo/bar.ent, then the base URI for relative URI references in
that entity is
http://example.org/foo/bar.ent. But if you parse
that document and write it out again as a single file, the entity
boundaries are lost. Inserting xml:base attributes *when you write
it out* is a way to preserve the meaning of relative URI references.
Of course I undestand the /utility/ of this xml:base attribute. But
I'm wondering if is not a violation of the /logic/ of the layered
nature of XML. With a xml:base attribute added on the sub-tree root
elements, a choice at the entity level constrains the semantic level.
One could even say that if you are interesting in the "/meaning/", as
you said, of the URI reference, you should not store this information
in the SYSTEM part of an entity declaration, since this mechanism is
for storing the document at the physical level, not for expressing
information at all. The division of the document into file is not
itself an "XML information", if I understand correctly the XML
infoset. I can imagine that there is good reason, in the XInclude
spec, for adding this xml:base element, since, for instance, this
XInclude is a mechanism defined at the vocabulary level ; but adding
this attribute to trees extracted by external entity seems break
compatibility.
Am I wrong with this idea?
I am unconvinced that it makes sense for the *parser* to insert the
xml:base attributes however; I would expect it instead to provide a
way to determine the base URI of an element taking into account the
entity boundaries.
I agree ; even the startEntity(String name) method in SAX does not
report the URI of the entity, I don't understand why: it prevents from
serialising the document as it where received (the same sub-trees in
the same file), and limit the "bidirectionality" of SAX as an API.