Bug #2100: Incorrect behaviour when an abstract type is used for validation - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #2100

closed

Incorrect behaviour when an abstract type is used for validation

Added by Michael Kay over 10 years ago. Updated over 10 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

Schema conformance

Sprint/Milestone:

Start date:

2014-07-02

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

Fix Committed on Branch:

Fixed in Maintenance Release:

Platforms:

Description

During schema validation, if the declared type of an element is abstract, and there is no xsi:type attribute, Saxon attempts to validate the element as if the type had an empty content model. This means that if the instance is non-empty, an inappropiate error message is produced, and if the instance is empty, it is incorrectly treated as valid. As stated in 3.4.1 (with greater clarity in the 1.1 version of the spec) validating against an abstract type should result in a validation error.

Actions

Copy link

Updated by Michael Kay over 10 years ago

Also discovered while investigating this: when the StandardErrorListener constructs the message for a validation error, the test for constraintReference is wrong: if the constraintReference is null, it prints "null", and if non-null, it prints nothing. In this case the constraintReference is null because the validation error doesn't seem to be described in the regular way in the spec.

Actions

Copy link

Updated by Michael Kay over 10 years ago

Status changed from New to Resolved

A patch is being committed on the 9.5 and 9.6 branches.

Actions

Copy link

Updated by Michael Kay over 10 years ago

Added test case Saxonica/Complex/complex021 to the W3C XSD test suite.

Actions

Copy link

Updated by Michael Kay over 10 years ago

Status changed from Resolved to In Progress

The patch causes the XQuery QT3 test prod-SchemaImport/qischema070 to fail, complaining that the type being used for validation is abstract. This test should not fail, because there is a non-abstract xsi:type on the element being validated. The patch is not incorrect, but it is exposing an error in the logic of FixedElement.computeFixedElementItemType() (used for validation of newly constructed elements in XQuery and XSLT); the error is that the validationOptions are set to contain topLevelSchemaType set to the type of the relevant element declaration, rather than the value of xsi:type.

Actions

Copy link