Saxon

I get similar results with Saxon 9.8. Oddly though, oXygen seems to accept this schema, and allows validation using a number of validation engines.

We have a complexType with complexContent named NoteType:

        <xsd:complexType name="NoteType">
		<xsd:complexContent>
			<xsd:extension base="DescriptionType">
				<xsd:attribute name="author" type="xsd:string" use="optional"/>
				<xsd:attribute name="entryDateTime" type="xsd:dateTime" use="optional"/>
				<xsd:attribute name="status" type="xsd:string" use="optional"/>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>

derived from a complexType with simpleContent named DescriptionType:

        <xsd:complexType name="DescriptionType">
		<xsd:simpleContent>
			<xsd:extension base="xsd:string">
				<xsd:attribute name="languageID" type="xsd:language"/>
				<xsd:attribute name="type" type="xsd:string"/>
			</xsd:extension>
		</xsd:simpleContent>
	</xsd:complexType>

This compiles OK in Saxon when xsdversion is set to "1.0", but is rejected when xsdversion is set to "1.1". This is because XSD 1.1 corrects what was perceived to be a bug in 1.0: to quote a comment in the Saxon code:

                // this is a special case: see test particlesZ031. Although the user wrote
                // <complexContent>, extending a complex type with simple content with a null
                // extension appears (in XML Schema 1.0) to be a legitimate way of creating a complex type with
                // *simple* content. In 1.1 it violates Derivation Valid (Extension) - see bug 5943

The reference to Derivation Valid (Extension) is §3.4.6.2 of XSD 1.1 part 1 - the derivation is invalid because none of the conditions in clause 1.4 is satisfied. See https://www.w3.org/TR/xmlschema11-1/#sec-cos-ct-extends.

The reference to bug 5943 is to https://www.w3.org/Bugs/Public/show_bug.cgi?id=5943 ; the issue was raised again in the duplicate bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=6600

So the errors that Saxon is reporting when XSD 1.1 is enabled are legitimate, and it's your choice whether to fix the schema to conform to the 1.1 rules (which basically means changing <xs:complexContent> to <xs:simpleContent> in the identified cases) or to switch Saxon to run in XSD 1.0 mode.

Meanwhile, of course, Saxon shouldn't be crashing after reporting the errors.

Hi Michael,

Thanks for quick analysisng issue. Can you please provide us answer to below two questions?

1. When we can expect the patch in saxon 9.9?
2. What work around i can sugguest to customer? Do they have to replace some content in their XSD?

Thanks Bhupender

We hope to produce the next maintenance release within the next week.

However, the patch doesn't solve your problem, and isn't needed for you to make progress. As I explained, the underlying problem is that your schema relies on a feature/bug in XSD 1.0 that was fixed in XSD 1.1, so you either need to change the schema to use xs:simpleContent in place of xs:complexContent in the relevant extended types, or you need to run Saxon in XSD 1.0 mode.

Hi Michael,

Thanks for update. Do you have plan to provide this fix in XSD 1.1 mode? if yes what are the time lines.

Thanks Bhupender

The fix will ensure that Saxon doesn't crash after reporting the error.

I've no plans to change the underlying design: Saxon implements the XSD 1.1 specification by default, which makes this schema invalid, but has an XSD 1.0 mode in which the schema is valid.

Hi Michael,

Thanks for update. We will ocnsume 9.9.1.6

Thanks Bhupender

HI Michael, O'Neil,

After we consume latest saxon 9.9.1.6 we get the below exception.
An internal server error occured: Validation failed for: /xsd/SCHEMA_OAGIS_9.2_NotifyShipment.xsd fatal errors: [ org.xml.sax.SAXParseException: The schema is invalid, Line : -1, Column : -1 ]

This details looks unclear, it does not which line of XSD has issue?

Have i missed osmething to configure?

Thanks
Bhupender

Presumably you fixed the errors in the schema? So I don't know what your schema now looks like. It would probably be best if you raised this as a new issue, since the original crash was definitely fixed.

I made it clear in my previous responses that your schema is invalid, and the only effect of the Saxon patch is that it no longer crashes after reporting the invalidity. If you haven't changed the schema, then it is still invalid, and Saxon is behaving correctly by throwing an exception to report the fact,

The details of the actual errors in your schema are reported to the error listener; unless you do something to redirect them, this writes details to the system error stream. Usually it's simplest to run validation from the command line, or from an IDE such as oXygen, until you know that the schema is valid. If you use the s9api API to compile a schema and you aren't confident that it is error-free, you should make sure that you direct the error messages (ErrorListener output) to some suitable place).