* David Powell <[EMAIL PROTECTED]> [2005-07-19 08:25]: > Why does xml:base allow for relative base URIs and stacking > then? If xml:base can only describe the actual source URI of > the document, then these features don't make sense.
Indeed, they don’t. > The example in the xml:base spec [1] uses a relative URI in the > <olist xml:base="/hotpicks/"> element, after defining an > absolute URI in <doc xml:base="http://example.org/today/";> at > the top of the document. > > [1] http://www.w3.org/TR/xmlbase/#syntax That example says: the content of the root element can be found in the resource at <http://example.org/today/>, and the content of the olist tag can be found in the resource at <http://example.org/hotpicks/>. xml:base is quite apparently being used as “a prefix for calculating relative URIs” instead of “the source URI for the material found inside this tag.” It makes me wonder whether the person who wrote the example was unaware of the consequences of the same-document reference specifications in the URI RFC. Surely, the xml:base WG must have noticed this issue and discussed it? > If xml:base can only describe the source URI, then one of them > must be lying? xml:base provides a mechanism to describe the base URI of any part of an XML document. If you copy bits from another document and don’t want to munge contained URI references, then you will need to set an xml:base on the copied container element for these copied bits. Notice that xml:base describes **a base URI**. The xml:base TR does not define what a base URI is. It’s RFC3986 (and originally, RFC2396) which does, while describing just what an URI is, to begin with. The same-document reference stanza in the URI RFCs is clear evidence that in the spirit of the spec, “base URI” means “the source URI of the content,” not “the prefix I wish to apply to relative references.” Now, xml:base appears to try to address the situation where an aggregate document may contain fragments from many sources, and each of which thus has its own base URI. But the devilish detail is that RFC-specified behaviour means that if a useragent were to find a link to <http://example.org/today/> somewhere inside the example document except inside the olist tag, or a link to <http://example.org/hotpicks/> inside the olist tag, it may not retrieve that URL – instead it would have to consider the XML document itself to be the document found at the respective URL. This is what RFC3986 says. The xml:base TR contains no language that would contradict, or even enforce, or in fact at all address this point. We therefore have to go by the behaviour specified in RFC3986 when we determine how a user agent resolves URIs. At first, I thought the RFC-specified same-document reference stanza made no sense. But then I realized it is perfectly fine and absolutely desirable for the case where the “base URI embedded in content” applies to the entire document. It is the xml:base TR which is at odds with this; applying same-document reference behaviour to fragments of an aggregate document is non-sensical. The more I think about it, the more it seems like this interaction is Broken As Designed. xml:base should not have adopted the “base URI” term – basically, it appears that the very attribute name itself is a misnomer. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
