When enabling XInclude processing (passing 'true' to AbstractDOMParser::setDoXInclude) I would expect the XInclude processing to occur BEFORE validation, where it is infinitely more useful.
While I understand that some users may wish to use XSD validation to tightly control where XInclude declarations may appear, and go to the additional trouble of validating each included document individually, the much more common use case for XInclude is amalgamating two or more XML "snippets" into a single document which is then validated against an XSD. Validation is most useful when performed as the last step before an application begins processing an XML document; it allows the application to make certain assumptions about the content of the document that it is about to traverse. Altering the document (i.e. via XInclude processing) after validation eliminates this benefit, and is therefore of questionable usefulness.
Ideally it should be possible to specify via the API whether XInclude processing will occur before or after validation; however, in the absence of such "configurability", I submit that processing before validating should have been chosen as the default sequence, for the reasons outlined above.
Currently I'll have to implement some ugly hacks to get around this, e.g. parsing without validation (so that the XIncludes get processed), writing the resulting document to a temporary file, and then parsing again, this time with validation - not only very inefficient, but grotesquely inelegant.