Hi Annette, Adding support for the unsigned* datatypes is on our to-do list for quite sometime now. The mapping that will probably provide is the following:
unsignedLong ---> nothing unsignedInt ---> long unsignedShort ---> int unsignedByte ---> byte I am not in favor of providing a default mapping to unsignedLong since there is no mapping into java types that fit correctly what XML Schema defines. If one wants to map unsignedLong to something then he would have to define it in a binding file. As a side note; I would note that the use of Castor is now widespread in the community and we have seen little request for supporting those unsigned* datatypes. If you want to give us a hand implementing that support, feel free to do so. Arnaud > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 12, 2002 10:05 AM > To: [EMAIL PROTECTED] > Subject: [castor-dev] Question concerning Unsigned data type > > Hello Keith, > > one of my first problems with Castor were the unsigned* data types. > > If I understand theXML Schema Spec correctly, the base of this family of data > types > is unsignedLong, with a maximum of 18446744073709551615. unsignedInt > restricts this maximum to smaller values, as do the other unsigned*. > > To me, a simple solution appears to map unsigned Long onto a Java 'long' resp. > derive XSUnsignedLong from XSLong with a restriction of the minimum to 0. > Of course, this reduces the maximum possible to Long.MAX. This reduction is > the only reason I can see why this has not been implemented. Please let me > know if there were others. > > The other unsigned* then would follow, being derived from unsignedLong if > we can afford to waste some bytes of memory, or from the shortest sufficient > base type otherwise. > > I'd very much appreciate support for the unsigned data types. Almost all the > XML Schemata I have seen so far use unsignedInt or other unsigned data types > exhaustively, to express that an Integer value must not be negative. I suppose > this has its origin in the fact that most people defining XML Schemas have - > if > at all - a programming background in C rather than Java, and C programmers > love unsigned data types. Since I doubt we'll succeed to re-educate all the > Schema designers, I'd favour a solution that supports unsigned at the price of > restricting the maximum for unsignedLong to half the value defined in the > Schema spec. > The current bypass is to change the XML Schemata if they use unsigned which > always gives my a slight grumble in my stomach - I don't like changing basic > documents in projects, particularly not if they come from standardization. > Apart from that, if we want Castor to be used, we should make it as easy as > possible to use it off-the-shelf . > Please let me know your opinion - I think I could easily implement the > necessary set of classes, and change the respective generator code, at least > as a > first exercise. > > Regards, Annette > > > > > > > > > -- > Dr. Annette S�ndermann > Zenturion GmbH > Postfach 1248, 85730 Ismaning > Tel.: 089/638 76 706 Fax: 089/638 76 707 > Internet: http://www.zenturion.de > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
