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

David,

Surely the responsibility for the datatype values resides with the datatype?

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!
>

Received on Friday, 20 July 2012 17:24:38 UTC