Hi Venkat, The main problem seems to be related to the fact that we currently include special properties like "mixed", "group", "any", etc. We plan to change this in the next few weeks, so the problems you're having related to them should go away.
The other problem is that the XSD generation described in the spec will generate a reasonable Schema for SDO types, but since SDO types don't capture all the necessary XSD metadata, types that are originally created from an XML Schema won't roundtrip back to the same schema. If we want them to, then we need to add annotations to the SDO metadata to modify the XSD generators output. Have you looked at how EMF's XSD generator supports schema-ecore-schema roundtripping? If we want to, we can try to support roundtripping in Tuscany with some implementation-specific apis and then look at proposing extensions to the spec in the future. Frank. "Venkata Krishnan" <[EMAIL PROTECTED]> wrote on 06/23/2006 09:52:34 AM: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
