W3C home > Mailing lists > Public > public-xsd-databinding@w3.org > March 2006

proposed text for ISSUE-3 - Mapping Types with Infinite Value Space

From: <paul.downey@bt.com>
Date: Tue, 28 Mar 2006 00:12:12 +0100
Message-ID: <2A7793353757DB4392DF4DFBBC95225504BFE8AF@I2KM11-UKBR.domain1.systemhost.net>
To: <public-xsd-databinding@w3.org>

I took ACTION-4 to propose text for ISSUE-3 that will 
advise on the value space to use.

>From experimentation with a number of different binding
tools I had to hand, I re-learnt how xs:integer is often 
presented as toolkit specific type (OK-ish - note even
java.lang.integer has limits), however some other
tools such as the .NET 1.1 SDK, present xs:integer as 
a 'string'.

Erik drew out this point in his issue description, 
but targeted his advice at toolkit vendors. 

However given in Basic patterns we want to cite types which
give a good user experience, I think the question to ask is
if, say,  a type derived from xs:decimal being presented as 
a string counts as 'a good user experience'. So:

Proposal #1:

Enumerate the fixed precision decimal derived types in 
Basic patterns, and grey-out/leave out the unconstrained 
types: xs:decimal, xs:integer, xs:negativeInteger, 
xs:positiveInteger, xs:nonNegativeInteger, xs:nonPositiveInteger

Proposal #2:

Enumerate xs:decimal and all its derived types in our 
Basic patterns and add a "Design Consideration":

The built-in numeric primitive types, in particular xs:decimal,
xs:integer, xs:negativeInteger, xs:positiveInteger, 
xs:nonNegativeInteger and xs:nonPositiveInteger
do not map directly to native types in many programming 
languages. They are likely to be presented as a toolkit 
specific construct or more generalised ways, such as a 

Received on Monday, 27 March 2006 23:12:16 UTC

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