Christian, what's the scenario here? Are you in control of the registration of all the schemata that contribute to the namespace? Can you create an uber-schema that includes all the others and then define the types using that? My guess is that there are other constraints that prevent you from doing that. I haven't tried it but I've a feeling that that would work?
Regards Kelvin. On 09/02/07, Christian Landbo Frederiksen < [EMAIL PROTECTED]> wrote:
Hmmm. I just found this in the Dev list: "In the future, we may want to look at allowing new types to be added to an existing namespace, but currently that is not supported." - Frank Budinsky If this is not coming up real soon - is there a way to circumvent this using the underlying EMF or something? -----Original Message----- From: Christian Landbo Frederiksen [mailto:[EMAIL PROTECTED] Sent: 9. februar 2007 14:29 To: [email protected] Subject: RE: SDO (Types) Registry And then again - that way I can't define from my xsd. Dang. How do I solve this? /Chr -----Original Message----- From: Christian Landbo Frederiksen [mailto:[EMAIL PROTECTED] Sent: 9. februar 2007 14:27 To: [email protected] Subject: RE: SDO (Types) Registry I have just run into calling define(...) for a schema with namespace that has already been defined by another schema does NOT add the types from the new schema. I suppose I have to register each seperately on its own typehelper? Is there a way to see if a namespace is already defined? /Chr -----Original Message----- From: Yang ZHONG [mailto:[EMAIL PROTECTED] Sent: 27. januar 2007 20:15 To: [email protected] Subject: Re: SDO (Types) Registry SDO spec seems not addressing the issues yet, here's what I know for Tuscany implementation. 1. connection between XSDHelper#define and XMLHelper#load The assumption is right: XSDHelper#define stores Types into (Package/Types) Registry and XMLHelper#load uses the Types from the (Package/Types) Registry 2. How XMLHelper#load uses Types Assuming a XML: <root:stock xmlns:root="NS" ... XMLHelper#load looks for the Type of the global Property with NameSpace "NS" and name "stock", and uses the Type to create DataObject instance then loads the rest of the XML. The Type can be dynamic from XSDHelper#define, where the DataObject is an instance of DataObjectImpl. The Type can also be static from code generation, where the DataObject is an instance of generated class such as MyStock. If no Type available, XMLHelper#load creates an instance of AnyTypeDataObject and loads data without any metadata. 3. (Package/Types) Registry Garbage Collection Types are weakly referenced by ClassLoader. If a (J2EE) application stops, Types can be Garbage Collected unless a system library (live ClassLoader) holds a strong reference. 4. (Package/Types) Registry Thread Safety No Thread Safety for the moment. However it could be done; the previous SDO implementation I worked on supports Thread Safety for example. 5. Two XSDHelper#define for same XSD(s) The later one overwrites the earlier one if same scope/application/ClassLoader. If concurrent, slower thread "wins" :-) If different scope/application/ClassLoader, multiple copies for the moment. However it could be optimized to save both storage and defining/loading time; the previous SDO implementation I worked on defines/loads same XSD(s) only once if no modification and makes Types available to multiple scopes/applications/ClassLoaders, for example. On 1/27/07, Christian Landbo Frederiksen < [EMAIL PROTECTED]> wrote: > > I was wondering what goes on in the background, since SDO can be used > the way is is used. > > In the example: > org.apache.tuscany.samples.sdo.specCodeSnippets.CreateDataObjectFromXsdA > ndXmlFiles > > types are defined in one static method like this: > XSDHelper.INSTANCE.define(is, null); > > and then in another static method xml is loaded: XMLDocument xmlDoc = > XMLHelper.INSTANCE.load(is); > > What is the connection between these two separate method invocations? > How does the loading of xml use the types defined above? I assume > something is stored somewhere but how does this relate to garbage > collection and thread safety? I meas somebody could call > XSDHelper.INSTANCE.define(is, null); with another xsd somewhere else in > the same VM? > > /Chr > > > > > > -- Yang ZHONG --------------------------------------------------------------------- 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]
