You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Venkata Krishnan <fo...@gmail.com> on 2006/06/23 15:52:34 UTC
SDO2XSD Generator@JIRA-120
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
Re: SDO2XSD Generator@JIRA-120
Posted by Frank Budinsky <fr...@ca.ibm.com>.
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" <fo...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org