assert unexpected result

Hi all,

I attaches an XSD (filename: test_rd.xsd) and a text-XML (filename payload (002).xml)

THE xsd has two assertions in lines 638 and 639

      <xsd:assert test="(count(G_SG3/S_NAD[D_3035=('ZSY')]) &lt;= 1)"/>
      <xsd:assert test="(count(G_SG3/S_NAD[D_3035=('ZSH')]) &lt;= 1)"/>

We expect, that

G_SG3/NAD with value ZSY occurs at most one time
G_SG3/NAD with value ZSH occurs at most one time

The text file violates the assertions

instead of

G_SG3/NAD with value ZSH occurs at most one time we have
G_SG3/NAD with value mxt

The validation result gives three informations but does not meet our expectations:

The content "mxt" of element <D_3035> does not match the required simple type. Value "mxt" contravenes the enumeration facet "ZSY, ZSH, ZSO, ZSX" of the type of element D_3035 --> This is correct
Element M_ORDRSP does not satisfy assertion (count(G_SG3/S_NAD[D_3035=('ZSH')]) <= 1) --> This is correct, as ZSH is missing in the testfile
Element M_ORDRSP does not satisfy assertion (count(G_SG3/S_NAD[D_3035=('ZSY')]) <= 1)

--> This makes us headaches as it is present¶

Could anybody please tell us why we get the third error? Is our assertion statement wrong or our interpretation of the error?

Regards Mario

Download all files

payload (002).xml (3.23 KB) payload (002).xml
test_rd.xsd (35.8 KB) test_rd.xsd

Replies (3)

Please register to reply

RE: assert unexpected result - Added by Michael Kay over 5 years ago

The clue to what's happening here lies in the warning messages:

Warning evaluating (fn:subsequence(...)) on line 1 column 13 Internal error: value doesn't match its type annotation. Value "mxt" contravenes the enumeration facet "ZSY, ZSH, ZSO, ZSX" of the type of element D_3035

Evaluation of the assertion is going wrong because the assertion is looking at invalid data. I haven't established exactly how the invalid data causes this failure, but it's certainly something that seems theoretically possible. Probably the only way of ensuring that this can never happen is to avoid ever evaluating an assertion over a subtree if any validity errors were found in the subtree; unfortunately this would result in some errors going undetected, so I'm not sure it would suit all users.

The reference to the subsequence() function is because the assertion has been optimized (taking advantage of schema information). It might be that it would be safer to avoid schema-aware optimizations of assertion expressions.

I will raise an issue on this and see if we can improve the logic for this use case. In general, however, once one invalidity is reported, it becomes a little unpredictable whether subsequent errors are legitimate or not; there is always a possibility of (a) other errors not being reported because the error recovery discards too much, or (b) subsequent spurious errors because the error recovery discards too little.

RE: assert unexpected result - Added by Michael Kay over 5 years ago

Will be followed up as a (possible) bug at https://saxonica.plan.io/issues/4172

RE: assert unexpected result - Added by Mario Mueller over 5 years ago

Hi Michael,

many thanks Regards Mario

(1-3/3)

Please register to reply

Project

Profile

Help

Saxon