Relative URL references such as sark.jpg,
../pi1/sark.jpg, and
turing/pi1/sark.jpg must be resolved relative to
an absolute base URI before being retrieved. When relative URLs are
found in XLinks, xml-stylesheet
processing instructions, system identifiers, and other locations in
XML documents, they are normally resolved relative to the absolute
base URL of the document or entity that contains them. For instance,
if you find the element <image
xlink:type="simple"
xlink:href="pi1/sark.jpg" /> in a document at the URL http://www.turing.org.uk/turing/index.html, you would
expect to find the file sark.jpg at the URL
http://www.turing.org.uk/turing/p1/sark.jpg.
This isn't a surprise. It's pretty much how links have worked in HTML
for over a decade.
However, XML does add a couple of new wrinkles to this procedure. First, an XML document may be composed of multiple entities loaded from multiple different URLs, even on different servers. If this is the case, then a relative URL is resolved relative to the base URL of the specific entity in which it appears, not the base URL of the entire document.
Secondly, the base URL may be reset or changed from within the
document by using xml:base
attributes. Such an attribute may appear on the XLink element itself
or on any ancestor element in the same entity. For example, this XLink
points to ftp://ftp.knowtion.net/pub/mirrors/gutenberg/etext93/wizoz10.txt:
<novel xmlns:xlink = "http://www.w3.org/1999/xlink"
xml:base="ftp://ftp.knowtion.net/pub/mirrors/gutenberg/etext93/"
xlink:type = "simple"
xlink:href = "wizoz10.txt">
<title>The Wonderful Wizard of Oz</title>
<author>L. Frank Baum</author>
<year>1900</year>
</novel>So does this one:
<novel xmlns:xlink = "http://www.w3.org/1999/xlink"
xml:base="ftp://ftp.knowtion.net/"
xlink:type = "simple"
xlink:href = "/pub/mirrors/gutenberg/etext93/wizoz10.txt">
<title>The Wonderful Wizard of Oz</title>
<author>L. Frank Baum</author>
<year>1900</year>
</novel>And this one does too:
<series xml:base="ftp://ftp.knowtion.net/">
<title>Oz Books</title>
<author>L. Frank Baum</author>
<novel xmlns:xlink = "http://www.w3.org/1999/xlink"
xlink:type = "simple"
xlink:href = "/pub/mirrors/gutenberg/etext93/">
<title>The Wonderful Wizard of Oz</title>
<year>1900</year>
</novel>
...
</series>All of these link to the URL ftp://ftp.knowtion.net/pub/mirrors/gutenberg/etext93/wizoz10.txt
regardless of where the document containing the XLink actually came
from. The base URL is taken from the nearest xml:base attribute in the same entity, in
preference to the base URL of the entity that contains the
element.
xml:base attributes can
themselves contain relative URLs. In this case, the base URL is formed
by resolving this relative URL against the base URL specified by
xml:base attributes higher up in
the tree and/or the base URL of the entity that contains the element.
For example, resolving the URLs in the xlink:href attributes in this authors element requires applying the URLs
in three separate ancestor elements:
<authors xml:base="http://www.literature.org/authors/"
xmlns:xlink = "http://www.w3.org/1999/xlink">
<author xml:base="baum-l-frank/">
<name>L. Frank Baum</name>
<novel xml:base = "the-wonderful-wizard-of-oz/">
<title>The Wonderful Wizard of Oz</title>
<year>1900</year>
<chapter xlink:type="simple"
xlink:href="introduction.html">Introduction</chapter>
<chapter xlink:type="simple"
xlink:href="chapter-01.html">The Cyclone</chapter>
<chapter xlink:type="simple"
xlink:href="chapter-02.html">The Council with the
Munchkins</chapter>
...
</novel>
</author>
</authors>What if the top element has a relative base URL or no xml:base attribute? Then you apply the
absolute base URL of the entity that contains the root element. In
theory, this entity should always have an absolute base URL against
which relative URLs can be resolved as a last resort. After all the
entity had to come from somewhere, right? Unfortunately, there are
some corner cases where this isn't true. In particular many APIs lose
track of the base URLs or create documents in memory without any base
URLs, so full resolution isn't always possible. The relevant
specifications are not perfectly clear on what happens here, though
one possible interpretation is to simply declare that the base URI is
the empty string. The URI specification defines this to mean the URI
of the current document, whatever it is. However, in the common case
where a document is read from an actual file or URL, it should always
be possible to calculate an absolute base URL for every
element.
There's one point we've made a couple of times, but it's worth
calling out because it's not obvious and quite tricky. All base URL
resolutions are performed within the scope of a single entity, not a
single document. If a document is built from multiple entities, then
it's the base URI of the entity that matters, not the base URI of the
document. Furthermore, xml:base
attributes only have scope within the entity from which they come.
They do not apply in any other entities. That is, if entity A includes
entity B, no xml:base attributes in
entity A will be used to resolve relative URLs in entity B. If the
base URL cannot be fully resolved using xml:base attributes from entity B, then the
final absolute URL is the URL from which entity B was loaded. xml:base attributes in ancestor elements
from different entities are not considered.
Although we've emphasized the application of xml:base attributes to xlink:href attributes in this section, they
also apply in many other contexts. For instance, they're used in
XInclude and XHTML 2.0. However, xml:base is a relative latecomer to the XML
table, so it's not universally applicable. For instance, XHTML 1.0 and
1.1 do not consider xml:base
attributes when resolving relative URLs in a and img
elements. Instead they use the traditional base element in the document's head.