Hi Martin, let me try to address some of your 'shots' ... ;-).
Martin S. Weber wrote: > > Hi Werner & all.. > > Quoting "Werner Guttmann" <[EMAIL PROTECTED]>: >> Hi Martin, >> >> Martin S. Weber wrote: >>> Hey people, >>> >>> so I've found that castor (wrongly) creates Java Enums of all uppercase >>> symbols for an xsd:enumeration xsd:restriction like the following: >>> >>> <xsd:simpleType> >>> <xsd:restriction base="xsd:token"> >>> <xsd:enumeration value="m"> <!-- prefix 'milli' --> >>> <xsd:enumeration value="M"> <!-- prefix 'mega' --> >>> </xsd:restriction> >>> </xsd:simpleType> >>> >>> The generated enum symbols for that will be 'M' and, er, yes, 'M'. So I >>> found that code, fixed it, and then wanted to compile castor. >> Is there really a need to fix this ? Actually, with java 5.0 you might >> have a valid point there. But I am not 100% convinced .... Okay, before having a go at this, let's get focused a bit. There's already a work-around for this, as documented here: http://castor.org/reference/html/xml.code.generator.html#d0e4989 In other words, we are aware of this problem (and have been so for a couple of years). Let me see whether this actually satisfies you already. And I am aware that this might still cause issues with code generation for Java 5.0 and higher, but here I am not 100% sure. Can you please try this, and see where it takes you. And please do come back and let us know about your findings. I thin that your fix might actually be a valid one, but with Java 1.4 and no real enums available, there was no option available. Would you mind if I addressed the other shots later on ? Let's first address your problem (and solve it), and then we'll take it from there, right ? > > Ok, let's try. > > shot 1: mega and milli are two different entities, their abbreviations > are well defined and well known, and you can't just change the case of > the lowercase 'm' to the uppercase 'M' as that gives you a 10^9 error! > > shot 2: this is for software to use unitsml, a language (in its nappies > still) that is to be used to transport unit information. m going to M is > a killer argument to not use castor. > > shot 3: XML is case sensitive. Yes this sucks. It should be > case-ignorant and -preserving, but it isn't. It's case sensitive. You > can't just change the case of things. I mean.. you just can't. > > shot 4: You generate code that doesn't compile when ignoring the case. > (Look at the source code generators output for the example I cited -- > you're getting a clash for dual 'M's.) Yes, we know. That's why we provide you with a binding file to manually override the naming conventions as used by the XML code generator where things do not work automagically. And that's on intention: we do NOT want to be a product that knows how to avoid all possible naming collisions. > > I understand that the java naming conventions are different, and that > you like to generate code that follows the java culture. But the XML > culture is different. E.g. Look at those two elements: <starts-with> and > <starts-With>. Yes it's braindead, but they are two different elements. > Generating method names incorporating the fragment startsWith for *both* > is just wrong with regard to the XML culture (shot 5?). As you see this > applies to applying java naming conventions _in general_ to xml stuff. > > Yes the output is alien and ugly and ... Go complain to the W3C. It's > them who are braindead. If you want to make conformant XML processors, > you have to be braindead, too. There's just no choice. See my answer to shot 4. To repeat it, the answer is NO. We simply don't want to replicate (and thus multiply) their brain-deadness into the Java world. We expect users that know what they are dealing with if they want to be using a powerful tool to generate code from XML schemas that can carry constructs that we sometimes cannot meet at all and/or meet easily, i.e. without human intervention. We have been given this choice when implementing the product years ago, and a deliberate decision has been taken. > > Regards, Regards > > -Martin Werner > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
