[ http://issues.apache.org/jira/browse/TUSCANY-515?page=comments#action_12419305 ]
Venkatakrishnan commented on TUSCANY-515: ----------------------------------------- Frank, I perfectly understand your perspective here about the 'no necessity' for this sort of round tripping. My intention is not about generating 'equal' xsds but only 'equivalent' ones without losing information and successful round-tripping is certainly not the end towards which I am working :-). Through this exercise, I am trying to understand if there are apsects of a data model encapsulated in an XSD that will go missing when encapsulated into SDOs. Take for example the case of mixed content. It is not an attribute of a type, but then it ends up as a property. Similar is the case of <xsd:choice> where there is not only a property named 'group' added to the SDO Type, the containing data type is also marked as open i.e. dataType.open=true. So a data model that is originally does not permit open content will now permit open content. One way by which I can identify what aspect of the original data model is missing or getting skewed is by generating the XSDs again and comparing them. I am not rigid about the equality of the definitions as along as they will produce similar xml instances. I have these issues in front of me (and may be more would crop up as you have predicted). If you mention them as genuine then I am only relieved that I have understood them rightly. But then, I would like to see if we could identify work-arounds to address them for now or should we just live with them. Thanks. > Augmenting / Modifying generated Java SDO Types to enable better conversion > to XSDs > ----------------------------------------------------------------------------------- > > Key: TUSCANY-515 > URL: http://issues.apache.org/jira/browse/TUSCANY-515 > Project: Tuscany > Type: Wish > Components: Java SDO Tools > Reporter: Venkatakrishnan > > I am working on enhancing the Java2WSDL to handle SDOs. One of the things > required in this is the mapping of SDO types to XSDs. > I am following the mapping rules specified in the Java SDO Spec. v2.0.1. Pg. > 107 onwards. > To try out, I picked up the sequences.xsd and generted the SDOs for that. > Next I run each SDO type thro' the tool I have implemented to generate the > XSDs. When I compare the resultant XSD with the original they are not > 'equivalent' in some cases (and I do understand that they will not be equal). > > To get over this incompatibility and arrive at a comparable XSD, the > generated SDOs must capture some additional information or maybe we must have > to change in certain parts, the way it is mapped from XSDs in the first > place. This might also mean that we might end up that the specs have to be > changed or enhanced in the first place. > Whatever be the future course I propose to track all issues related to > SDO-XSD mapping under this JIRA. For each point that I observe as an issue I > shall raise sub-tasks here, within. so that I do not scatter the JIRAs > related to this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
