W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > July 2012

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

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 31 Jul 2012 15:52:46 +0100
Message-ID: <5017F13E.8050503@epimorphics.com>
To: public-rdf-dawg-comments@w3.org, David Booth <david@dbooth.org>

On 31/07/12 15:05, David Booth wrote:
> Hi Andy,
> On Tue, 2012-07-31 at 09:04 +0100, Andy Seaborne wrote:
>> David,
>> Thank you for your comment on serializing xsd:decimal, xsd:float,
>> xsd:double.
>> XSD defines the operations for these datatypes including rules for
>> precision.  For xsd:decimal, the precision required is:
>> [[ http://www.w3.org/TR/xmlschema11-2/
>> All ·minimally conforming· processors must support decimal values whose
>> absolute value  can be expressed as i / 10k, where i and k are
>> nonnegative integers such  that i < 1016 and k ≤ 16 (i.e., those
>> expressible with sixteen total digits).
>> ]]
>> [[ http://www.w3.org/TR/xmlschema-2/
>> Note:  All ·minimally conforming· processors ·must· support decimal
>> numbers with a minimum of 18 decimal digits
>> ]]
>> SPARQL uses the work of XQuery/XPath Functions and Operators and the
>> requirements for handling these numeric datatypes derive from that body
>> of work.  The SPARQL specification links to each operator required.
>> RDF defines a literal as a lexical form and a datatype.  It does not
>> consider the datatype to modify the behavior of forming the RDF literal.
> Should I understand this to mean that when a minimally conforming SPARQL
> server creates a value of type xsd:decimal, then at least 18 decimal
> digits of precision must be retained in *serializing* that value to
> lexical form?  I understand that the computations must be performed with
> at least 18 decimal digits of precision, but serialization is
> (potentially) a different matter.

Serialization can't truncate - it must represent the value and there is 
no flexibility in the serialization step of forming the literal.  If the 
calculation says the value is X, then the serialization must represent X.

The serialization represents the value. In some datatypes like 
xsd:decimal, there are multiple ways to write the same value.  It's a 
feature of the datatype, not RDF itself.  xsd:decimal does not record 
precision with trailing zeros.

See http://www.w3.org/TR/xsd-precisionDecimal/ (W3C Working Group Note) 
which is not a required datatype in SPARQL (or even an XSD processor)


> Thanks,
> David
>> The working group is not planning to make any changes in this area.
>> I would be grateful if you reply to this message to confirm that the
>> working group has responded to your comment.
>> Yours, on behalf of the SPARQL Working Group,
>> 	Andy
>> 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 Tuesday, 31 July 2012 14:53:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:30 UTC