Hi Frank and others familiar with SDOs, could you please comment on the following: -
Based on some experiences with the first cut of Java2WSDL enhanced for SDOs posted in http://issues.apache.org/jira/browse/TUSCANY-120, I propose... - Not to generate XSDs for SDOs that have been originally generated from XSDs. Instead, make use of the source/ original XSD as is. Thus when a WSDL is generated for an interface involving SDO types that have been generated from XSDs, the original / source XSDs will be imported / included. Reasons ------------- - Impractical to generate an XSD from an SDO Type such that it is entirely consistent the one from which the SDOs were generated in the first place. - Eleminating redunancy of generating an XSD when it had already existed. - The specifications also suggest precisely this. SDO Implementation & Tooling. ----------------------------------------------------------------------- - To be able to use the original XSDs during WSDL generation, the XSD locations must be cached somewhere using their namespaces as the key. Later, when generating WSDL, for every SDO type encountered, the namespace URI for the SDO Type will be retrieved. Using this namespace as key, the corresponding XSD location will be retrieved from the cache and imported into the WSDL. Is this a right approach? What would be an ideal place to hold this map of namespaces vs schema locaitons? I understand that there are two ways of generating types out of XSDs i) thro the XSDHelper ii) thro the XSD2JavaInterfaceGenerator. Is there a confluence point for these two where the map could be held? - Also banking on the original XSD as the consistent model for the data throughout, makes sense only if the SDO serialization ensures that, if an SDO Type has been originally generated from an XSD then, the serialized data will always be valid instance of the XSD. Does the current implementation of SDO take care of this? Thanks. - Venkat
