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

Re: [XOM-interest] XInclusion produdes invalid document

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

On Mar 6, 2005, at 3:45 PM, Elliotte Harold wrote:

Andrew Thompson wrote:


* the div has picked up an xmlns="" which makes it fail w3 validation. This is a Xerces bug, I think... because I've seen it when using XSLT before

That's weird. It's probably something that's required in your case due to things you haven't told us, but it might be my bug. Hard to tell without seeing the full example. I'd be surprised if it were a Xerces bug though.

It's been happening to me a lot with DocBook. I filed a bug report with the developers of the DocBook XSLT stylesheets, and some of them could reproduce it, but Norman Walsh himself could not. So it's not just my system, but it is something quite subtle.

So I boiled this down to a test case:

Here's the include file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
<html xmlns="http://www.w3.org/1999/xhtml";
xmlns:xi="http://www.w3.org/2001/XInclude";
xml:lang="en" lang="en">
<head>
<title>Hello world</title>
</head>
<body>
<p>foo</p>
<xi:include href="navbar.xml"/>
</body>
</html>

Here's what it includes (navbar.xml):

<p id="navbar" class="">
<a href="/index.php" title="My Homepage">Home</a> |
<a href="/code/index.php" title="Code I've written">Code</a> |
<a href="/photos/index.php" title="Pictures of people I know and places I've been">Photos</a> |
<a href="http://www.mozilla.org/";>Mozilla</a> |
<a href="http://diary.recoil.org/pixel/";>Diary</a></p>

If that's not enough context I can always zip everything up at this end and send it to you.

I'm now using the Xerces bundled with Xalan 2_6_0 and it's still happening.
At least I _THINK_ it's using that Xerces version. Is there an easy way to get XOM to tell me which parser it found?
I ran it with java -verbose:class, but that only tells me that it is loading Xerces, not which JARs it's loading Xerces from...

* The killer is this xml:base="file:///path/on/my/local/harddisk/website%20bits/ sidebar.xml"
EHR, I notice you didn't mention this in your article @ http://cafe.elharo.com/xml/xinclude/ but from a quick read of the XInclude spec this seems to be expected (XInclude spec, section 4.5.5).

That's correct. It is expected. XOM is allowed to compute relative URIs instead. So far I don't implement that, and it's not exactly clear what that would mean if I did. (I could do it if the parent element had an xml:base attribute that contained an absolute URI, but if the document is simply written out to an arbitrary location, the only way to get the base URI right is to write an absolute URI).

I see what you mean. And yet it seems that in trying to fix the complex case they've made the simplest case too hard.
I mean, here's my workflow, if I'm honest:

1. I have a bunch of HTML documents that have a lot of repetitive sections in them
2. I copy and paste the repetitive bits into separate files
3. I xinclude the fragments into the original documents
4. I clean everything up to be valid XHTML, which doesn't take long because I wrote my HTML to be 99% valid XHTML from the beginning in anticipation of the day I'd want to do something like this
5. I run it through xinclude and from my perspective, garbage comes out

The point being that all of the relative URIs were "valid" in the original documents.
So now the same URIs are in fragment files in the same directory as the original documents.
I Xinclude them back into "finished" documents and it doesn't work because it tries to be too clever. <sigh>

In other words, this isn't #include from C, and I need to stop thinking of it as if it were.
But didn't anyone do use case analysis on this? Am I really doing something so unreasonable?

My application here is my website. Thus there's no such thing as an absolute URI in it, except for external links.
It has to work regardless of whether it's on my hard disk, on a test server or live on the Internet. Thus none of the documents have absolute xml:base attributes - that would defeat the whole idea!

Actually, I think you can detect my case. Here's what I'm thinking...

You know the base URI of the document doing the including. eg, let's say it is currently:
file:///foo/bar/baz/index.xml
When you see xi:include, you get the relative URL of the fragment:
<xi:include href="fragment.xml">
Thus the absolute URI of the fragment is:
file:///foo/bar/baz/fragment.xml

Well, then you can detect that these are the same except for the last component: ie, they're both at "file:///foo/bar/baz/" and in this case it would be OK to skip emitting the xml:base attribute.

If on the other hand I write:

<xi:include href="someOtherDir/SomeOtherFragment.xml">

Then the 2 URIs don't match up to their last component ("file:///foo/bar/baz/" != "file:///foo/bar/baz/someOtherDir") and you need to add an xml:base to the included fragment. I think that would work recursively for documents included in the fragment too?

What do you think?

You could write a post-process that stripped the xml:base attributes. It would be easiest to do this using XSLT or (in XOM 1.1) XPath:

This I'll probably do, given I've already sunk so much time into this.

Thanks for all your time!

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