I have to use instances as well and I find the SDO way quite useful in that sense...
-----Original Message----- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 12. februar 2007 20:00 To: [email protected] Subject: Re: SDO (Types) Registry I'm not sure if this is relevant but if you are looking to manage schemas themselves rather than instances described by them, the Apache XmlSchema project may be useful as well. http://ws.apache.org/commons/XmlSchema/index.html -- Jeremy On Feb 12, 2007, at 10:40 AM, Christian Landbo Frederiksen wrote: > > > Let me first say, I don't not have very much insight into how > Tuscany is > built up. > > I am dealing with a situation where the xsd's, that define the > format of > a generic data publishing sysem, can be added and changed > dynamically - > even the individual types of a namespace can be changed (probably not > very often). I first looked into EMF XSD and then found Tuscany, > and it > has looked very promising. > > Except that I ran into the fact that namespaces cannot be altered once > defined. Frank Budinsky came up with a solution where namespaces > can be > extended, but the types that exist already in a namespace cannot be > redefined. > > Perhaps this scenario is way beyond the purpose of SDO, but besides > these two issues I find it very useful to work with runtime xml > schemas. > > So as you might guess I think an option to totally redefine namespaces > or to extend them with new types and just overwrite the existing ones, > would be fine. > > This is in fact something I am trying to look into implement > myself, but > at the understanding I'm at now I am having difficulties > maneuvering in > the EMF. I have no idea where defined schemas are currently kept in > the > VM and therefore don't know where to put in the code to allow types > of a > namespace to be redefined. > > Any pointers to where this code would go would be GREAT... > > /Chr > > -----Original Message----- > From: kelvin goodson [mailto:[EMAIL PROTECTED] > Sent: 10. februar 2007 13:27 > To: [email protected] > Subject: Re: SDO (Types) Registry > > Christian, > > unfortunately not. The only open JIRA we have in this area is > http://issues.apache.org/jira/browse/TUSCANY-761 for unregistering all > the > types in a namespace. Perhaps we could collect together some info on > what's > really useful here and have some design discussions on how to handle > type > lifecycle. There have previously been discussions on forming > associations > between HelperContexts so that one HC can have dependencies on > another/others. This might allow for example dropping type > definitions > by > dropping all references to a given HelperContext. It would be good to > know > exactly which operations would be the most valuable to you in order to > help > make good design decisions. > > Regards, Kelvin. > > > > On 10/02/07, Christian Landbo Frederiksen < > [EMAIL PROTECTED]> wrote: >> >> Is there no way to 'undefine' types if you have to modify existing > types? >> >> /Chr >> >> ________________________________ >> >> From: Frank Budinsky [mailto:[EMAIL PROTECTED] >> Sent: Fri 2/9/2007 5:10 PM >> To: [email protected] >> Subject: RE: SDO (Types) Registry >> >> >> >> If the requirement is just to add new types to a namespace, as >> opposed > to >> modifying existing types (which is nasty), I don't think it would be > hard >> to add this support. >> >> This is open source, maybe you want to help :-) >> >> Initially, I would suggest adding a new instance variable in > XSDHelperImpl >> - extensibleNamespaces (false by default, but can be set to true) - > and >> then change this line in XSDHelperImpl.define(): >> >> if (ePackage == null || TypeHelperImpl.getBuiltInModels >> ().contains(ePackage)) >> >> to this: >> >> if (extensibleNamespaces || ePackage == null || > TypeHelperImpl. >> getBuiltInModels().contains(ePackage)) >> >> Then, it's a matter of debugging to make sure that in > SDOXSDEcoreBuilder, >> when a type is requested that already exists, it just uses the > existing >> type and moves on. New types would get added in the usual way. >> >> I think this may be related to, and helped by, the work that will be > done >> in TUSCANY-1085 (not the patch provided by Fuhwei, but the proper fix > that >> needs to be done), which needs to ensure that previously loaded types > are >> found in SDOXSDEcoreBuilder. >> >> Frank. >> >> >> "Christian Landbo Frederiksen" > <[EMAIL PROTECTED]> >> wrote on 02/09/2007 08:36:35 AM: >> >>> 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.CreateDataObjectFromXs > dA >>>> 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] >> >> >> >> >> >> >> --------------------------------------------------------------------- >> 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]
