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

Hi,

On Mon, May 13, 2013 at 3:45 AM, Manu Sporny <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.


>
> > 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)
??

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