Venkat,
The problem with schemaLocation is that it needs to be relative to the
importing WSDL or an absolute path in the deployment environment, so
keeping track of the path of the schema that was used to generate the
types in the development environment isn't useful. Instead the location
needs to be provided by the application (e.g., Java2WSDL) that knows where
things will be in the deployment environment. If you want the application
to use annotations on the Types to store the schemaLocation, that's
possible, but currently you'll need to use EMF APIs to do it. But I don't
think you necessarily know the runtime schemaLocation ahead of time
anyway.
My guess is that Java2WSDL should probably just generate an import
something like this:
<import namespace="the target namespace"/>
for types that XSDHelper.isXSD() returns true.
I also think Java2WSDL should allow users to specify schemaLocations for
their existing schemas. For example:
java2WSDL -location "some namespace" "some location" -location
"another namespace" "another location" ...
in which case you could generate imports with locations:
<import namespace="some namespace" location="some location"/>
I think this is the best approach, because it is when you're generating
the WSDL that you know where it and the corresponding XSDs are going to be
located. If the user, or some fancy tool, doesn't provide these locations,
then the runtime will need to be able to locate the imports without
schemaLocations, which some runtimes can. My guess is that Java2WSDL will
be the low level tool that more sophisticated generators will invoke, so
they would automatically manage and pass in the namespace/location
mappings.
That's my opinion anyway. Does anybody else have any thoughts on this
issue?
Frank
"Venkata Krishnan" <[EMAIL PROTECTED]>
07/12/2006 09:21 AM
Please respond to
[email protected]
To
[email protected]
cc
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]
