Hi Christopher, your project sound quite ineteresting. If you managed to migrate to castor and are intersted we can add a link to our 'Products that use Castor' section.
To your questions regarding binding. First of all, you won't need a binding for all schemas. It is only needed if source generator has problems related to: - use element/attribute names for java classes/properties - class name conflicts caused by multiple elements with same name - and so on The binding does not influence element/attribut names wether on marshalling nor unmarshalling. You will always get the element attribute names defined in schema at marshalling and only xml that confroms to the schema is valid at unmarshalling. The binding only enables you to changed the name of the java class or property that corresponds to a element/attribute. For example you may have declared a element named 'final'. As 'final' is a reserved word in java we can not use this name for a property. Therfore you can tell castor to use the property name 'myFinal' instead. Another example is that you may have declared 2 complex types with the same name 'foobar' inside of 2 different complex types. Codegen would create a class 'Foobar' for both of the in the same directory. This leads to the one generated first being overwritten by the second one. If both complex types are similar this may be what you want but in many cases you would expect 2 independend classes. The binding will allow you to change the name of one or both of the generated classes. At the moment we do not support to generate the binding automatically, but with 1.1.1 support to automatically resolve naming conflicts will be added. If you like to test that you can build Castor yourself from SVN head or take the latest snapshot that already includes this feature. For information on usage of the conflict resolution strategies you need to ask Werner as he has added this. Hope that helps Ralf Christopher Garwood schrieb: > Hi, > > First off, thanks so much to those who gave me some guidance on the last > question I had - very much appreciated :) . I have another one now > relating to the binding file. I've read through the section on binding > but was wondering if there is a means to automatically generate this > file. If there is a schema that has a number of fields in a complex > type that are then repeated in other complex types, do these need to be > manually specified in the binding.xml file? Also, when moving back from > Java classes to XML are the original element names preserved? One of > the examples shown is where the complex type name and the field name are > appended together - are these then taken apart as it were when moving > back to XML? Any input would be greatly appreciated > > I am working on a project called Pedro which renders data entry forms > for an XML schema. Users use the forms to produce XML files which > validate against the schema. Currently, we are using the MSV Schema > Reader to interpret the schemas. We are now trying to replace MSV > Schema Reader with Castor. Therefore we are concerned with preserving > information about the record and field definitions in the schema because > these tags are used both in the generated forms and in the generated XML > data files. If anyone is interested in finding out more about what > we're up to, please check out http://pedrodownload.man.ac.uk . > > Thanks for your time, > > Chris. > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email -- Syscon Ingenieurbüro für Meß- und Datentechnik GmbH Ralf Joachim Raiffeisenstraße 11 72127 Kusterdingen Germany Tel. +49 7071 3690 52 Mobil: +49 173 9630135 Fax +49 7071 3690 98 Internet: www.syscon.eu E-Mail: [EMAIL PROTECTED] Sitz der Gesellschaft: D-72127 Kusterdingen Registereintrag: Amtsgericht Stuttgart, HRB 382295 Geschäftsleitung: Jens Joachim, Ralf Joachim --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
