Re: Serializing xsd:decimal, xsd:float, xsd:double

On Jul 20, 2012, at 12:24 PM, Andy Seaborne wrote:

> David,
> 
> Surely the responsibility for the datatype values resides with the datatype?

+1

Pat

> 
> The rules for handling xsd decimals are entirely derived from XSD which already has rules for this situation.
> 
> An RDF literal is a lexical form and a datatype; value translation is a matter for the datatype definition.
> 
> If the lexical form is "0.049508196721311475409836" then the literal is "0.049508196721311475409836"^^xsd:literal.
> 
> xsd:double and xsd:float are completely defined by XSD.
> 
> xsd:decimal, being infinite, has a minimal requirement of expressibility with 16 digits in XSD 1.1, which was 18 in XSD 1.0 [1,2]
> 
> 	Andy
> 
> [1] http://www.w3.org/TR/xmlschema-2/#decimal
> [2] http://www.w3.org/TR/xmlschema11-2/#partial-implementation
> 
> On 20/07/12 16:19, David Booth wrote:
>> It is currently difficult to compare the results of two different SPARQL
>> servers when xsd:decimal, xsd:float or xsd:double are used, because
>> there does not seem to be any standard way to control the number of
>> decimal places that are serialized.  For example, if the decimal
>> 0.049508196721311475409836 is computed, one server may serialize this as
>> 
>>   "0.0495081967"^^xsd:decimal
>> 
>> and another may serialize it as
>> 
>>   "0.050"^^xsd:decimal
>> 
>> One might (erroneously) attempt to round both of the serialized values
>> to one decimal place in order to compare them, but if they have already
>> been rounded once before serialization (as above) then this won't work,
>> because 0.050 rounds to 0.1, while 0.0495081967 rounds to 0.0.
>> 
>> I think the SPARQL standard should provide some "SHOULD" guidance, such
>> as specifying that a SPARLQ server SHOULD (by default) serialize a
>> specified number of decimal places (perhaps all available), and MAY
>> provide a standard means of controlling the number of decimal places
>> that are serialized.
>> 
>> If it is too late in the WG process to consider this for SPARQL 1.1 (and
>> I assume it is) then please add this to the wish list for the next
>> version.
>> 
>> Thanks!
>> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 20 July 2012 18:23:01 UTC