You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Scott Kurz <sc...@gmail.com> on 2007/04/09 17:11:05 UTC
Basic SDO question: no built-in types?
This is maybe an SDO for dummies question.
Are there any built-in SDO types, say, corresponding to int which I can
work with as a generic DataObject in the manner that java.lang.Integer is a
java.lang.Object
corresponding to int? (I'm not seeing anything from a quick scan of the
source or spec to suggest that there is.)
Or is the simplest DataObject one can create a user-defined, complexType
wrappering a single int?
Thanks,
Scott
Re: Basic SDO question: no built-in types?
Posted by Ole Ersoy <ol...@gmail.com>.
Kelvin,
Brilliant article. Just in time too :-).
It will really come in handy when I start coding
the "Restore DataObject MetaData" part of the LDAP DAS.
Thanks again,
- Ole
kelvin goodson wrote:
> Ole,
> glad to be of help. I was a bit worried that the different perspectives
> from which Frank and I responded might cause confusion, but you seem to be
> happy marrying the two responses together. Just to be clear, from the SDO
> perspective, in the context we are discussing the EPackage does 2
> orthogonal
> things that are handled separately in SDO. One is to aggregate and provide
> access to the type system, and the other to bestow the namespace uri upon
> the types it contains. I answered from the perspective of the first and
> Frank from the second.
>
> BTW, page 2 of the recently published "What is SDO? Part 2" paper has a
> description of how to create types dynamically using the SDO API.
> http://java.sys-con.com/read/358059_2.htm
>
>
> Regards, Kelvin.
>
>
> On 10/04/07, Ole Ersoy <ol...@gmail.com> wrote:
>>
>> Kelvin, Frank,
>>
>> Great - Thanks for all the insight. I wrote
>> most of the DAS LDAP Design Guide using references
>> to EMF concepts, so I'll start using this to convert over.
>>
>> Thanks again,
>> - Ole
>>
>> kelvin goodson wrote:
>> > Ole,
>> > the HelperContext acts as a high level scope for types. To create
>> types
>> > dynamically using the SDO 2.1 API you would get the TypeHelper instance
>> > from
>> > a HelperContext instance and use one of the TypeHelper.define
>> methods to
>> > create types within the scope of the HelperContext.
>> >
>> > There is also Tuscany specific interface on the SDOUtil class that
>> allows
>> > creation of types more in the style you show above, using a TypeHelper
>> > instance to control the scope of the new types. In this case the new
>> types
>> > are available to the HelperContext to which the TypeHelper instance
>> > belongs,
>> > and all its associated helpers.
>> >
>> > The SDO API variant method offers solutions to the issues encountered
>> when
>> > creating type systems which have cross references, which can't be
>> achieved
>> > with the Tuscany interface. It also deals with achieving a state
>> whereby a
>> > newly created type is known to be finalized. The Tuscany API is a
>> quick
>> > method for defining types when these considerations are not important.
>> >
>> > Regards, Kelvin.
>> >
>> > On 09/04/07, Ole Ersoy <ol...@gmail.com> wrote:
>> >>
>> >> Hope it's ok that I piggy back with a somewhat related question.
>> >>
>> >> Does SDO a container for Type instances (the equivalent to an EMF
>> >> EPackage)?
>> >>
>> >> In the EMF API I would do something like
>> >>
>> >> DataType dataType = EcoreFactory.eINSTANCE.createDataType();
>> >> //Initialize the dataType
>> >> //Add it to an ePackage containing all the model's Types
>> >> ePackage.eClassifiers.add(dataType);
>> >>
>> >> Thanks,
>> >> - Ole
>> >>
>> >>
>> >>
>> >> Scott Kurz wrote:
>> >> > Thanks Fuhwei, Frank that helps me under the SDO view of the
>> built-in
>> >> > types.
>> >> >
>> >> > I wonder how useful it would be to allow WSDL2Java to generate a
>> Type,
>> >> > then,
>> >> > instead of an int or String, when the "-dynamicSDO" option is
>> chosen.
>> >> >
>> >> > There would need to be some runtime databinding-sdo support for this
>> >> option
>> >> > too, I'd think.
>> >> >
>> >> > Interesting but I'm probably going to drop this train of thought for
>> >> now...
>> >> >
>> >> > Scott
>> >> >
>> >> > On 4/9/07, Fuhwei Lwo <fu...@bricemedia.com> wrote:
>> >> >>
>> >> >> Scott,
>> >> >>
>> >> >> SDO built-in types were defined in the sdoModel.xsd under
>> >> >> tuscany/java/spec/sdo-api/src/main/resources/xml directory. The
>> >> >> mapping from
>> >> >> XSD to Java is described in the spec section 9.4.
>> >> >>
>> >> >> The instances of SDO built-in types will be instances of
>> >> >> commonj.sdo.Type.
>> >> >> So if you have a SDO type for xsd:int, the name of the
>> >> >> commonj.sdo.Typeinstance will be "Int".
>> >> >>
>> >> >> Hope this helps.
>> >> >>
>> >> >> Scott Kurz <sc...@gmail.com> wrote: This is maybe an SDO for
>> >> dummies
>> >> >> question.
>> >> >>
>> >> >> Are there any built-in SDO types, say, corresponding to int
>> which I
>> >> can
>> >> >> work with as a generic DataObject in the manner that
>> >> java.lang.Integeris
>> >> >> a
>> >> >> java.lang.Object
>> >> >> corresponding to int? (I'm not seeing anything from a quick
>> scan of
>> >> the
>> >> >> source or spec to suggest that there is.)
>> >> >>
>> >> >> Or is the simplest DataObject one can create a user-defined,
>> >> complexType
>> >> >> wrappering a single int?
>> >> >>
>> >> >> Thanks,
>> >> >> Scott
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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: Basic SDO question: no built-in types?
Posted by kelvin goodson <ke...@gmail.com>.
Ole,
glad to be of help. I was a bit worried that the different perspectives
from which Frank and I responded might cause confusion, but you seem to be
happy marrying the two responses together. Just to be clear, from the SDO
perspective, in the context we are discussing the EPackage does 2 orthogonal
things that are handled separately in SDO. One is to aggregate and provide
access to the type system, and the other to bestow the namespace uri upon
the types it contains. I answered from the perspective of the first and
Frank from the second.
BTW, page 2 of the recently published "What is SDO? Part 2" paper has a
description of how to create types dynamically using the SDO API.
http://java.sys-con.com/read/358059_2.htm
Regards, Kelvin.
On 10/04/07, Ole Ersoy <ol...@gmail.com> wrote:
>
> Kelvin, Frank,
>
> Great - Thanks for all the insight. I wrote
> most of the DAS LDAP Design Guide using references
> to EMF concepts, so I'll start using this to convert over.
>
> Thanks again,
> - Ole
>
> kelvin goodson wrote:
> > Ole,
> > the HelperContext acts as a high level scope for types. To create
> types
> > dynamically using the SDO 2.1 API you would get the TypeHelper instance
> > from
> > a HelperContext instance and use one of the TypeHelper.define methods to
> > create types within the scope of the HelperContext.
> >
> > There is also Tuscany specific interface on the SDOUtil class that
> allows
> > creation of types more in the style you show above, using a TypeHelper
> > instance to control the scope of the new types. In this case the new
> types
> > are available to the HelperContext to which the TypeHelper instance
> > belongs,
> > and all its associated helpers.
> >
> > The SDO API variant method offers solutions to the issues encountered
> when
> > creating type systems which have cross references, which can't be
> achieved
> > with the Tuscany interface. It also deals with achieving a state
> whereby a
> > newly created type is known to be finalized. The Tuscany API is a quick
> > method for defining types when these considerations are not important.
> >
> > Regards, Kelvin.
> >
> > On 09/04/07, Ole Ersoy <ol...@gmail.com> wrote:
> >>
> >> Hope it's ok that I piggy back with a somewhat related question.
> >>
> >> Does SDO a container for Type instances (the equivalent to an EMF
> >> EPackage)?
> >>
> >> In the EMF API I would do something like
> >>
> >> DataType dataType = EcoreFactory.eINSTANCE.createDataType();
> >> //Initialize the dataType
> >> //Add it to an ePackage containing all the model's Types
> >> ePackage.eClassifiers.add(dataType);
> >>
> >> Thanks,
> >> - Ole
> >>
> >>
> >>
> >> Scott Kurz wrote:
> >> > Thanks Fuhwei, Frank that helps me under the SDO view of the built-in
> >> > types.
> >> >
> >> > I wonder how useful it would be to allow WSDL2Java to generate a
> Type,
> >> > then,
> >> > instead of an int or String, when the "-dynamicSDO" option is chosen.
> >> >
> >> > There would need to be some runtime databinding-sdo support for this
> >> option
> >> > too, I'd think.
> >> >
> >> > Interesting but I'm probably going to drop this train of thought for
> >> now...
> >> >
> >> > Scott
> >> >
> >> > On 4/9/07, Fuhwei Lwo <fu...@bricemedia.com> wrote:
> >> >>
> >> >> Scott,
> >> >>
> >> >> SDO built-in types were defined in the sdoModel.xsd under
> >> >> tuscany/java/spec/sdo-api/src/main/resources/xml directory. The
> >> >> mapping from
> >> >> XSD to Java is described in the spec section 9.4.
> >> >>
> >> >> The instances of SDO built-in types will be instances of
> >> >> commonj.sdo.Type.
> >> >> So if you have a SDO type for xsd:int, the name of the
> >> >> commonj.sdo.Typeinstance will be "Int".
> >> >>
> >> >> Hope this helps.
> >> >>
> >> >> Scott Kurz <sc...@gmail.com> wrote: This is maybe an SDO for
> >> dummies
> >> >> question.
> >> >>
> >> >> Are there any built-in SDO types, say, corresponding to int which I
> >> can
> >> >> work with as a generic DataObject in the manner that
> >> java.lang.Integeris
> >> >> a
> >> >> java.lang.Object
> >> >> corresponding to int? (I'm not seeing anything from a quick scan of
> >> the
> >> >> source or spec to suggest that there is.)
> >> >>
> >> >> Or is the simplest DataObject one can create a user-defined,
> >> complexType
> >> >> wrappering a single int?
> >> >>
> >> >> Thanks,
> >> >> Scott
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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: Basic SDO question: no built-in types?
Posted by Ole Ersoy <ol...@gmail.com>.
Kelvin, Frank,
Great - Thanks for all the insight. I wrote
most of the DAS LDAP Design Guide using references
to EMF concepts, so I'll start using this to convert over.
Thanks again,
- Ole
kelvin goodson wrote:
> Ole,
> the HelperContext acts as a high level scope for types. To create types
> dynamically using the SDO 2.1 API you would get the TypeHelper instance
> from
> a HelperContext instance and use one of the TypeHelper.define methods to
> create types within the scope of the HelperContext.
>
> There is also Tuscany specific interface on the SDOUtil class that allows
> creation of types more in the style you show above, using a TypeHelper
> instance to control the scope of the new types. In this case the new types
> are available to the HelperContext to which the TypeHelper instance
> belongs,
> and all its associated helpers.
>
> The SDO API variant method offers solutions to the issues encountered when
> creating type systems which have cross references, which can't be achieved
> with the Tuscany interface. It also deals with achieving a state whereby a
> newly created type is known to be finalized. The Tuscany API is a quick
> method for defining types when these considerations are not important.
>
> Regards, Kelvin.
>
> On 09/04/07, Ole Ersoy <ol...@gmail.com> wrote:
>>
>> Hope it's ok that I piggy back with a somewhat related question.
>>
>> Does SDO a container for Type instances (the equivalent to an EMF
>> EPackage)?
>>
>> In the EMF API I would do something like
>>
>> DataType dataType = EcoreFactory.eINSTANCE.createDataType();
>> //Initialize the dataType
>> //Add it to an ePackage containing all the model's Types
>> ePackage.eClassifiers.add(dataType);
>>
>> Thanks,
>> - Ole
>>
>>
>>
>> Scott Kurz wrote:
>> > Thanks Fuhwei, Frank that helps me under the SDO view of the built-in
>> > types.
>> >
>> > I wonder how useful it would be to allow WSDL2Java to generate a Type,
>> > then,
>> > instead of an int or String, when the "-dynamicSDO" option is chosen.
>> >
>> > There would need to be some runtime databinding-sdo support for this
>> option
>> > too, I'd think.
>> >
>> > Interesting but I'm probably going to drop this train of thought for
>> now...
>> >
>> > Scott
>> >
>> > On 4/9/07, Fuhwei Lwo <fu...@bricemedia.com> wrote:
>> >>
>> >> Scott,
>> >>
>> >> SDO built-in types were defined in the sdoModel.xsd under
>> >> tuscany/java/spec/sdo-api/src/main/resources/xml directory. The
>> >> mapping from
>> >> XSD to Java is described in the spec section 9.4.
>> >>
>> >> The instances of SDO built-in types will be instances of
>> >> commonj.sdo.Type.
>> >> So if you have a SDO type for xsd:int, the name of the
>> >> commonj.sdo.Typeinstance will be "Int".
>> >>
>> >> Hope this helps.
>> >>
>> >> Scott Kurz <sc...@gmail.com> wrote: This is maybe an SDO for
>> dummies
>> >> question.
>> >>
>> >> Are there any built-in SDO types, say, corresponding to int which I
>> can
>> >> work with as a generic DataObject in the manner that
>> java.lang.Integeris
>> >> a
>> >> java.lang.Object
>> >> corresponding to int? (I'm not seeing anything from a quick scan of
>> the
>> >> source or spec to suggest that there is.)
>> >>
>> >> Or is the simplest DataObject one can create a user-defined,
>> complexType
>> >> wrappering a single int?
>> >>
>> >> Thanks,
>> >> Scott
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> 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: Basic SDO question: no built-in types?
Posted by kelvin goodson <ke...@gmail.com>.
Ole,
the HelperContext acts as a high level scope for types. To create types
dynamically using the SDO 2.1 API you would get the TypeHelper instance from
a HelperContext instance and use one of the TypeHelper.define methods to
create types within the scope of the HelperContext.
There is also Tuscany specific interface on the SDOUtil class that allows
creation of types more in the style you show above, using a TypeHelper
instance to control the scope of the new types. In this case the new types
are available to the HelperContext to which the TypeHelper instance belongs,
and all its associated helpers.
The SDO API variant method offers solutions to the issues encountered when
creating type systems which have cross references, which can't be achieved
with the Tuscany interface. It also deals with achieving a state whereby a
newly created type is known to be finalized. The Tuscany API is a quick
method for defining types when these considerations are not important.
Regards, Kelvin.
On 09/04/07, Ole Ersoy <ol...@gmail.com> wrote:
>
> Hope it's ok that I piggy back with a somewhat related question.
>
> Does SDO a container for Type instances (the equivalent to an EMF
> EPackage)?
>
> In the EMF API I would do something like
>
> DataType dataType = EcoreFactory.eINSTANCE.createDataType();
> //Initialize the dataType
> //Add it to an ePackage containing all the model's Types
> ePackage.eClassifiers.add(dataType);
>
> Thanks,
> - Ole
>
>
>
> Scott Kurz wrote:
> > Thanks Fuhwei, Frank that helps me under the SDO view of the built-in
> > types.
> >
> > I wonder how useful it would be to allow WSDL2Java to generate a Type,
> > then,
> > instead of an int or String, when the "-dynamicSDO" option is chosen.
> >
> > There would need to be some runtime databinding-sdo support for this
> option
> > too, I'd think.
> >
> > Interesting but I'm probably going to drop this train of thought for
> now...
> >
> > Scott
> >
> > On 4/9/07, Fuhwei Lwo <fu...@bricemedia.com> wrote:
> >>
> >> Scott,
> >>
> >> SDO built-in types were defined in the sdoModel.xsd under
> >> tuscany/java/spec/sdo-api/src/main/resources/xml directory. The
> >> mapping from
> >> XSD to Java is described in the spec section 9.4.
> >>
> >> The instances of SDO built-in types will be instances of
> >> commonj.sdo.Type.
> >> So if you have a SDO type for xsd:int, the name of the
> >> commonj.sdo.Typeinstance will be "Int".
> >>
> >> Hope this helps.
> >>
> >> Scott Kurz <sc...@gmail.com> wrote: This is maybe an SDO for
> dummies
> >> question.
> >>
> >> Are there any built-in SDO types, say, corresponding to int which I
> can
> >> work with as a generic DataObject in the manner that java.lang.Integeris
> >> a
> >> java.lang.Object
> >> corresponding to int? (I'm not seeing anything from a quick scan of
> the
> >> source or spec to suggest that there is.)
> >>
> >> Or is the simplest DataObject one can create a user-defined,
> complexType
> >> wrappering a single int?
> >>
> >> Thanks,
> >> Scott
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Basic SDO question: no built-in types?
Posted by Frank Budinsky <fr...@ca.ibm.com>.
SDO doesn't have an EPackage-like object, but the URI of a Type represents
the same concept. You effectively add a type to a package by calling
TypeHelper.define() with a type who's URI represents the package that you
want it to be in.
Frank.
Ole Ersoy <ol...@gmail.com> wrote on 04/09/2007 02:37:27 PM:
> Hope it's ok that I piggy back with a somewhat related question.
>
> Does SDO a container for Type instances (the equivalent to an EMF
EPackage)?
>
> In the EMF API I would do something like
>
> DataType dataType = EcoreFactory.eINSTANCE.createDataType();
> //Initialize the dataType
> //Add it to an ePackage containing all the model's Types
> ePackage.eClassifiers.add(dataType);
>
> Thanks,
> - Ole
>
>
>
> Scott Kurz wrote:
> > Thanks Fuhwei, Frank that helps me under the SDO view of the built-in
> > types.
> >
> > I wonder how useful it would be to allow WSDL2Java to generate a Type,
> > then,
> > instead of an int or String, when the "-dynamicSDO" option is chosen.
> >
> > There would need to be some runtime databinding-sdo support for this
option
> > too, I'd think.
> >
> > Interesting but I'm probably going to drop this train of thought for
now...
> >
> > Scott
> >
> > On 4/9/07, Fuhwei Lwo <fu...@bricemedia.com> wrote:
> >>
> >> Scott,
> >>
> >> SDO built-in types were defined in the sdoModel.xsd under
> >> tuscany/java/spec/sdo-api/src/main/resources/xml directory. The
> >> mapping from
> >> XSD to Java is described in the spec section 9.4.
> >>
> >> The instances of SDO built-in types will be instances of
> >> commonj.sdo.Type.
> >> So if you have a SDO type for xsd:int, the name of the
> >> commonj.sdo.Typeinstance will be "Int".
> >>
> >> Hope this helps.
> >>
> >> Scott Kurz <sc...@gmail.com> wrote: This is maybe an SDO for
dummies
> >> question.
> >>
> >> Are there any built-in SDO types, say, corresponding to int which I
can
> >> work with as a generic DataObject in the manner that
java.lang.Integer is
> >> a
> >> java.lang.Object
> >> corresponding to int? (I'm not seeing anything from a quick scan of
the
> >> source or spec to suggest that there is.)
> >>
> >> Or is the simplest DataObject one can create a user-defined,
complexType
> >> wrappering a single int?
> >>
> >> Thanks,
> >> Scott
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> 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: Basic SDO question: no built-in types?
Posted by Ole Ersoy <ol...@gmail.com>.
Hope it's ok that I piggy back with a somewhat related question.
Does SDO a container for Type instances (the equivalent to an EMF EPackage)?
In the EMF API I would do something like
DataType dataType = EcoreFactory.eINSTANCE.createDataType();
//Initialize the dataType
//Add it to an ePackage containing all the model's Types
ePackage.eClassifiers.add(dataType);
Thanks,
- Ole
Scott Kurz wrote:
> Thanks Fuhwei, Frank that helps me under the SDO view of the built-in
> types.
>
> I wonder how useful it would be to allow WSDL2Java to generate a Type,
> then,
> instead of an int or String, when the "-dynamicSDO" option is chosen.
>
> There would need to be some runtime databinding-sdo support for this option
> too, I'd think.
>
> Interesting but I'm probably going to drop this train of thought for now...
>
> Scott
>
> On 4/9/07, Fuhwei Lwo <fu...@bricemedia.com> wrote:
>>
>> Scott,
>>
>> SDO built-in types were defined in the sdoModel.xsd under
>> tuscany/java/spec/sdo-api/src/main/resources/xml directory. The
>> mapping from
>> XSD to Java is described in the spec section 9.4.
>>
>> The instances of SDO built-in types will be instances of
>> commonj.sdo.Type.
>> So if you have a SDO type for xsd:int, the name of the
>> commonj.sdo.Typeinstance will be "Int".
>>
>> Hope this helps.
>>
>> Scott Kurz <sc...@gmail.com> wrote: This is maybe an SDO for dummies
>> question.
>>
>> Are there any built-in SDO types, say, corresponding to int which I can
>> work with as a generic DataObject in the manner that java.lang.Integer is
>> a
>> java.lang.Object
>> corresponding to int? (I'm not seeing anything from a quick scan of the
>> source or spec to suggest that there is.)
>>
>> Or is the simplest DataObject one can create a user-defined, complexType
>> wrappering a single int?
>>
>> Thanks,
>> Scott
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Basic SDO question: no built-in types?
Posted by Scott Kurz <sc...@gmail.com>.
Thanks Fuhwei, Frank that helps me under the SDO view of the built-in types.
I wonder how useful it would be to allow WSDL2Java to generate a Type, then,
instead of an int or String, when the "-dynamicSDO" option is chosen.
There would need to be some runtime databinding-sdo support for this option
too, I'd think.
Interesting but I'm probably going to drop this train of thought for now...
Scott
On 4/9/07, Fuhwei Lwo <fu...@bricemedia.com> wrote:
>
> Scott,
>
> SDO built-in types were defined in the sdoModel.xsd under
> tuscany/java/spec/sdo-api/src/main/resources/xml directory. The mapping from
> XSD to Java is described in the spec section 9.4.
>
> The instances of SDO built-in types will be instances of commonj.sdo.Type.
> So if you have a SDO type for xsd:int, the name of the commonj.sdo.Typeinstance will be "Int".
>
> Hope this helps.
>
> Scott Kurz <sc...@gmail.com> wrote: This is maybe an SDO for dummies
> question.
>
> Are there any built-in SDO types, say, corresponding to int which I can
> work with as a generic DataObject in the manner that java.lang.Integer is
> a
> java.lang.Object
> corresponding to int? (I'm not seeing anything from a quick scan of the
> source or spec to suggest that there is.)
>
> Or is the simplest DataObject one can create a user-defined, complexType
> wrappering a single int?
>
> Thanks,
> Scott
>
>
Re: Basic SDO question: no built-in types?
Posted by Fuhwei Lwo <fu...@bricemedia.com>.
Scott,
SDO built-in types were defined in the sdoModel.xsd under tuscany/java/spec/sdo-api/src/main/resources/xml directory. The mapping from XSD to Java is described in the spec section 9.4.
The instances of SDO built-in types will be instances of commonj.sdo.Type. So if you have a SDO type for xsd:int, the name of the commonj.sdo.Type instance will be "Int".
Hope this helps.
Scott Kurz <sc...@gmail.com> wrote: This is maybe an SDO for dummies question.
Are there any built-in SDO types, say, corresponding to int which I can
work with as a generic DataObject in the manner that java.lang.Integer is a
java.lang.Object
corresponding to int? (I'm not seeing anything from a quick scan of the
source or spec to suggest that there is.)
Or is the simplest DataObject one can create a user-defined, complexType
wrappering a single int?
Thanks,
Scott
Re: Basic SDO question: no built-in types?
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Scott,
Section 8 of the SDO spec describes all the standard built-in types. Types
like java.lang.Integer are SDO datatypes which correspond to XSD
simpleTypes. They are not SDO DataObjects. DataObjects correspond to XSD
complexTypes.
Frank.
"Scott Kurz" <sc...@gmail.com> wrote on 04/09/2007 11:11:05 AM:
> This is maybe an SDO for dummies question.
>
> Are there any built-in SDO types, say, corresponding to int which I can
> work with as a generic DataObject in the manner that java.lang.Integer
is a
> java.lang.Object
> corresponding to int? (I'm not seeing anything from a quick scan of the
> source or spec to suggest that there is.)
>
> Or is the simplest DataObject one can create a user-defined, complexType
> wrappering a single int?
>
> Thanks,
> Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org