Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XInclusion produdes invalid document

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Andrew Thompson <lordpixel AT mac.com>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XInclusion produdes invalid document
  • Date: Sun, 6 Mar 2005 19:59:53 -0500


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 ...)





Archive powered by MHonArc 2.6.24.

Top of Page