Hello Frank, Raymond and Jean
I have attached a first cut of the XSD Generator under JIRA-120 and am
looking for some comments on the approach therein. For the SDOs I have used
the XSD2JavaGenerator from the sdo-tools project using the sequences.xsd as
input.
I am simply following what is laid out in the SDO Spec v 2.0.1 in the
section Generation of XSD from SDO Type and Property from 107. Here are
some issues that I have come across upto now with a part of the specs
implemented.
Issues
----------
1) When a complex type allows mixed content i.e. has the attribute
'mixed=true' the SDO's type.sequenced is rightly set to true. However in
addition to this, there is a property named 'mixed' that is added to the SDO
Type.
Issue : When the SDO is used to generate an XSD this property 'mixed' ends
up as an element within a complex type.
2) On Pg 109 of the SDO spec. states that when SDOType.sequenced is true
then add the attritbute mixed="true" to the complex type and the element
<xsd:choice maxOccurs="unbounded">. Why is this a choice and not a
sequence?
Issue: The MixedQuote complex type in sequences.xsd for which I generated
the SDOs is of mixed content but the group within this complex type is a
'sequence' and not a choice. i.e.
<<xsd:sequence>.
Question : Is this something that must be fixed in the specs or....
3)For <xsd:choice> the generated SDO includes a property named 'group'. If
there are more than on <xsd:choice> elements then, there are as many
properties named as group1, group2 etc. Further the SDO.Type.isOpen is set
to 'true' for the SDO that contains these properties
Issue : As in the case of 'mixed' here also, having a property within the
SDO results in an xsd with elememts named 'group', 'group1' etc. with the
property.isMany = true;
Issue: Since the SDO.Type.isOpen is set to true when the SDO is used to
generate the xsd, there is an additional element <xs:any
processContents="lax" maxOccurs="unbounded" /> that is generated since it is
assumed to be open content.
Issue: The elements within the <xsd:choice> also become properties of the
SDO and hence the grouping information is lost. i.e. for the xsd
<xsd:choice maxOccurs="unbounded" minOccurs="0">
<xsd:element name="a" type="xsd:string" />
<xsd:element name="b" type="xsd:int" />
</xsd:choice>
there are three properties added to the SDO.Type namely group, a and b.
When the SDO is used to generate the xsd again, there are three elements
generated. Here is the final output.
<xs:sequence>
<xs:any processContents="lax" maxOccurs="unbounded" />
<xs:element minOccurs="0" name="group"
maxOccurs="unbounded" />
<xs:element minOccurs="0" type="xs:string" name="a"
maxOccurs="unbounded" />
<xs:element minOccurs="0" type="xs:int" name="b"
maxOccurs="unbounded" />
</xs:sequence>
The information about what elements are under the <xsd:choice> is not
available in the SDO.
Question : Is the XSD2SDO generation right? Is this something that must be
fixed in the specs. or is it wrong intepretation of the XSDGenerator that I
have developed
I shall go ahead and address the other items in the specs as well and shall
probably get back with some more of these.
Thanks.
- Venkat
