Testing can show the presence of errors, but not their absence.
Consider the following documents:
Is the book valid? Well, let's see. Entities are expanded by the parser, so that book is structurally equivalent to this document:
And that document is valid DocBook NG “IPA”. So the answer is yes.
Next, if I tell you that the
fileref attribute is resolved against the
current base URI, can you tell me the URI of that graphic? Did you get
I knew you could. The point is that expanding an entity preserves the
base URI of that entity.
Now let's drag this document into the twenty-first century.
Is the book valid? No, because the DocBook NG schema doesn't allow XInclude elements. Oh, you meant after XInclude processing. (I'll resist a long rant about processing models by reference.) Well, let's see. After XInclude expansion, we'll get:
So the answer is, “it depends”. Specifically, it depends on
whether or not DocBook NG “IPA” allows
xml:base (you did notice the extra
xml:base attribute, didn't you?) to appear on
chapter. It does, so the answer is yes.
This time, I'm sure you can tell me that the URI of that graphic is
because the base URI is explicit.
The problem is that lots and lots of schemas out there, maybe
some that you're responsible for don't allow
xml:base to appear anywhere.
And XInclude is
fundamentally incompatible with all those schemas in the presence of
In the short term, I think there's only one answer: update your
schemas to allow
xml:base either (a)
everywhere or (b) everywhere you want XInclude to be allowed. I
urge you to put it everywhere as your users are likely to want to do things
you never imagined.
Longer term, I've heard a couple of possible solutions. One is to change
(W3C XML) schema validation so that attributes in the
namespace are silently allowed everywhere (just like attributes from
That isn't a very attractive answer to me; I think it's a flaw in W3C XML
I can't control where the schema instance attributes can occur. But it
would allow you to use XInclude with all those schemas that you have no
power to update.
Another possibility, though I haven't heard it suggested with any
seriousness, would be to update XInclude so that it doesn't add
xml:base attributes to the included document.
The sad thing is, that attribute is a bit of a “belt and
suspenders” approach to the base URI. The included document has a
base URI property in the Infoset and that property has the correct value.
We didn't have to add the attribute. Except maybe we did, because without
the attribute, the correct base URI wouldn't survive serialization (as
might occur, for example, if you packaged the document up and shipped
it off to some web service in a SOAP
In any event, even if we could remove it, removing it would be backwards incompatible so it's awfully painful to do that. And it won't magically fix all the running code out there. And it will seriously inconvenience folks who need to ship documents around after XInclude expansion.
Updated, 04 Apr 2005.
I originally said, I think what pains me most about this situation is that XInclude was in development for just over five years. It went through eleven draftsEvolving at an average rate of just over 37 words a day, if you count all the words in all the public drafts. including three Candidate Recommendations.
I went on to ask why no one noticed until after XInclude became a Recommendation. And I was just wrong. The problem was noticed, and the decisions taken were deliberate. This is a good thing. It means the process didn't fail in a spectacular fashion. It's embarrassing to screw up in public, but the embarrassment at hand is insignificant (though much more acutely personal) compared to what I originally feared.
The informality of this medium allows me to write quickly, sometimes too quickly. I've said stupid things before, I'm bound to say them again, though this incident is likely to make me a little more careful.
In the original version of this essay, I went on to compare the length of XInclude (8,563 “words” according to my word counting script) with the length of the XSL/XML Query family of specifications (clocking in at 505,779, just over a half million). The point of my comparison is no longer relevant, but I'll leave the numbers.
P.S. I am still not kidding, though perhaps I wish I could say I had been.