Support #4911

Possible Bug with Saxon Schema Validation - target namespace has not been imported

Added by Octavian Nadolu 7 months ago. Updated 5 months ago.

Start date:
Due date:
% Done:


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


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, 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:

schemaA-11.xsd (452 Bytes) schemaA-11.xsd Octavian Nadolu, 2021-02-17 08:20
schemaB.xsd (456 Bytes) schemaB.xsd Octavian Nadolu, 2021-02-17 08:20
schemaC.xsd (864 Bytes) schemaC.xsd Octavian Nadolu, 2021-02-17 08:20


#1 Updated by Michael Kay 7 months 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 § 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.

#2 Updated by Octavian Nadolu 7 months ago

Thanks for clarification. As a suggestion, maybe you can add an error code to identify the problem and point to the specification.

#3 Updated by Michael Kay 7 months 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.

#4 Updated by Michael Kay 7 months 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.

#5 Updated by O'Neil Delpratt 5 months ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF