Project

Profile

Help

Bug #4172

Spurious assertion failure caused after another validation error

Added by Michael Kay about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Schema-Aware processing
Sprint/Milestone:
-
Start date:
2019-03-18
Due date:
% Done:

100%

Legacy ID:
Applies to branch:
9.9, trunk
Fix Committed on Branch:
9.9, trunk
Fixed in Maintenance Release:

Description

See https://saxonica.plan.io/boards/3/topics/7419

Schema validation has reported failure of an assertion when in fact the assertion is perfectly valid; the failure appears to be triggered by the fact that there is an invalid value within the element to which the assertion applies, but this shouldn't make the assertion false.

History

#1 Updated by Michael Kay about 1 year ago

I think that the assertion failed not because the result was false, but because an error occurred during its evaluation; the error was reported as a warning condition, stating

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

Reading the XSD 1.1 and XDM specifications rather carefully, it seems that in the tree that the XPath expression is processing, the element D_3035, whose content is invalid, should be annotated as xs:anyType. This gives us a peculiar situation, not encountered elsewhere, where the XPath expression is processing a mixture of typed and untyped data in the same document. It also means that some of the assumptions we make during optimization of the expression (which is treated as being schema-aware) are questionable.

We build the tree using the standard builder/validator, in which type annotations are allocated optimistically at startElement time. That is, the type annotation is what the type should be, if the element is valid. We don't have any mechanism in the tree builder to revert this if the element turns out to be invalid; in normal circumstances this would be a fatal error, and the tree would never be accessed, so its type annotations would be immaterial.

One option might be to avoid doing assertion processing on any tree that contains data reported as being invalid. In many cases, however, this would lead to some validation errors going unreported, making it difficult to correct all errors after a single validation run.

#2 Updated by Michael Kay about 1 year ago

I note that the class AnnotationTreeBuilder contains the comment:

In the case of an element
node, the type annotation is added during the endElement call, after testing assertions against that element,
to satisfy the rule that when an assertion is evaluated, the target element has type AnyType but its attributes
and descendants are typed according to the appropriate schema declarations.

This might have been wishful thinking.

#3 Updated by Michael Kay about 1 year ago

  • Status changed from New to In Progress

I have introduced logic with the effect that when a validation error occurs, the AssertionTreeBuilder is notified, and is asked to reset the type annotation of all ancestor elements to s:anyType.

This has the desired effect for this particular test case; the challenge is to ensure that it causes no regression elsewhere.

#4 Updated by Michael Kay about 1 year ago

All tests are passing after this change.

I'm still a bit concerned that there could still be issues around optimization: however, we are not providing the assert expression with a static context item type, so there is little scope for the optimizer to make use of schema information, which suggests we should be OK.

#5 Updated by Michael Kay about 1 year ago

  • Status changed from In Progress to Resolved
  • Fix Committed on Branch 9.9, trunk added

#6 Updated by O'Neil Delpratt about 1 year ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.9.1.3 added

Bug fix applied to the Saxon 9.9.1.3 maintenance release

Please register to edit this issue

Also available in: Atom PDF