Re: [castor-dev] Different Spec versions

[Bender Heri]

Title: [castor-dev] Different Spec versions

OK, since nobody wants to clarify what Twiki means, I will summarize here what solution I found in order to solve the problem with schema evolution:   1. Broken the xsd-file into two parts: One part covers all definitions which stay the same in both versions, the other one includes this first one and adds all definitions which have altered in the new version. There are two (or more) versions of this second xsd, each one according to the appropriate specification.   2. Created two binding files where all definitions of the second xsd are mapped to the pattern xxxV1 resp. xxxV2 (where xxx is the original name of the element resp. type). After calling the sourceGenerator twice (one time for version 1 with V1.xsd and bindingV1.xml and one time with V2.xsd and bindingV2.xml) I get one class for each definition which is unaltered between the versions and two classes for each definition which has altered (beside the appropriate xxxDescriptor class).   These two steps didn't take too much time.   3. In order to have an abstraction of the two versions to work within my application, I created an adapter class for each class xxxVx and one Interface for both which covers a superset of all methods of the xxxV1 and xxxV2 class. This step took about 5 working days for a quite small schema (about 30 elements and types, partly nested). Especially the array class wrappers required a big care to not confuse the different class castings. Note: The representation of each nested class within the interface classes (param types or return types) had to be mapped to the appropriate interface too, and then calling the underlying castor generated class the interface had to be typcasted.     I do not see an elegant solution what castor could provide in order to solve these problems as long as xml schemas do not support schema evolution.   One possible approach could be: SourceGenerator must know of the two (or more) different spec versions, so that it can be called only once instead of two or more times (for each spec version). The needed informations (see the files created in step 1 and 2) could be provided by a new defined xml file. SourceGenerator now takes care of the mappings to the xxxVx classes when it encounters the same element or type in the different Vx.xsd files. With this knowledge the SourceGenerator also can create the adapter classes (xxxVxAdpt.java) and the Interface (xxxIntf.java). Although this sounds like a lot work it would save even more work for each user of castor.   Hope this makes sense   Heri    -----Original Message----- From: Ostermueller, Erik [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 3:36 PM To: [EMAIL PROTECTED] Subject: RE: [castor-dev] Different Spec versions IMHO, this is a difficult problem. It would be nice to change only those structures that change. The problem with that is, though, that a parent class needs to know whether to load the old child or the new one. So, one is inclined to also change the parent.  This behaviour bubbles all the way up to the root. Be sure to share with the group whatever solution you land on. To avoid this problem, I think it will require more customization than plain SoureGenerator-generated code allows.   --Erik -----Original Message----- From: Bender Heri [mailto:[EMAIL PROTECTED] Sent: Mon 11/17/2003 7:52 AM To: [EMAIL PROTECTED] Cc: Subject: [castor-dev] Different Spec versions Hi My server application which receives XML-Messages must treat 2 different specification versions of the XML-File. Most of the types, attributes and elements stay the same between the versions (98%) but some are different (mandatory/optional, existing/not existing, renamed elements). I thought of resolving this problem like this: - having 2 different schemas which include a third schema where the unchanged items are declared - let castor build the classes in two different subpackages - creating wrapper classes for each castor generated class which implements an interface - working only with the interface The problem is now, that there are really a lot of elements and types. I have to create for each castor generated class one interface and two wrappers (one for each version. Maybe I must support three or even more versions in future) -> much boring error-prone work. Is there annother way of addressing such an issue? I particular the common unchanged types and elements should be wrapped into the same class (not different classes with the same name in different sub packages). Heri BTW: Castor 9.5.2, java 1.4.2 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of:         unsubscribe castor-dev