Project

Profile

Help

Bug #4402

Cannot be cast to net.sf.saxon.type.ComplexType

Added by Bhupender Rathee 10 months ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Schema-Aware processing
Sprint/Milestone:
-
Start date:
2019-12-03
Due date:
% Done:

0%

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

Description

Hi Team,

We get below exception while loading XSD to SchemaManager object(schemaMgr.load(new StreamSource(xsd));) Exception which we get is:- net.sf.saxon.type.BuiltInAtomicType (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162d78) cannot be cast to net.sf.saxon.type.ComplexType (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162d78)

How do we know which element in XSD has issue ? How do we get more detail about this exception?

PFA:- XSD and payload

Thanks Bhupender

Content.zip (10.8 KB) Content.zip Bhupender Rathee, 2019-12-03 14:29
exception.PNG (13.1 KB) exception.PNG Bhupender Rathee, 2019-12-27 03:37

History

#1 Updated by Michael Kay 10 months ago

  • Category set to Schema-Aware processing
  • Assignee set to Michael Kay
  • Priority changed from Low to Normal

Thanks. The output I get on 9.9 is:

Saxon-EE 9.9.1.5J from Saxonica
Java version 1.8.0_121
Using license serial number K007537
Loading schema document file:/Users/mike/bugs/2019/4402-rathee/Content/XSD.xsd
Finished loading schema document file:/Users/mike/bugs/2019/4402-rathee/Content/XSD.xsd
Error on line 765 of XSD.xsd:
  The type Q{}NoteType has complex content so it cannot be derived by extension from the
  complex type Q{}DescriptionType which has simple content
Error on line 1136 of XSD.xsd:
  The type Q{}SequencedTextType has complex content so it cannot be derived by extension
  from the complex type Q{}TextType which has simple content
Error on line 184 of XSD.xsd:
  The type Q{}ConfirmationResponseCodeType has complex content so it cannot be derived by
  extension from the complex type Q{}ResponseCodeType which has simple content
Error on line 1115 of XSD.xsd:
  The type Q{}SequencedCodeType has complex content so it cannot be derived by extension
  from the complex type Q{}CodeType which has simple content
Error on line 1128 of XSD.xsd:
  The type Q{}SequencedIDType has complex content so it cannot be derived by extension from
  the complex type Q{}IdentifierType which has simple content
java.lang.ClassCastException: net.sf.saxon.type.BuiltInAtomicType cannot be cast to net.sf.saxon.type.ComplexType
	at com.saxonica.ee.schema.UserComplexType.makeExtendedParticle(UserComplexType.java:1842)
	at com.saxonica.ee.schema.UserComplexType.makeExtendedParticle(UserComplexType.java:1871)
	at com.saxonica.ee.schema.UserComplexType.compile(UserComplexType.java:1715)
	at com.saxonica.ee.schema.ElementParticle.compile(ElementParticle.java:228)
	at com.saxonica.ee.schema.ModelGroup.compile(ModelGroup.java:542)
	at com.saxonica.ee.schema.ModelGroupParticle.compile(ModelGroupParticle.java:276)
	at com.saxonica.ee.schema.UserComplexType.compile(UserComplexType.java:1754)
	at com.saxonica.ee.schema.UserComplexType.validate(UserComplexType.java:993)
	at com.saxonica.ee.schema.ElementDecl.validate(ElementDecl.java:910)
	at com.saxonica.ee.schema.ElementParticle.validate(ElementParticle.java:207)
	at com.saxonica.ee.schema.ModelGroup.validate(ModelGroup.java:284)
	at com.saxonica.ee.schema.SequenceModelGroup.validate(SequenceModelGroup.java:45)
	at com.saxonica.ee.schema.ModelGroup.validate(ModelGroup.java:275)
	at com.saxonica.ee.schema.SequenceModelGroup.validate(SequenceModelGroup.java:45)
	at com.saxonica.ee.schema.ModelGroupParticle.validate(ModelGroupParticle.java:245)
	at com.saxonica.ee.schema.UserComplexType.validate(UserComplexType.java:936)
	at com.saxonica.ee.schema.ElementDecl.validate(ElementDecl.java:910)
	at com.saxonica.ee.schema.ElementParticle.validate(ElementParticle.java:207)
	at com.saxonica.ee.schema.ModelGroup.validate(ModelGroup.java:284)
	at com.saxonica.ee.schema.SequenceModelGroup.validate(SequenceModelGroup.java:45)
	at com.saxonica.ee.schema.ModelGroupParticle.validate(ModelGroupParticle.java:245)
	at com.saxonica.ee.schema.UserComplexType.validate(UserComplexType.java:936)
	at com.saxonica.ee.schema.ElementDecl.validate(ElementDecl.java:910)
	at com.saxonica.ee.schema.ElementParticle.validate(ElementParticle.java:207)
	at com.saxonica.ee.schema.PreparedSchema.validate(PreparedSchema.java:1014)
	at com.saxonica.ee.schema.SchemaCompiler.compile(SchemaCompiler.java:504)
	at com.saxonica.ee.schema.SchemaCompiler.validate(SchemaCompiler.java:538)
	at com.saxonica.config.EnterpriseConfiguration.addSchemaSource(EnterpriseConfiguration.java:695)
	at com.saxonica.ee.s9api.SchemaManagerImpl.load(SchemaManagerImpl.java:118)
	at com.saxonica.Validate.doValidate(Validate.java:329)
	at com.saxonica.Validate.main(Validate.java:58)
Fatal error during validation: net.sf.saxon.type.BuiltInAtomicType cannot be cast to net.sf.saxon.type.ComplexType

Process finished with exit code 2

I would suggest start by fixing the schema errors that are reported before it crashes. Saxon tries to keep going after reporting errors in the schema, so that it can find as many errors as possible in a single run, but when the internal data structures don't represent a valid schema there's always a risk of this kind of crash.

#2 Updated by Michael Kay 10 months ago

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.

#3 Updated by Michael Kay 10 months ago

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.

#4 Updated by Michael Kay 10 months ago

  • Status changed from New to Resolved
  • Applies to branch 9.8, 9.9, trunk added
  • Fix Committed on Branch 9.8, 9.9, trunk added

Preventing the crash seems to be a simple matter of checking before entering the "compile" phase for a complex type that the validation phase was successful: a simple test at the start of UserComplexType.compile(). I will commit this patch on the 9.8, 9.9, and development branches (though it's becoming highly unlikely we will do another build on the 9.8 branch).

#5 Updated by Bhupender Rathee 10 months ago

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

#6 Updated by Michael Kay 10 months ago

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.

#7 Updated by Bhupender Rathee 10 months ago

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

#8 Updated by Michael Kay 10 months ago

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.

#9 Updated by O'Neil Delpratt 10 months ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.9.1.6 added

Patch committed to the Saxon 9.9.1.6 maintenance release.

#10 Updated by Bhupender Rathee 9 months ago

Hi Michael,

Thanks for update. We will ocnsume 9.9.1.6

Thanks Bhupender

#11 Updated by Bhupender Rathee 9 months ago

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

#12 Updated by Michael Kay 9 months ago

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.

#13 Updated by Bhupender Rathee 9 months ago

Hi Michael,

We have not modified the schema, hence the schema is same as attached above Original exception which we get on call of load is "SaxonAPIException"(Also attached)

Can you please share details what you get now with latest saxon version?

Thanks Bhupender

#14 Updated by Michael Kay 9 months ago

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).

Please register to edit this issue

Also available in: Atom PDF