http://norman.walsh.name/2005/04/01/xinclude 8 47 2005-04-01T10:21:57-05:00 $Date: 2006-07-14 10:06:19 -0400 (Fri, 14 Jul 2006) $ Norman Walsh 2005 Norman Walsh It turns out that there's a nasty interaction between XInclude, xml:base, and validation. Update: I was wrong. The interaction is real, but it didn't go unnoticed. E. Dijkstra Testing can show the presence of errors, but not their absence. I doubt this is news, it's drifted across my radar a couple times in the past month or two: it turns out there's a nasty interaction between XInclude, xml:base, and validation. 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 http://norman.walsh.name/2005/04/01/examples/chapters/picture.png? 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 http://norman.walsh.name/2005/04/01/examples/chapters/picture.png, 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 validation.

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 xml: namespace are silently allowed everywhere (just like attributes from the http://www.w3.org/2001/XMLSchema-instance namespace). That isn't a very attractive answer to me; I think it's a flaw in W3C XML Schema that 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 envelope). 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 drafts Evolving 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.