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

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 
'string'.
"""

Paul

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