RE: In the spec, swap RFC4627 for RFC7159

On Thursday, March 06, 2014 5:14 PM, Thomas Steiner wrote:
> 
> Hi Markus,
> 
> > I've thought about this before myself but am still on the fence on what
to
> > do. Unfortunately, RFC7159 isn't simply a reclassification of RFC4627 to
> > bring it on the standards track but also contains a number of BC-
breaking
> > changes. For example, it loosens the restriction on top-level constructs
(in
> > RFC4627 only objects and arrays are allowed, in RFC7159 everything is).
I'd
> > thus prefer to not make this change at this point.
> 
> When you try to "lift" the trivial JSON object 42 (just the integer)
> to JSON-LD, you would have to convert it to something that is an
> object anyway in order for JSON-LD to make sense (you need a key,
> unless I am terribly mistaken). So you are right that allowing
> "everything" ("trivial" JSON) seems challenging, but probably not a
> problem in practice [citation needed].

The problem in practice is that none of the algorithms was written with that
in mind. The JSON-LD grammar makes this requirement explicit though.


> > Is there any reason to update the ref apart from "let's use the
> > latest stuff"?
> 
> This was my main motivation, especially given the challenges around
> JSON standardization. Finally, duplicate keys are disallowed, so this
> is definitely a good thing.

No, unfortunately they have not been disallowed. It's still exactly the same
as in RFC4627:

   "The names within an object SHOULD be unique."

Thus we also state in the JSON-LD spec that

  "In contrast to JSON, in JSON-LD the keys in objects MUST be unique."


> My preference would still be to swap to
> the new RFC, but nothing breaks if the spec references the old RFC.

I think it's better to wait for the next version of JSON-LD to make that
change. Especially given that RFC7159's grammar [1] contains a very
problematic error:

  JSON-text = ws value ws
  value = false / null / true / object / array / number / string

This means that

  3409 true 1949 false

Would be valid according the grammar. But no current parser will be able to
interpret that. Then there's also the question what we really should
reference? RFC7159? Why not ECMA-404?



[1] http://tools.ietf.org/html/rfc7158#section-2


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 6 March 2014 16:36:50 UTC