Hi Frank, I have changed the implementation of XSDHelper.define to this effect. Just to recap this.. here is what I do...
if ( isXSD(type) ) throw IllegalArgumentException; else go ahead and generate the XSD. There is a patch of XSDHelper.define that I had submitted under JIRA-535. I shall update that patch for this and re-post it again. Please have a look to see if it is ok. Getting back to the case when the XSD for a SDO Type exists, how can we extract this XSD information given an SDO Type. If the schemalocation for the XSD must be available whenever a generated SDO type is loaded by a program like the Java2WSDL tool, then I cannot see anyother way of doing this than adding shcema informatoin as some annotation to the generated code. Can you please help me with some advice on how to get this done? Thanks. - Venkat On 7/11/06, Frank Budinsky <[EMAIL PROTECTED]> wrote:
Hi Venkat, Since XSDHelper.generate() says this in the JavaDoc: * Round trip from XSD to SDO to XSD is not supported. * Use the original schema if one exists instead of generating a new one, as * the generated XSD validates a different set of documents than the original XSD. and also this: * @throws IllegalArgumentException if the XSD could not be generated. I would say that XSDHelper.generate() should throw IllegalArgumentException in this case: if (isXSD(type) ) throw new IllegalArgumentException(); So that leaves the rest up to the Tuscany Java2WSDL command. > - 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? Yes. Frank. "Venkata Krishnan" <[EMAIL PROTECTED]> wrote on 07/11/2006 01:06:21 PM: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
