Thanks. You are right, this is a bug. The bug had already been fixed in the
9.4 branch, but I will now issue a patch for 9.3. Sorry about the
inconvenience.
It's one of those bugs where it's quite hard to explain the circumstances in
user-oriented terms. During schema processing Saxon creates a temporary
SimpleTypeDefinition object for a simple type, and later turns this into an
AtomicType, ListType, or UnionType when its variety becomes clear. The problem
occurs because sometimes after the conversion, another schema component is
left pointing to the old (pre-conversion) SimpleTypeDefinition. It all depends
on the order in which components are processed, which is itself rather random,
as it involves iterating over a HashMap.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the swift response and the explanation. George Bina from SyncRO
Soft actually spotted that this was a Saxon bug when I reported the behaviour
on the DITA list. I suppose it's one of those things that doesn't crop up all
that often!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello. When validating the following (test) schemas with saxon EE 9.3.0.5 in
Oxygen 12:
testBase.xsd:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="<a class=" "="" href="http://www.w3.org/2001 /XMLSchema">http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:simpleType name="yesno-att.class">
<xs:restriction base="xs:string">
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
</xs:restriction>
</xs:simpleType>
<xs:attributeGroup name="image.attributes">
<xs:attribute name="href" type="xs:string"/>
<xs:attribute name="scalefit" type="yesno-att.class"/>
</xs:attributeGroup>
<xs:element name="test">
<xs:complexType>
<xs:attributeGroup ref="image.attributes"/>
</xs:complexType>
</xs:element>
</xs:schema>
test.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="<a class=" "="" href="http://www.w3.org/2001 /XMLSchema">http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:redefine schemaLocation="testBase.xsd">
<xs:attributeGroup name="image.attributes">
<xs:attribute name="href" type="xs:string" _use="required" _=""/>
<xs:attribute name="scalefit" type="yesno-att.class"/>
</xs:attributeGroup>
</xs:redefine>
</xs:schema>
I get the following error message:
Invalid restriction: attribute @scalefit is inconsistent with the base type.
Type yesno-att.class is not validly derived from type yesno-att.class
Xerces reports no error given the same input and the error message appears
spurious in any case. Is this a known issue with Saxon 9.3?
Thanks. You are right, this is a bug. The bug had already been fixed in the
9.4 branch, but I will now issue a patch for 9.3. Sorry about the
inconvenience.
It's one of those bugs where it's quite hard to explain the circumstances in
user-oriented terms. During schema processing Saxon creates a temporary
SimpleTypeDefinition object for a simple type, and later turns this into an
AtomicType, ListType, or UnionType when its variety becomes clear. The problem
occurs because sometimes after the conversion, another schema component is
left pointing to the old (pre-conversion) SimpleTypeDefinition. It all depends
on the order in which components are processed, which is itself rather random,
as it involves iterating over a HashMap.
Thanks for the swift response and the explanation. George Bina from SyncRO
Soft actually spotted that this was a Saxon bug when I reported the behaviour
on the DITA list. I suppose it's one of those things that doesn't crop up all
that often!