Well, serves me right.  I noted there was a controversy around xml:base fixup in XInclude and then stepped right into the middle of that controversy.  (How’d they even find me so quickly?)  Dare Obasanjo defends the ability to suppress xml:base fixup, but notes that by disallowing xml:base fixup one must rely on other mechanisms (pre-processing relative URIs with XSLT, for instance) to ensure links remain intact.  I agree, but let’s look at that approach more closely.

Seems to me there are several ways to use a fixup-suppression mechanism safely:

1. First, you have to know whether there are any relative URIs in the document.  If there aren’t, xml:base fixup is unnecessary, inconvenient, even harmful:
   • A schema for the fragment, plus an assertion or at least assumption that all URIs are indicated using xs:anyURI or types derived from it.  By inspecting the document in the light of such a schema, you can then determine which URIs are relative (Though you are unlikely to have such a schema in this use case, since we already know we’re validating post-inclusion.)
   • Some other out-of-band assertion that there are no relative URIs.
2. If there are identifiable relative URIs, you can deal with them in a number of ways:
   • Absolutize them as Dare suggests (XSLT might work for this, though the string manipulations required by the absolutization algorithm are not XSLT’s strong point.)
   • Decide to re-base them. That is, just leave them relative because you know that they will work correctly at the new base.  This is reasonable in many circumstances (after all, what are relative URIs for).
   • Ignore them.  If you can handle the possibility that the links might be broken or lead to unexpected destinations (you might even be trying to exploit a security hole on purpose) just leave them alone.

I think this justifies my point, which is that one should disable xml:base fixup with care and only with specific knowledge about the included fragment unavailable to a generic XInclude processor.

Step 1 shows there are no generic mechanisms within the scope of XInclude that allow it to determine when xml:base fixup is harmful.  I don’t have any problem with out-of-band information being used (thought a global processor option seems rather blunt) to make these assertions.

Step 2 implies that in the cases where you want to suppress xml:base for valid reasons, this can be best expressed as infoset pre-processing (modifying the [base URI] or the character information items comprising the URI).  XInclude allows wide latitude in creation of the included infosets, and such manipulation seems perfectly allowable.  The XInclude syntax is quite extensible so you could even add assertions about parameterizing the infoset creation on an element-by-element basis.

  <xi:include href="MayContainRelativeURIs.xml" xix:changebase="true"
                    xmlns:xi="http://www.w3.org/2001/XInclude"
                    xmlns:xix="http://example.com/XIncludeExtensions"/>

I’m glad to see Dare move from considering xml:base fixup "fundamentally broken" to "optimized for an edge case", but I still think that dropping the fixup completely as Dare implied would need to be classified as "fundamentally broken for the edge case", not simply "optimized for the common case."  It is a judgement call whether passing XML Schema validation but breaking links is better than keeping links intact but failing XML Schema validation.

So my advice stated more clearly is: Don’t consider the user option to suppress xml:base fixup as a workaround to a fundamental flaw in XInclude - use it in conjunction with specific knowledge about relative URIs in the contents of the inclusion to re-base the content.  It’s a new feature, not a workaround.  A side-effect of such re-basing is that the output is smaller and easier to validate against schemas that don’t allow xml:base.