(no subject)

>>> I understand the misreading. I'm happy that you tested, it's good  
>>> information to have. But Pellet has that behavior because I read  
>>> the XML Schema specs and interpreted them in what I think is the  
>>> obvious way. Thus, I think Pellet's behavior is spec compliant.
>>
>> I read the spec differently: both values spaces are defined  
>> mathematically in terms of "numbers". The mathematical value 1 is  
>> in the [float](http://www.w3.org/TR/xmlschema-2/#float) value space  
>> because it is the value 1x2^0, is in the [decimal](http://www.w3.org/TR/xmlschema-2/#integer 
>> ) value space because it is the value 1x10^{-0}, and it is in the  
>> [integer](http://www.w3.org/TR/xmlschema-2/#integer) value space  
>> because it is in the set \{...-2,-1,0,1,2,...\}. As these are all  
>> mathematical and not lexical definitions it appears that the  
>> Integer and float value spaces overlap.
>
> This would be true if XML Schema had a purely structural type  
> system. But it also includes nominal types:
> 	http://www.w3.org/mid/D245D6CC-4F7B-41CC-BCF4-FAE7CD7CFFC9@cs.man.ac.uk
>
> My reading of the spec:
> 	http://www.w3.org/mid/6572A0FC-B943-4ACE-9E42-6D914E2C383C@cs.man.ac.uk
>
> Since all primitive datatypes are disjoint, double and decimal and  
> float are all disjoint.
>
> (Interestingly, McQueen (mis)read it the same way! <http://www.w3.org/mid/8E57FB57-80B1-4016-A7F0-46DE8CEB8289@acm.org 
> >. That does suggest that the de facto understanding is strongly  
> against mine, but I think mine was honestly come by.)

Hmmm...I think your interpretation might actually be the intent: [the  
·value space·s of all ·primitive· datatypes are disjoint (they do not  
share any values)](http://www.w3.org/TR/xmlschema-2/#equal). I'm not  
crazy about their definitions (a claim about disjointness isn't the  
same as defining multiple colors of numbers), but they did seem to  
intend disjoint spaces.

The new version of the XSchema spec is much [clearer](http://www.w3.org/TR/xmlschema11-2/#order 
), and explicitly endorses "other applications" which join the value  
spaces:

For purposes of this specification, the value spaces of primitive  
datatypes are disjoint, even in cases where the abstractions they  
represent might be thought of as having values in common.  In the  
order relations defined in this specification, values from different  
value spaces are ·incomparable·.  For example, the numbers two and  
three are values in both the decimal datatype and the float datatype.   
In the order relation defined here, the two in the decimal datatype is  
not less than the three in the float datatype; the two values are  
incomparable.  Other applications making use of these datatypes may  
choose to consider values such as these comparable.


Regardless, my experience is that users both want and expect a single  
number line (modulo NaN and +-inf). I feel that the last sentence of  
the above section of the new XSchema spec blesses these semantics with  
xsd constants. And current tools are inconsistent in their  
interpretation, so any choice we make is going to force *some*  
implementation(s) to change. Is anyone really still pushing for  
multiple number lines, one of which includes Integers and one of which  
includes (for example) floats?

-rob