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

RE: Updated JSON-LD spec to more closely align w/ RDF data model

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Tue, 9 Jul 2013 15:20:22 +0200
To: "'RDF WG'" <public-rdf-wg@w3.org>
Message-ID: <018101ce7ca7$11dd9500$3598bf00$@lanthaler@gmx.net>
On Tuesday, July 09, 2013 2:29 PM, Peter F. Patel-Schneider wrote:
> On 07/09/2013 02:00 AM, Markus Lanthaler wrote:
> Well then what is JSON?   Is it only defined in terms of implementations?
> Which ones count?  Can I build an implementation of JSON, and have it
> count?


> Suppose that I wanted to find out about JSON numbers from JSON-LD. The JSON-LD
> document points me at RFC4627, plus it says that "[a] number is similar to
> that used in most programming languages", which isn't any help at all.
> RFC4627 points at ECMAScript Programming Language Standard, Third Edition,

It doesn't. It only say that it was derived from ECMAScript.

> plus it provides a grammar for numbers (after providing the "similar" phrase)
> which is, in essence, the grammar commonly used for floating point numbers in
> most programming languages.  But this grammar doesn't say anything about that
> JSON numbers really are, instead only providing a syntax.

It is a serialization format. What do you want it to say? What isn't clear?

> RFC4627 doesn't completely nail down the relationship between JSON and
> ECMAScript, only saying that "[JSON] is derived from the object literals of
> JavaScript".  "Derived from" could cover a multitude of relationships, but the
> only two real choices here are "subset of" and "different from". "Different
> from" isn't helpful at all, so someone who wants to determine what JSON
> numbers should be is pretty much left with "subset of."

Then just ignore that sentence or read it as "it has been inspired by ECMAScript".

> So one comes up with JSON numbers being a subset of ECMAScript, Version 3,
> numbers, which works out to IEEE floating point double minus NaNs,
> negative 0, and maybe infinities.

Which is not the same as JSON numbers.

> Of course, conforming JSON implementations can do lots of things. They could
> implement JSON numbers as strings, they could implement JSON numbers in base
> three, etc., etc.   However, they should (and it is very strange that the JSON
> specs don't support turning this should into something stronger) implement
> JSON numbers as if the numbers were turned into IEEE floating point double.
> However, when writing specifications on top of JSON any shoulds should
> be carried through.

Right. That would make some things much easier, others much more difficult. The fact though is that it does not and JSON-LD is build on top of JSON. 

> PS:  It appears that there is an IEEE working group set up to (re-
> )define JSON.

Right, I'm participating in those discussions. It's not a redefinition, it's a reclassification. RFC4627 is an informational RFC and contains some errors (e.g. the JavaScript code in section 6 contains a security vulnerability). The (current) charter of the JSON WG is to correct these errors by making *minimal* changes to RFC4627 and to republish it on the standards track. It will probably also contain a section describing the relationship to ECMAScript in more details.

The current draft can be found here in case someone is interested:

> PPS: ECMAScript Version 5.1 provides a parser for JSON.   If JSON actually is
> defined in terms of the current version of ECMAScript, then this is the
> definition of how JSON documents are turned into data.

It is not. The ECMAScript parser e.g. accepts top-level strings which are invalid in RFC JSON.

I wrote all of this already a couple of times and we discussed this several times both in the JSON-LD CG and with (some members of) the RDF WG. I don't see much value in discussing this again as nothing has changed in the meantime.

There's a section in the API spec summarizing these issues:

Markus Lanthaler
Received on Tuesday, 9 July 2013 13:20:54 UTC

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