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

On 05/14/2013 04:52 AM, Pierre-Antoine Champin wrote:
> Hi,
>
> On Mon, May 13, 2013 at 3:45 AM, Manu Sporny 
> <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>> wrote:
>
>     On 05/10/2013 06:31 PM, Sandro Hawke wrote:
>     > I believe, by saying in situations where there might be a loss, one
>     > MUST NOT convert to a number.
>
>     We didn't do this because the range for a JSON number isn't defined
>     anywhere.
>
>     > It's true we don't know exactly when there might be a loss, but
>     after
>     > talking with Markus, I'm pretty confident that using the range of
>     > 32-bit integers will work well.
>
>     ... except that most systems support 64-bit numbers, and we'd be
>     hobbling those systems. :/
>
>     We might want to put in guidance that moves the decision to the
>     processor (it can detect when a conversion would result in data loss).
>     Perhaps it should be up to the implementation to determine when data
>     could be lost.
>
>
> +1 to that; 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.

And there's no way in practice to issue a warning.  Existing standard 
JSON parsers don't report loss accuracy in representing numbers.   I 
just confirmed that by testing Node 0.10, Firefox 20, and Chromium 25:

    JSON.parse("[10000000000000000001]")

returns:

    [ 10000000000000000000 ]

without warning or error.   We're not going to get those implementations 
to change.

>
>     > I'd also add:
>     >
>     > "1"^^xs:int              // not native since it's 'int' not
>     > 'integer' "01"^^xs:integer     // not native since it's not in
>     > canonical form
>
>     +1
>
>
> +1
>
>     > These rules will make xs:integer data round tripping through JSON-LD
>     > perfectly lossless, I believe, on systems that can handle at least
>     > 32 bit integers.
>
>     Yeah, but I'm still concerned about the downsides of limiting the
>     number
>     to 32-bits, especially since most of the world will be using 64-bit
>     machines from now on.
>
>     I do agree that we might be able to change the text to ensure that
>     precision loss isn't an issue, and I do agree with you that it's
>     definitely worth trying to prevent data loss.
>
>     Tracking the issue here:
>
>     http://lists.w3.org/Archives/Public/public-rdf-wg/2013May/0136.html
>
>     > On a related topic, there's still the problem of xs:double.  I don't
>     > have a good solution there.   I think the only way to prevent
>     > datatype corruption there is to say don't use native number when the
>     > value happens to be an integer.
>
>     I don't quite understand, can you elaborate a bit more? Do you mean,
>     this would be an issue?
>
>     "234.0"^^xsd:double --- fromRDF() ---> JsonNumber(234)
>
>
> I think doubles are much more tricky. There is indeed the problem of 
> double values that happend to be integers, but there is also the 
> problem of some decimal number having no exact double representation 
> (such as 0.1). So round-tripping doubles seems much more hazardous 
> anyway...
>
> Maybe there should be two flags: one that preserves round-trip 
> (canonical booleans and ints) and one that does not (all booleans and 
> ints + doubles) ??
>

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.

That seems like the best path forward.

         -- Sandro

>   pa
>
>
>
>     -- manu
>
>     --
>     Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>     Founder/CEO - Digital Bazaar, Inc.
>     blog: Meritora - Web payments commercial launch
>     http://blog.meritora.com/launch/
>
>