XOM API for Processing XML with Java

[Andrew Thompson <lordpixel AT mac.com>]

On Mar 6, 2005, at 6:25 PM, Elliotte Harold wrote:

> Au contraire. They really do need to be relative to the original 
> document. For instance, let's suppose I have this element:
>
> <xi:include href="http://www.cafeaulait.org/"; />
>
> That document includes a lot of relative URLs that point at other 
> documents on http://www.cafeaulait.org/. Including it on 
> http://www.example.org/ where those documents do not exist should not 
> break the links.  The goal is that a relative URL not change what it 
> points to just because an element is included.

But doesn't that presuppose the original document only has one 
interesting URI?

Sometimes my document might be at

http://pixel.recoil.org/index.html

sometimes it might be at:

http://staging-server.local/index.html

and sometimes

file:///My Desktop/staging/index.html

and sometimes

file:///My Laptop/web bits/index.html

Working the way they've defined it, the xml:base on any included 
fragment will end up being an absolute URI indicating where the 
fragment.xml document happened to be when you ran the xinclude (ie, 
xml:base="file:///My Desktop/staging/fragment.html"). Or it can become 
a relative URI (xml:base="fragment.xml"), but then it may end up naming 
the document fragment which the end user of the merged file will not 
even have.

Personally I'd not expected the end result of running an XInclude to 
depend on where the files happened to be when I invoked the executable.

I'm not denying there are plenty of cases where you do need to add an 
xml:base - I can think of some myself.
I'm just saying they should have allowed a mode where the end document 
is independent of its constituent parts.

In my case all of the relative documents will be copied up to the web 
server as a part of the deployment process.
In the sort of application I'm describing this has to be a given. 
Sticking xml:base="file:///My Laptop/web bits/fragment.xml" into the 
element certainly won't make those relative URIs in the fragment work! 
Quite the opposite, if a web browser were to actually pay attention to 
it, the relative links in that part of the document would fail because 
they'd be looking for file:///.

I could put an xml:base on the index.html: 
'xml:base="http://pixel.recoil.org/";'. However that's not right either 
because it would mean I can't test my site from my local hard disk or 
from http://staging-server.local/

Basically what this tells us is they did not assume a preprocessing 
model. The assumption is the web server or the browser will fetch the 
included parts as it serves or fetches the document. If that's the only 
supported model, then it works fine, but it doesn't work if what you 
want to do is resolve all your includes up front then deploy the 
result.

AndyT (lordpixel - the cat who walks through walls)
A little bigger on the inside

        (see you later space cowboy ...)