Support #4911
closedPossible Bug with Saxon Schema Validation - target namespace has not been imported
0%
Description
It seems to be a problem when validating a an XSD 1.1 schema that has an import schema with a different namespace, and refers a type from that namespace in an assert .
I tested with axon 10.3 and 9.9.1.7, and when I validate "schemaC.xsd" I get an error message something like this: "Atomic type ns1:Token3 exists, but its target namespace has not been imported in the static context" I attached the sample files.
This problem was reposted by one of Oxygen XML users. You can find more details here: https://www.oxygenxml.com/forum/viewtopic.php?f=1&t=22443
Files
Updated by Michael Kay almost 4 years ago
It's not the world's most wonderful message but I think it's correct.
The key is in XSD 1.1 Part 1 §3.13.6.2 rule 2.2.5: {in the static context for evaluation of the XPath expression in an assert), " The in-scope schema definitions are those components that are present in every schema by definition, as defined in Built-in Attribute Declarations (§3.2.7), Built-in Complex Type Definition (§3.4.7) and Built-in Simple Type Definitions (§3.16.7)."
The hidden meaning of that rule is that types defined in the schema itself are not available for use in assertions. The reason for that rule is to prevent circularity: since types in the schema are defined with reference to assertions, then the assertions can't be defined with reference to types.
Updated by Octavian Nadolu almost 4 years ago
Thanks for clarification. As a suggestion, maybe you can add an error code to identify the problem and point to the specification.
Updated by Michael Kay almost 4 years ago
Not easy, because we simply initialise a static context for evaluating the XPath expression, and then fire off the XPath processor: the XPath processor can't find the type name in its static context, but it has no idea why this particular type is absent.
Updated by Michael Kay over 3 years ago
- Tracker changed from Bug to Support
- Status changed from New to Resolved
- Assignee set to Michael Kay
Closing this, I don't think there is any other useful action we can take.
Updated by O'Neil Delpratt over 3 years ago
- Status changed from Resolved to Closed
Please register to edit this issue