castor

xml schema polymorphism and source generator

Details

  • Type: Bug Bug
  • Status: Reopened Reopened
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 1.3
  • Fix Version/s: 1.3.4
  • Component/s: XML code generator
  • Labels:
    None
  • Testcase included:
    yes
  • Number of attachments :
    1

Description

From the conversation in the castro dev mailing list:

I have another question today.

How can i handle a xsd polymorphism like described in

http://www.xml.com/pub/a/2003/10/29/derivation.html

I cannot change the xml schema, its designed one of our costumer.

The problem is that i can create a bas complexType A1 with child-elements B and C. And complexType A2 is extends complexType A1 and then i can overwrite its child-types and/or how many the child occur.

A1
B type="int" maxOccur="unbounded"
C type="string"

A2 extends A1
B type="date"
C type="int"

The problem for the source-generator is, that he generates a method for element A1.getB() returns int[] and for A2.getB() returns a date.

Any hints to resolve this problem? Can i use a binding file to resolve this?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
azgard added a comment -

Provide a test case for this - look at comments in pom.xml.

Show
azgard added a comment - Provide a test case for this - look at comments in pom.xml.
Hide
Permalink
Werner Guttmann added a comment -

Hi, just had a look at your XML schema, and there's a few things I observed. It looks like you have not fully understood the restrictions on how an <xs:restriction> can be used on <xs:complexType> definitions. Here's a the output on using a validating XML parses on your sample XML schema:

  • complex type C:
Multiple annotations found at this line:
	- derivation-ok-restriction.5.4.2: Error for type 'C'. The particle of the type is not a valid 
	 restriction of the particle of the base.
	- rcase-NameAndTypeOK.3: Error for the particle whose {term} is the element declaration 
	 'B'. Its occurrence range, (0,unbounded), is not a valid restriction of the range, (0,1, of the 
	 corresponding particle in the base type.
  • complex type D:
Multiple annotations found at this line:
	- derivation-ok-restriction.5.4.2: Error for type 'D'. The particle of the type is not a valid 
	 restriction of the particle of the base.
	- rcase-NameAndTypeOK.7: The type of element 'B', 'date', is not derived from the type 
	 of the base element, 'integer'.
  • complex type E
Multiple annotations found at this line:
	- rcase-NameAndTypeOK.3: Error for the particle whose {term} is the element declaration 
	 'B'. Its occurrence range, (0,unbounded), is not a valid restriction of the range, (0,1, of the 
	 corresponding particle in the base type.
	- derivation-ok-restriction.5.4.2: Error for type 'E'. The particle of the type is not a valid 
	 restriction of the particle of the base.

I hope that the error messages are self-explanatory.

Show
Werner Guttmann added a comment - Hi, just had a look at your XML schema, and there's a few things I observed. It looks like you have not fully understood the restrictions on how an <xs:restriction> can be used on <xs:complexType> definitions. Here's a the output on using a validating XML parses on your sample XML schema: complex type C: Multiple annotations found at this line: - derivation-ok-restriction.5.4.2: Error for type 'C'. The particle of the type is not a valid restriction of the particle of the base. - rcase-NameAndTypeOK.3: Error for the particle whose {term} is the element declaration 'B'. Its occurrence range, (0,unbounded), is not a valid restriction of the range, (0,1, of the corresponding particle in the base type. complex type D: Multiple annotations found at this line: - derivation-ok-restriction.5.4.2: Error for type 'D'. The particle of the type is not a valid restriction of the particle of the base. - rcase-NameAndTypeOK.7: The type of element 'B', 'date', is not derived from the type of the base element, 'integer'. complex type E Multiple annotations found at this line: - rcase-NameAndTypeOK.3: Error for the particle whose {term} is the element declaration 'B'. Its occurrence range, (0,unbounded), is not a valid restriction of the range, (0,1, of the corresponding particle in the base type. - derivation-ok-restriction.5.4.2: Error for type 'E'. The particle of the type is not a valid restriction of the particle of the base. I hope that the error messages are self-explanatory.
Hide
Permalink
azgard added a comment -

Thanks a lot. This was my fault.

The problem was, that i got schemas from a german institution and i was unconcerned about that schemas can have errors.

After i validate the schemas i got the same errors like in the submited test schema.

Show
azgard added a comment - Thanks a lot. This was my fault. The problem was, that i got schemas from a german institution and i was unconcerned about that schemas can have errors. After i validate the schemas i got the same errors like in the submited test schema.
Hide
Permalink
Werner Guttmann added a comment -

No worries. Always glad to help if things are so easy.

Show
Werner Guttmann added a comment - No worries. Always glad to help if things are so easy.
Hide
Permalink
azgard added a comment -

Sorry, i must reopen the issue.

Now i have attached a valid schema with the described problem.

Werner, can you please test it?

Show
azgard added a comment - Sorry, i must reopen the issue. Now i have attached a valid schema with the described problem. Werner, can you please test it?
Hide
Permalink
Werner Guttmann added a comment -

Yes, I can confirm that this is a problem with Castor, indeed.

Show
Werner Guttmann added a comment - Yes, I can confirm that this is a problem with Castor, indeed.
Hide
Permalink
azgard added a comment -

Hello Werner, any news around this issue? Does a workaround exists?

Show
azgard added a comment - Hello Werner, any news around this issue? Does a workaround exists?
Hide
Permalink
Werner Guttmann added a comment -

No, there's unfortunately no work-around. I had a very close look yesterday, and tried several alternative scenarious (e.g. decreasing the upper bound to 4 instead of unbounded), and it looks like the problem only occurs if you are switching from multi-valued to singe-valuedness.

I have a test case working where I have manually amended the descriptor class(es) so that everything works, but I still have to figure out how to change the code base to have this automated.

Fwiw, this is not an easy bug fix, as I expect another 4 to 8 hours of coding/testing/integration testing. In other words, this won't happen tomorrow.

Show
Werner Guttmann added a comment - No, there's unfortunately no work-around. I had a very close look yesterday, and tried several alternative scenarious (e.g. decreasing the upper bound to 4 instead of unbounded), and it looks like the problem only occurs if you are switching from multi-valued to singe-valuedness. I have a test case working where I have manually amended the descriptor class(es) so that everything works, but I still have to figure out how to change the code base to have this automated. Fwiw, this is not an easy bug fix, as I expect another 4 to 8 hours of coding/testing/integration testing. In other words, this won't happen tomorrow.

People

  • Assignee:
    Werner Guttmann
    Reporter:
    azgard
Vote (1)
Watch (1)

Dates

  • Created:
    Updated: