Hi,
I've just been playing with the source generator with a schema I have to
write an app
around, and have noticed a bit of a problem with the way that castor
generates the
type classes for xs:enumerations in attribute restrictions. If one has
more than one
SimpleType in different elements, but with the same name only one of the
classes
gets generated becuase castor only names the class after the SimpleType.
E.g. If one has
<xs:element name="Element1">
<xs:complexType>
<xs:attribute name="thing" default="Something">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration
value="Something"/>
<xs:enumeration
value="SomethingElse"/>
<xs:enumeration
value="SomethingElseAgain"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="Element2">
<xs:complexType>
<xs:attribute name="thing" default="AnotherThing">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration
value="AnotherThing"/>
<xs:enumeration
value="YetAnotherThing"/>
<xs:enumeration
value="LotsOfThings"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
A class called ThingType will be generated, but only one! Whilst this
probably isn't a good piece of
schema design anyway, it is (it seems) legal, and I'm stuck with it...
I've made some changes to the source I've got here to solve the problem,
but I would appreciate
some comments from others on the way I've gone about it, as it smells of
hack to me.
What I've done is to bestow AttributeDecl with awareness of its parent (in
the form of a struct), and
have the source factory make the class name [element name][attribute
name]Type.java, if the
simple type in question happens to be inside an element.
If people want I'll dust off my somewhat shaky grasp of CVS and try and
post a diff file wilth my
changes.
Cheers,
Owen
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
