That is not really an option. I agree that it would work, but schemas may be defined dynamically using the same namespace, so...
/Chr -----Original Message----- From: kelvin goodson [mailto:[EMAIL PROTECTED] Sent: 9. februar 2007 15:07 To: [email protected] Subject: Re: SDO (Types) Registry 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
