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

Re: more (ugh) on JSON-LD numbers

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Wed, 10 Jul 2013 09:09:02 -0700
Message-ID: <51DD871E.1010201@gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
CC: public-rdf-wg@w3.org

On 07/10/2013 08:00 AM, Markus Lanthaler wrote:
> On Wednesday, July 10, 2013 4:37 PM, Peter F. Patel-Schneider wrote:
>> Having been burnt more than once already on JSON-LD numbers, this time
>> I'm going to ask before stating.  :-)
>>
>> 1/  What is a JSON-native number, if it is not a JSON number from RFC
>> 4627, Section 2.4?
> If we talk about a JSON-native number we mean a number from RFC4627.
>
>
>> 2/ What JSON-native numbers can't be losslessly round-tripped through
>> RDF?
> It depends on the implementation.

What implementation fits in here?   We are talking about taking a bit of 
syntax - a JSON number - transforming it using an algorithm in the JSON API 
document to another bit of syntax - an RDF literal - and then transforming it 
using another algorithm in the JSON API document into another bit of syntax - 
a JSON number, again. Lossless round-tripping means that this double 
transformation is the identity map.
>
>
>> 3/ What is the fractional part of a JSON number if it is not fraction
>> part (frac) in RFC 4627, Section 2.4?
> fractionalPart = number mod 1;  // e.g. 1.5 mod 1 = 0.5
>
>
>
>> 4/ Which xsd datatypes are to be used for the following JSON numbers?
>>       0.0
>>       1.1E1
> xsd:integer
>
>
>>       0.1
>>       0.00000000000000000000000000000000000000001
>>       11E-1
> In most cases xsd:double.

Most cases?   Oh, perhaps you mean that some JSON implementations can't handle 
all these or that they round some of them to something that is like an 
integer.   But, again, these are just pieces of syntax.

If a JSON implementation could emit 
0.00000000000000000000000000000000000000001 the surely it should be able to 
determine that it has a non-zero fractional part and thus should be 
transformed into an xsd:double.

Actually a better case would have been 
1.00000000000000000000000000000000000000001 but I don't think that there is 
anything different about this one (which is the same as 1.0 in xsd:double, I 
think) from the preceeding case.
>
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
Received on Wednesday, 10 July 2013 16:09:32 UTC

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