I for one would certainly like that xml:base, xml:id and xml:lang would be allowed everywhere. I do think that it should be restricted to known 'xml:foo' attributes and shouldn't apply to all by default.

Is the fundemental problem here one of treating xml:base as an attribute at all?

Should it not have been decided to treated xml:base specially in the same way that namespace declarations are? That would have avoided the Infoset problem of possible contradiction between the xml:base attribute and the [base URI] as well as this validation problem.

Also, ...because without the attribute, the correct base URI wouldn't survive serialization.... Hmm, that's not really serialization if it's throwing away some of the data. This is the mirror image argument for the xml:base attribute to be special: it should be inserted when serializing in which case it shouldn't be present as an attribute in the Infoset.

I'm exploring the edge of what I understand here so I'd be pleased to see some discussion of this.

Are you sure nobody noticed this? I could swear I had users complaining to me about this before the spec went to REC, and I suspect the working group heard some of this too, though I'd have to search through the archives to make sure. OK. Found it. Peter McCracken raised this issue with the working group on June 12, 2003; and it was discussed. After this date, XInclude was sent back to working draft status for other reasons. So the problem is not that the working group didn't know about this issue. The problem (if any) is that the choice they made. If they had decided differently, they could have easily changed this.

Personally, I don't consider this all that big a deal. Schema-validity is vastly overrated. I routinely add markup to my documents that is not accounted for by the schemas, and as long as you don't blindly throw away all invalid documents, everything pretty much works. I think the working group's decision here is the right one. If you really need validity and XInclude, then you need to update your schemas/DTDs to support xml:base everywhere. It's probably a good idea to do that anyway.

I stand corrected. It wasn't unknown. I'll have to think some more about what I think this means. Bill de hÓra questions the process. I'm not sure at the moment if it's the process, or my memory (or something else) that I think is the problem.

I agree with Eliotte, it's in no ways new, and the issue had been raised and discussed. One of the change (from memory) that we did end up with is that the xml:base is added only if necessary, i.e. if addding an xml:base is needed to get URI-Reference expansion right within the included subtrees. In practice it means that if the included resource is in the same directory/folder/whatever than the resource including it, adding the xml:base is not necessary, and for example libxml2 will not add it. This is a publishing limitation but it allows to cope with the validation problem until the various DTDs/Schemas have been updated with the extra xml:base.

Daniel

There is a general process problem here that bedevils most XML standards efforts. You get a group of volunteers together, and then put together what you can with limited resources. The problem is that so much of what you do is theoretical, because no-one is testing along the way.

Where I think Java got it so *right* was that conformance was always part of the standard, so there was always a reference implementation and a set of conformance tests. I think that is where all XML standards have to get to, if they are going to avoid this type of problem as a general consequence.

There *are* XInclude implementations, of course, but I'm not sure they are so widely used. I suspect XQuery 1.0 and XSLT/XPath 2.0 are getting much more user testing before going to recommendation (thanks to Mike Kay and others). So I don't think you can apply the XInclude statistics directly to XQuery/XSLT/XPath.

However, it *would* help if the W3C & OASIS got out of the paper standard business, and moved more to being in the "standard + reference implementation + conformance" business. It's harder to get resources for, tougher to get to the finish of, but makes for *much* better results. C++ showed us how wrong things could get with a paper standard, Java showed us a much better process. XML shouldn't ignore that example.

Cheers, Tony.

Daniel's recollection is incorrect. This was discussed but the original decision stood. XInclude processors are required to preserve the full base URIs of the elements they include. This means that any content included from a different document is required to have an xml:base attribute. It is not enough that the relative URIs resolve correctly. According to the spec, the full base URI must be preserved; not merely the URI of the parent directory. libxml is nonconformant in this respect; though I'm not sure if anyone will notice or care since the practical impact of this nonconformance seems small.