Support #5584
closed
assertion in XSD 1.1 might be misinterpreted
0%
Description
I have an assertion in a schema
<xsd:element name="chapter">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="hierarchy">
<xsd:assert test="every $x in (*) satisfies $x = (num | heading |section | article)"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
and this XML snippet
<chapter eId="chap_1">
<num>1. Kapitel:</num>
<heading>Gegenstand und Geltungsbereich</heading>
<section>
<content>
<p>some text</p>
</content>
</section>
</chapter>
And Saxon EE 10.6 gives me this error on validation
Element chapter does not satisfy assertion every $x in (*) satisfies $x = (num | heading |section | article)
I would expect it to be valid against the assertion Doing the same test with Xerces shows that Xerces claims the assertion is valid
Not sure this is a bug, maybe my misunderstanding
Thanks Geert Bormans
Files
Updated by Martin Honnen over 2 years ago
When using SaxonCS I get a warning "FOTY0012 Cannot get the typed value of an element (section) with element-only content" and I think that way, with a dynamic error during the attempt to evaluate the test expression, Saxon treats the assertion as failed for the section element, as https://www.w3.org/TR/xmlschema11-1/#assertion-validation says "It is a consequence of this rule that a conforming processor which treats a type error in an XPath expression as a dynamic error will treat the expression as having evaluated to false".
That is my interpretation of why Saxon says the chapter element fails the assertion, the atomization of section happening as part of the (right hand) side of the operator = fails as elements with element only content don't have a typed value (https://www.w3.org/TR/xpath20/#dt-typed-value).
Updated by Michael Kay over 2 years ago
Martin's interpretation is correct: evaluation of the assertion did not return false, it failed with an error, as reported in the warning message.
The rules for evaluating assertions say, in effect, that you first construct the XDM tree for the element being validated, and then validate it against a schema that's the same as the target schema but without the assertions; this gives you a typed XDM tree, and the assertion is then evaluated against this typed tree. Evaluating the "=" operator against an element node requires atomization, and atomization of a typed element node with element-only content fails with a dynamic error.
Using "=" to test element names, rather than element values, is quite wrong. The assertion should probably be written
every $x in (*) satisfies $x ! (self::num or self::heading or self::section or self::article)
Updated by Michael Kay over 2 years ago
The relevant rules are in ยง3.13.4.1 of XSD 1.1 part 1:
In particular if an assertion appears on element E, then the children of E are validated (and acquire type annotations) before applying the assertions on E. So in this example, the atomization of the child elements follows the rules for atomising typed elements, which leads to a dynamic error if any of the children has element-only content. Contrary to what Martin suggested, the failure can occur for either operand of "=".
Updated by Michael Kay over 2 years ago
- Tracker changed from Bug to Support
- Category set to Schema conformance
- Status changed from New to Closed
- Assignee set to Michael Kay
Updated by Geert Bormans over 2 years ago
Thanks Michael for the explanation. Thanks Martin also for stepping in
Please register to edit this issue
.