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

On 05/14/2013 03:01 PM, Pierre-Antoine Champin wrote:
>
>
>
> On Tue, May 14, 2013 at 2:07 PM, Sandro Hawke <sandro@w3.org 
> <mailto: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 :)
>

Yeah, the point is the producer has no idea what environment the 
consumer will have.

Yesterday on the JSON-LD call, Gregg proposed a solution that I really 
like, which is to make the useNativeTypes conversion be done on a 
JSON-LD structure, so it's not part of the RDF Round Tripping at all, 
and can simply be done within a system (not usually for sending across 
the wire).   Within a system, lossy conversion can be detected.

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

Excluding xsd:decimal was Markus' idea, based on the thinking that the 
only reason someone uses xsd:decimal (instead of integer or double) is 
because they really want an exact representation, eg for money.   I 
think he's right about that.

       -- Sandro

>   pa