xjc derivation by extension/restriction

[Tomas-Kraus]

Hi,

xjc produces this error when compiling the schema below. this issue does seem to relate to issue 149, but in this case the content of the 3 involved types does not appear to be conflicting in any way....

Base complex type "Response" is derived by restriction, while this complex type "MyResponse" is derived by extension. This is not currently handled by XJC, but we are seeking input on this issue. Please report this to the JAXB team.<<<

cheers, dk #### Environment Operating System: Windows XP Platform: PC #### Affected Versions [2.2]

[Tomas-Kraus]

• Issue Imported From: https://github.com/javaee/jaxb-v2/issues/745
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot

[Tomas-Kraus]

@glassfishrobot Commented Reported by dkodko

[Tomas-Kraus]

@glassfishrobot Commented snajper said: Thanks for submission, will look into it.

[Tomas-Kraus]

@glassfishrobot Commented kameleono said: I have been exposed to the same problem when trying to generate Java code for the JDF Schema (http://www.cip4.org/).

Since no single attribute nor element was being redefined by the extension of the restriction, I modified the code in the class com.sun.tools.xjc.reader.xmlschema.ct.AbstractExtendedComplexTypeBuilder for the checkIfExtensionSafe method.

It now compiles the example from the following book: http://www.datypic.com/books/defxmlschema/chapter14.html

As far as the JDF Schema is concerned, there are some other limitations that became apparent.

[Tomas-Kraus]

@glassfishrobot Commented mwarden said: We manage the Ed-Fi education data interchange standard [1] and have received reports from a state trying to use our standard with XJC, and this report seems to align with this Issue. I am commenting in order to explain the use case, as the error message reported in this situation implies the team would like to better understand why this use case occurs.

We have a standard core XSD that defines a large set of complex types for use in standard interchanges of data. For example, we define a a complex type named TeacherSchoolAssociation for use in an interchange that reports assignment and employment relationships for teachers to school buildings. Both the type and the interchange structure are part of our standard.

However, there may be optional elements in our standard core for TeacherSchoolAssociation that have no relevance for a given state, and they would like to remove these elements via a restriction. Similarly, individual states have additional things they will need to report that are specific to that state and do not make sense to add to the standard for all states, and they would like to add these elements via an extension.

Therefore we create a new XSD, e.g. OH-Core that includes the Ed-Fi-Core. We first restrict types to remove unnecessary optional children. We then extend types to add in state-specific children. This is valid per the specification and works fine in other processors.

Here is the exact error we get in this situation (modified slightly – the state that reported is not Ohio):

xjc -xmlschema .\schemas\OH-ServiceEnvelope-StudentProfileEnrollment.xsd -d code -p com.edfi.oh.xchange parsing a schema... [ERROR] Base complex type "OH-TeacherSchoolAssociationRestriction" is derived by restriction, while this complex type "OH-TeacherSchoolAssociationExtension" is derived by extension. This is not currently handled by XJC, but we are seeking input on this issue. Please report this to the JAXB team. line 835 of file:/C:/Docum.../jaxb_schemas/schemas/OH-Ed-Fi-Core-Extension.xsd

I would be happy to provide any additional details about this use case. Additionally, I would be happy to discuss whether an alternative pattern to achieve the same flexibility might be more appropriate for XJC users.

[1] Ed-Fi, a K-12 education data interchange standard offered by the Michael and Susan Dell Foundation, http://www.ed-fi.org/

[Tomas-Kraus]

@glassfishrobot Commented File: AbstractExtendedComplexTypeBuilder.java Attached By: kameleono

[Tomas-Kraus]

@glassfishrobot Commented Was assigned to jaxb-issues

[Tomas-Kraus]

@glassfishrobot Commented This issue was imported from java.net JIRA JAXB-745