Comments in JSON

#1

Post by p3drosola » Fri, Aug 02, 2013, 1:58 PM UTC

Re: Comments in JSON

#2

Post by varikin » Fri, Aug 02, 2013, 2:22 PM UTC

This sounds great until some parser uses the comment definition instead of the value. Is it defined in the spec that parsers need to use the last defined value for a key?

Re: Comments in JSON

#3

Post by davidradcliffe » Fri, Aug 02, 2013, 2:26 PM UTC

Neat trick! Not sure I'd trust it, and might be confusing for anyone reading who didn't know this.

Re: Comments in JSON

#4

Post by dak1 » Fri, Aug 02, 2013, 2:27 PM UTC

varikin wrote: post #2

This sounds great until some parser uses the comment definition instead of the value. Is it defined in the spec that parsers need to use the last defined value for a key?

Since the order of an object's keys is not guaranteed, it seems like even if a parser respected the last-defined rule, you could still potentially end up with the wrong field last.

Re: Comments in JSON

#5

Post by nonchalance » Fri, Aug 02, 2013, 2:28 PM UTC

The JSON RFC (http://www.ietf.org/rfc/rfc4627.txt?number=4627) says

    The names within an object SHOULD be unique.

SHOULD is defined (http://www.ietf.org/rfc/rfc2119) as

    3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
       may exist valid reasons in particular circumstances to ignore a
       particular item, but the full implications must be understood and
       carefully weighed before choosing a different course.

Salient point is that you would need to ensure that you are only using JSON parsers that tolerate duplicate names (and use the last value)

Re: Comments in JSON

#6

Post by ygra » Fri, Aug 02, 2013, 2:30 PM UTC

varikin wrote: post #2

This sounds great until some parser uses the comment definition instead of the value. Is it defined in the spec that parsers need to use the last defined value for a key?

Not really defined, but since an object is defined as an unordered collection of key/value pairs, a conforming parser could probably shuffle the pairs before parsing them.

Re: Comments in JSON

#7

Post by hosay123 » Fri, Aug 02, 2013, 2:30 PM UTC

This would completely break any event driven (streaming) parser.

Re: Comments in JSON

#8

Post by [deleted] » Fri, Aug 02, 2013, 2:32 PM UTC

dak1 wrote: post #4

varikin wrote: post #2

This sounds great until some parser uses the comment definition instead of the value. Is it defined in the spec that parsers need to use the last defined value for a key?

Since the order of an object's keys is not guaranteed, it seems like even if a parser respected the last-defined rule, you could still potentially end up with the wrong field last.

[deleted]

Re: Comments in JSON

#9

Post by basicallydan » Fri, Aug 02, 2013, 2:33 PM UTC

This is a nice trick, but probably only should be used in systems where the set people touching the code is a limited, rarely-changing set of people and anything using the JSON is strictly going to treat the last defined value as the value to use. Dragons lurk elsewhere!

Re: Comments in JSON

#10

Post by treerex » Fri, Aug 02, 2013, 2:38 PM UTC

ygra wrote: post #6

varikin wrote: post #2

This sounds great until some parser uses the comment definition instead of the value. Is it defined in the spec that parsers need to use the last defined value for a key?

Not really defined, but since an object is defined as an unordered collection of key/value pairs, a conforming parser could probably shuffle the pairs before parsing them.

I suppose it could, but the point of the object being defined as an unordered collection is because the most straight-forward way of implementing this is through a hash table, where the order of the keys cannot be guaranteed without additional work. I'm sure they didn't consider a parser randomly permuting the lexical order of the pairs as something a sane person would do.