[EMAIL PROTECTED] wrote: > > H all, > > I had some discussions with Arnoud Blandin on the SourceGenerator, > while the list was down. Here are some of the outcomes. > > .1) > "diff-for-asWrapper" contains a context-diff for an ugly patch to a bug that > resulted in an exception shown in miniproject "wrapper.tgz". The out.txt file > contains the error; > > [javac] /home/daan/project/wrapper/test/generated/BitArray.java:147: >incompatible types > [javac] found : boolean > [javac] required: java.lang.Boolean > [javac] return ((Boolean)_bitList.get(index)).booleanValue(); > > the part ".booleanValue()" should not be attached if asWrapper is true (to > go short). This goes for eleven more or less different types. All the numeric > types, i think. Unfortunately the XS-classes for those do not have a common > ancestor apart from the others. This is what makes my patch ugly. > Thanks...I'll let Arnaud handle this one since you've already been in discussion with him. > .2) (I just read a mail from Alex Edwards, that also justifies this point) > > I have several schemas. Some of them define the same names. > ... <things ommitted> > In xsdl elements and types can have the same name. This is not handled > by the SourceGenerator. Also elements of the same name can have slightly different > semantics in different context. In Java this could be solved with innerclasses. Has > this been discussed before? Yes it has been discussed. The org.exolab.javasource package would have to be upgraded first to support inner-classes. I have some *big* patches from a couple people that adds innerclass support, but I need to review them. I checked in some of their changes, but not yet the actual innerclass stuff as I haven't had the time to thoughoughly review and test them. In any case...innerclasses would be the best solution, in my opinion, to the problem. > > Or with automatic generation of package names. The exaple from Alex would/could lead > to the classes: > package.person.Address and > package.dog.Address This could be done, but I prefer the approach above. > > an (lesser) alternative would be: > package.PersonAddress and > package.DogAddress We do this approach already for type-safe enumeration classes. The trick is knowing when you'll have two classes with the same name, so that you don't have to mangle all the names. This is why the inner classes are better (or even your package solution above). > > What I would also like is for the -package option to work as a base package , and for > castor to then create subpackages for each (xml-)namespace. Is this a valid change > request in everybodies eyes? Automatically creating a namespace->package is not always clean, but certainly doable. We actually have this on our to do list. We wouldn't use the -package as the "base" package if the namespace contained a URL as the namespace such as: http://www.w3.org/xyz, only if the namespace was a simple URI like "xyz". Otherwise the namespace would be converted to a full package without using the base as such "org.w3.xyz" (the www and http:// would be removed). > > In that case if Alex's dog and person where namespaces instead of parent nodes, it > would also be resolved. As a current workaround, Alex can also use an XSLT stylesheet to modify the name of the elements before running through the source generator. --Keith ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
