History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: CASTOR-2284
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Sridhar Setti
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
castor

CodeGenerator not handling inheritence of simple types properly

Created: 30/Jan/08 12:53 PM   Updated: 19/Feb/08 05:01 PM
Component/s: XML code generator
Affects Version/s: 1.1.2.1
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: 1. XML File Sample.xsd (1 kb)

Environment: Windows XP Pro on Standalone JVM


 Description  « Hide
I am not sure if this is already addressed. When I searched I couldn't find this precise problem. Please correct me if I am wrong.

A simpletype based on xsd:string will not generate a class and will be of type java.lang.String. If a new simpletype is derived from the first using restriction and enumeration, a new class is generated but is not inherited from java.lang.String as it is not possible to.

Using these simpletypes will become impossible in a hierarchy of complextypes. The following schema sample highlights the problem. PartyRole is derived from ObjectRole. Both are simple types, but ObjectRole being just a string does not generated any class. PartyRole being enumeration generates a class. But PartyRole is derived from ObjectRole which is not clearly reflected in the java classes generated. We need simpletypes of this nature to use them in a hierachy of complex types, for e.g. Object, Party.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:simpleType name="ObjectRole">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType name="PartyRole">
<xsd:restriction base="ObjectRole">
<xsd:enumeration value="Person"/>
<xsd:enumeration value="Org"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="Object">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="Role" type="ObjectRole"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="BaseParty">
<xsd:simpleContent>
<xsd:extension base="Object">
<xsd:attribute name="Type" type="xsd:string"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="Party">
<xsd:simpleContent>
<xsd:restriction base="BaseParty">
<xsd:attribute name="Role" type="PartyRole"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
</xsd:schema>



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Werner Guttmann - 31/Jan/08 03:20 AM
I'll be looking into this post 1.2 release ...

Werner Guttmann - 31/Jan/08 03:20 AM
Btw, can you please attach the sample XML schema rather than inlining it (where some information might be lost) ?

Sridhar Setti - 07/Feb/08 04:13 PM
Attached the sample schema

Thanks a lot,
Sridhar


Werner Guttmann - 19/Feb/08 05:01 PM
I just had a look at this issue in detail, and I am afraid there's almost nothing that can be done to work around this XML/object mismatch so that we could meet your demand(s) right now.

We might be able to enter a discussion, though, to establish what could be done. I'd rather have this discussion elsewhere, though.e.g. the development mailing list.