Change of xsd:int for large numbers
People, As I have been going through the service description I realized we are going to have problems with our current use of xsd:int which is a signed integer value. If you remember we changed from the xsd:integer to an xsd:int in release 1.0 to simplify coding in Java since it uses a base int type instead of an Integer object. This was okay in release 1 since we were specifying bandwidth in Mbps, however, with the introduction of service descriptions it is possible to specify the units for capacity. This means with our current xsd:int definition we are unable to specify bps for capacity. Also, it looks like burst size as an xsd:int will also not work. Is anyone against me changing these to an integer or perhaps nonNegativeInteger? Thanks, John
Hi John, (2013/07/31 9:12), John MacAuley wrote:
Is anyone against me changing these to an integer or perhaps nonNegativeInteger?
I prefer xsd:long or xsd:unsingedLong (64 bit integer), and they seem enough for the purrpose. Here is the mapping of xsd and Java types. http://xmlbeans.apache.org/docs/2.0.0/guide/conXMLBeansSupportBuiltInSchemaT... In Java, xsd:integer and xsd:nonNegativeInteger will be BigInteger object. Java programmers must write such as BigInteger x = BigInteger.valuof(1000); BigInteger y = ...; BigInteger z = x.add(y); It's too complicated... Thanks -- Katsuhiko OHKUBO ookubo-k@aist.go.jp
I used the standard Sun jaxb compiler on the schema with an xsd:unsignedLong and it generated a BigInteger. I tried it with an xsd:long and it generated a java long for capacity and a Long object for mtu and burst size since they are optional. I will go with the long as you suggest. John On 2013-07-30, at 11:53 PM, Katsuhiko OHKUBO <ohkubo-k@suri.co.jp> wrote:
Hi John,
(2013/07/31 9:12), John MacAuley wrote:
Is anyone against me changing these to an integer or perhaps nonNegativeInteger?
I prefer xsd:long or xsd:unsingedLong (64 bit integer), and they seem enough for the purrpose.
Here is the mapping of xsd and Java types. http://xmlbeans.apache.org/docs/2.0.0/guide/conXMLBeansSupportBuiltInSchemaT...
In Java, xsd:integer and xsd:nonNegativeInteger will be BigInteger object. Java programmers must write such as BigInteger x = BigInteger.valuof(1000); BigInteger y = ...; BigInteger z = x.add(y); It's too complicated...
Thanks
-- Katsuhiko OHKUBO ookubo-k@aist.go.jp _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi John, (2013/08/01 12:57), John MacAuley wrote:
I will go with the long as you suggest.
Thank you.
Here is the mapping of xsd and Java types. http://xmlbeans.apache.org/docs/2.0.0/guide/conXMLBeansSupportBuiltInSchemaT...
This table may be wrong.. Some time ago, I used wsdl2java (Apache CXF 2.6.6) and Sun Java 7, xsd:unsignedLong became BigInteger, xsd:long became long. -- Katsuhiko OHKUBO ookubo-k@aist.go.jp
Hi On Tue, 30 Jul 2013, John MacAuley wrote:
As I have been going through the service description I realized we are going to have problems with our current use of xsd:int which is a signed integer value. If you remember we changed from the xsd:integer to an xsd:int in release 1.0 to simplify coding in Java since it uses a base int type instead of an Integer object. This was okay in release 1 since we were specifying bandwidth in Mbps, however, with the introduction of service descriptions it is possible to specify the units for capacity. This means with our current xsd:int definition we are unable to specify bps for capacity. Also, it looks like burst size as an xsd:int will also not work.
Looking at the XSD spec, it looks like integer is more or less what we want, as there are no intrisic limit to these things. Bending the .xsd to accomodate certain implementations, frameworks or languages seems silly.
Is anyone against me changing these to an integer or perhaps nonNegativeInteger?
Using long (or whatever) doesn't really change anything for me. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (3)
-
Henrik Thostrup Jensen -
John MacAuley -
Katsuhiko OHKUBO