You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Venkata Krishnan <fo...@gmail.com> on 2006/07/11 19:06:21 UTC
SDO support for Java2WSDL
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
Re: SDO support for Java2WSDL
Posted by Venkata Krishnan <fo...@gmail.com>.
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 <fo...@gmail.com> 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 <fr...@ca.ibm.com> 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" < enjoyjava@gmail.com> 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" <for.svkrish@gmail.com >
> > > To: <tu...@ws.apache.org>
> > > 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 <fr...@ca.ibm.com> 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" <fo...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >>
> > > >>
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: SDO support for Java2WSDL
Posted by Venkata Krishnan <fo...@gmail.com>.
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 <fr...@ca.ibm.com> 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" <en...@gmail.com> 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" <fo...@gmail.com>
> > To: <tu...@ws.apache.org>
> > 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 <fr...@ca.ibm.com> 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" <fo...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: SDO support for Java2WSDL
Posted by Frank Budinsky <fr...@ca.ibm.com>.
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" <en...@gmail.com> 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" <fo...@gmail.com>
> To: <tu...@ws.apache.org>
> 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 <fr...@ca.ibm.com> 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" <fo...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO support for Java2WSDL
Posted by Raymond Feng <en...@gmail.com>.
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" <fo...@gmail.com>
To: <tu...@ws.apache.org>
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 <fr...@ca.ibm.com> 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" <fo...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO support for Java2WSDL
Posted by Frank Budinsky <fr...@ca.ibm.com>.
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" <fo...@gmail.com>
07/12/2006 09:21 AM
Please respond to
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
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 <fr...@ca.ibm.com> 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" <fo...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO support for Java2WSDL
Posted by Venkata Krishnan <fo...@gmail.com>.
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 <fr...@ca.ibm.com> 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" <fo...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: SDO support for Java2WSDL
Posted by Frank Budinsky <fr...@ca.ibm.com>.
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" <fo...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org