Bug #3919
closed
Saxon validation fails where Xerces succeeds
100%
Description
I have two schemas, munipub_basket.xsd and munipub.xsd, where the first schema includes the second schema (separate namespace).
An element defined in the included schema is reported as invalid when validated through the first schema but not when validated against only the second schema.
The declaration in question (from munipub.xsd) is:
<xs:element name="td">
<xs:complexType>
<xs:complexContent>
<xs:extension base="block_xor_inline_children">
<xs:attributeGroup ref="tablecellattributes"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="block_xor_inline_children" mixed="true">
<xs:choice>
<xs:group ref="blockelements" minOccurs="0" maxOccurs="unbounded"/>
<xs:group ref="inlineelements" minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:attributeGroup ref="globals"/>
</xs:complexType>
The validation failure is on <td> with #PCDATA:
<tr>
<td>text directly in td</td>
</tr>
Using Oxygen to run the validator, if Saxon EE is set as the default validator, the td is reported as invalid but with Xerces it is valid. My weak understanding of the XSD spec suggests that the td should be valid (in that the mixed="true" from the referenced complex type should be respected for <td>.
If I create a document that uses the munipub.xsd directly with the same table Saxon reports it as valid. So something with the inclusion of the schema is causing an issue with Saxon.
XSDs and test docs attached.
Files
Updated by Michael Kay over 5 years ago
I think Saxon is getting it right. Looking at the XSD 1.1 spec,
§3.4.2.3.3 Mapping Rules for Content Type Property of Complex Content
{content type} - rule 1 (specifically 1.3) tells us that the "effective mixed" is false.
Rule 4.2.3 then says (for derivation=extension) that the {variety} (of TD's type) is mixed if and only if the "effective mixed" is true.
So I don't think "mixed" should be inherited from the base type.
There seems to be no change here between XSD 1.0 and XSD 1.1
Updated by Michael Kay over 5 years ago
But then, why is Saxon deciding it's mixed content when the munipub.xsd schema is used in isolation?
Looking at the code in this case, isLocallyEmpty() returns true and in this case the mixedness of the base type is inherited. Indeed, looking back at the spec, Rule 4.2.2: If the {base type definition} is a complex type definition whose {content type}.{variety} = element-only or mixed and the ·effective content· is empty, then {base type definition}.{content type}; (In fact, the value of "mixed" on the derived type is ignored in this case).
So the question becomes, why is isLocallyEmpty() not true in the other case?
Updated by Michael Kay over 5 years ago
What's happening, in the branch with the xs:include, is that UserComplexType.validateExtension() is exiting early because it finds that the type is already known to the Configuration, and it assumes this means that it has already been validated so no further action is needed. (Note, for ease of debugging I've made the complex type of the td element into a global named type, and so far this doesn't seem to affect the outcome).
Despite its name, it's the code in validateExtension() that changes the variety of the type to mixed.
Further investigation to follow.
Updated by Michael Kay over 5 years ago
There's a strong overlap between this bug and bug #3925. The symptoms are slightly different (the test case in 3925 works under 9.8 and fails under 9.9) but the underlying fragility is the same. Because the repro for 3925 is far simpler, I'm going to focus my diagnostic efforts on that one, and come back to this bug later to see if the same solution applies.
Updated by Michael Kay over 5 years ago
In investigating bug #3925, I find that removing the lines
SchemaType existing = getConfiguration().getSchemaType(getStructuredQName());
if (existing != null && existing.isSameType(this)) {
return true;
}
solves the problem. (This is the "early exit" referred to in comment #3).
Updated by Michael Kay over 5 years ago
- Category set to Schema-Aware processing
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Applies to branch 9.8, 9.9 added
- Fix Committed on Branch 9.8, 9.9 added
Confirmed fixed (on 9.8 and 9.9) by the change to UserComplexType.validateExtension() - patch (B) of issue #3925.
Updated by O'Neil Delpratt over 5 years ago
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.8.0.15 added
Bug fix applied in the Saxon 9.8.0.15 maintenance release. Leave open to the Saxon 9.9 maintenance release.
Updated by O'Neil Delpratt over 5 years ago
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 9.9.0.2 added
Bug fix applied in the Saxon 9.9.0.2 maintenance release.
Please register to edit this issue
.