W3C home > Mailing lists > Public > public-rdf-wg@w3.org > May 2013

Re: json-ld-api: change proposal for handling of xs:integer

From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
Date: Tue, 14 May 2013 21:01:29 +0200
Message-ID: <CA+OuRR9_2prTca1ROnZ+9NZqLDfsFG-8t1=gV_rjV7H14-BUiQ@mail.gmail.com>
To: Sandro Hawke <sandro@w3.org>
Cc: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>, Manu Sporny <msporny@digitalbazaar.com>, W3C RDF WG <public-rdf-wg@w3.org>
On Tue, May 14, 2013 at 2:07 PM, Sandro Hawke <sandro@w3.org> wrote:

> after all, both xs:integer and JSON allow arbitrary long integers, so this
> is up to implementations to cope with that -- or at least notify in the
> cases they don't.
>  But which implementation?   The JSON-LD producer has to make this choice
> on behalf of all JSON-LD consumers to which it might be passing documents.

I was thinking that the *producer* could raise an exception when asked to
serialize a large integer. Of course, this still raises the question of
when to raise it, an int larger than 32 bits or larger than 64 bits :)

Markus and I have consensus on a way forward:
> - for useNativeTypes=True, all numeric types (except xsd:decimal) are
> converted to json native numbers.  on translation back to RDF literals,
> they'll all end up as xsd:double.
> - we'll say clearly that setting useNativeTypes=True MAY change the value
> and/or datatype of any RDF numeric literals (except xsd:decimal).  So keep
> it False if you want exact roundtrip conversion.

fair enough.
But why exclude xs:decimal, then ?? I understand that the conversion back
to xs:double is lossy, but so is the case for xs;integer. Why treat them

Received on Tuesday, 14 May 2013 19:01:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:27 UTC