Saxon

I assume that in the second case (validation of the output using an XMLReader) you were using the Xerces schema validator rather than the Saxon schema validator. There's no intrinsic reason to expect two different validators to report the same errors. A schema processor has to make judgments about this; for example, if an element isn't supposed to appear in a particular position, should it still validate the content of that element? The last thing anyone wants is multiple error messages all caused by what is essentially a single error. All you can really expect is that two validators agree about whether the document is valid or not. To investigate this in more detail one would need to look at the actual document and schema.

I think that when Saxon finds a "content model" violation, i.e. an element that isn't valid by virtue of the content model of the parent element, then it basically stops validating the following sublings of that element, on the grounds that any errors reported with regard to those siblings are quite likely to be spurious.

There's also a possibility of differences caused by the fact that in one case, validation is within the context of a transformation. In principle, a single validation error is enough to cause the transformation to fail, and once an error occurs during a transformation, it's perfectly entitled to stop there and then. In practice, though, for validation of output documents Saxon doesn't do that: or at any rate, it doesn't do so by default.

But I think it would be interesting to compare a freestanding Saxon validation of the result document (using the com.saxonica.Validate) command with a free-standing Xerces validation, taking XSLT out of the equation. It would then be interesting to look at the actual Xerces messages and see whether any of them are related, in the sense that they relate to the same or related elements.

That explanation is very helpful, thank you. I just ran a quick test using com.saxonica.Validate on a nearly identical document as the source document I mentioned originally. The messages output are very similar to the messages I got using Saxon with validation during the transformation. The number of messages is the same as well (4).

• XSD99999: In content of element : The content model does not allow element to appear as the first child. Expected .

• XSD99999: In content of element : The content model does not allow element to appear immediately after element . It must be preceded by one of: , .

• XSD99999: In content of element : The content model does not allow element to appear immediately after element

  . Expected

  or nothing.

• XSD99999: In content of element : The content model does not allow element to appear immediately after element . The following elements would be valid here, all in no namespace: funding-info, processing-relationships, x (or nothing).

I believe the messages I included above in my second set of messages are the equivalent of what Xerces would produce in a freestanding validation.

I think you correct that the Xerces messages not output by Saxon are messages which are associated with the descendants of the elements that Saxon did flag. I will be doing some more testing to confirm that the other 6 errors Xerces flagged are also flagged by Saxon when the 4 errors they have in common are resolved. I'm sure they will be! Thanks again!

ID/IDREF constraints apply at document level. In your XSLT, you are invoking validation at element level. You will only get ID/IDREF errors if you validate the whole document, not an individual element, even if it is the root element of the document.

Thank you again for the assist. I've done some googling and I haven't found a way to validate the whole document during transformation. If there is a way, I would appreciate if you could refer me to some documentation on it. Otherwise, I will proceed to implement the full document validation after the transform via a parser validation with an XMLReader.

You can do <xsl:document validation="strict"> to create the output document: or xsl:result-document with no href has pretty much the same effect. That is, you typically replace

<xsl:template match="/">
  <root>
    ,, code here
  </root>
</xsl:template>

with

<xsl:template match="/">
 <xsl:document validation="strict">
  <root>
    ,, code here
  </root>
 </xsl:document>
</xsl:template>

The detailed rules for what gets validated can be found here:

http://www.w3.org/TR/2009/PER-xslt20-20090421/#validation