Bug #3919: Saxon validation fails where Xerces succeeds - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #3919

closed

Saxon validation fails where Xerces succeeds

Added by Eliot Kimber about 6 years ago. Updated about 6 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

Schema-Aware processing

Sprint/Milestone:

Start date:

2018-09-26

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.8, 9.9

Fix Committed on Branch:

9.8, 9.9

Fixed in Maintenance Release:

9.8.0.15, 9.9.0.2

Platforms:

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

saxon-xsd-validation-issue.zip (91.3 KB) saxon-xsd-validation-issue.zip

XSDs and test docs.

Eliot Kimber, 2018-09-26 22:16

Actions

Copy link

Updated by Michael Kay about 6 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

Actions

Copy link

Updated by Michael Kay about 6 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?

Actions

Copy link

Updated by Michael Kay about 6 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.

Actions

Copy link

Updated by Michael Kay about 6 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.

Actions

Copy link

Updated by Michael Kay about 6 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).

Actions

Copy link