Project

Profile

Help

Support #5584

closed

assertion in XSD 1.1 might be misinterpreted

Added by Geert Bormans over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
Schema conformance
Sprint/Milestone:
Start date:
2022-06-28
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:
Java

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

Actions #1

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).

Actions #2

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)

Actions #3

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 "=".

Actions #4

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
Actions #5

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

Also available in: Atom PDF