W3C home > Mailing lists > Public > public-xsd-databinding@w3.org > December 2005

Re: ISSUE-3: Mapping Simple Numeric Types with Infinite Value Space

From: Pete Cordell <petexmldev@tech-know-ware.com>
Date: Tue, 20 Dec 2005 09:28:00 -0000
Message-ID: <003901c60547$ae63c9b0$b100a8c0@RW>
To: "Databinding WG" <public-xsd-databinding@w3.org>

----- Original Message From: "Databinding Issue Tracker" <dean+cgi@w3.org>

> ISSUE-3: Mapping Simple Numeric Types with Infinite Value Space
> http://www.w3.org/2005/06/tracker/databinding/issues/3
> Raised by: Paul Downey
> On product: All
> Created on behalf of Erik Johnson (Epicor)
> http://lists.w3.org/Archives/Public/public-xsd-databinding/2005Dec/0015.html
> The xs:integer simple type (which is derived from xs:decimal, BTW) has a
> value space defined as "the infinite set {...,-2,-1,0,1,2,...}" (see
> http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/#integer).  Most
> programming language and database implementations have (unsigned)
> integer value spaces of 0 to some power of 2 minus 1.  Some schema
> processors map xs:integer and derived types like xs:nonNegativeInteger
> to string types to avoid potential overflow problems.  However, many
> schema users are not aware that many languages/databases cannot consume
> xs:nonNegativeInteger in the way developers may expect.
> I think the only sound way to go forward is to ensure that schema
> processors do not map simple types with an infinite value space to a
> toolkit construct with a non-infinite value space.

Is it also possible to advise that, where possible, schema writers specify 
appropriate bounds for numerical values, either explicitly using 
(min|max)(In|Ex)clusive, or implicitly using types such as xs:int?  Schema 
processors then have a better chance of assigning the value to an 
appropriately sized native integer, or an unbounded type (possibly string 

Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
(or http://www.xml2cpp.com)
Received on Tuesday, 20 December 2005 09:28:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:12 UTC