Hi, I need some community inputs on the following: -
- I like to go forward with Frank's suggestion that the schemalocation be input to Java2WSDL along with the corresponding namespaces. Ofcourse this could make the commandline lengthy, but then may be we can have an XML Config File to capture all inputs to Java2WSDL. This will be optional... i.e. use either command line or xml config file. Any comments on this approach? - If during generation of the WSDL, the tool discovers that there is no schemalocation specified for a namespace that is to be imported then we print a message to the console but continue with the WSDL generation so that schemalocations could be later added. Can the schemalocation default to "*.xsd" when not specified? I see something of this sort in the XSDHelperImpl where when schemaLocaiton is not specified it is assumed to be "*.xsd". Thanks - Venkat On 7/13/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
Frank, I entirely endorse your viewpoint about the schemalocation. Yes, I think this must be input during deployment or during the time of running Java2WSDL. This would be more reliable than 'assuming' schemalocations annotated in the SDO Types. About the point on throwing an exception when isXSD(type) is true, I too perceive it as an approach that will safeguard data consistency. Especially from the following - "the generated XSD validates a different set of documents than the original XSD" and some sample round-trips that I tried I believe that this is important lest which the user will be caught unaware. Thanks. - Venkat On 7/12/06, Frank Budinsky <[EMAIL PROTECTED]> wrote: > > 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] > >
