The SDO spec is vague on this issue. I believe that a perfectly reasonable interpretation is to throw an exception in generate (because it can't generate the "correct" schema). I think that Java2WSDL can choose to optionally generate a schema for these types, but not by calling XSDHelper.generate() - we could have a Tuscany internal method that does it if you want. But, I think you need to be very careful when you generate multiple versions of the same metadata. You're asking for trouble when you have more than one version of the same schema types floating around.
Frank. "Raymond Feng" <[EMAIL PROTECTED]> wrote on 07/12/2006 12:35:12 PM: > Hi, > > Do we want to fully disable the XSD generation from a SDO Type initially > loaded from XSD? My impression of the spec is that you can still use > XSDHelper.generate(Type) but the result could be different than the orginal > XSD (XSD1 --> SDO Type --> XSD2). Maybe for Java2WSDL, we should have an > option to tell if we try to reversely generate XSD from the Type or just > produce "xsd:import". > > Thanks, > Raymond > > ----- Original Message ----- > From: "Venkata Krishnan" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Wednesday, July 12, 2006 6:21 AM > Subject: Re: SDO support for Java2WSDL > > > > 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] > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
