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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
