Re: [Json] Human JSON (Hjson)

[Phillip Hallam-Baker <[e-mail]>]

On Thu, May 26, 2016 at 7:03 AM, Peter Cordell <[e-mail]>
wrote:

> For me JSON is too simple, and YAML is too complex.  I've tried to get
> into YAML a couple of times, but it seems to have multiple ways to do the
> same things, so I end up getting confused.  It clearly fails at at least
> one level to be human friendly.  Why JSON doesn't have comments eludes me.
> JavaScript does, so missing that bit in the subsetting was a big drop off
> IMO.
>
> I'd love something that is more flexible than JSON, but less complicated
> than YAML.  While I might quibble about some of the choices in this
> proposal, the fact that it can be described as JSON with 7 lines of
> variations is a big win.
>
> What I find frustrating in this space is that protocols and specifications
> are the bread and butter of IETF.  And yet the IETF has put very little
> effort into developing 'tools' for this area (*).  And the really sad thing
> is that the reason is not because this is a difficult problem, but more
> that it is such a simple problem that everyone comes up with their own pet
> solution and they'd rather have no solution instead of someone else's
> solution.  As a result we end up with other groups second hand goods like
> XML and JSON.
>
> So I'd welcome it going forward in a form that would allow experience with
> working with the format and would be simple for a working group to adopt
> and put on standards track if they felt it was useful.  Perhaps as an AD
> shepherded individual RFC that can just be 're-badged' to put it on
> standards track if the desire arose.
>
> (* OK, we have ABNF, but that's the assembly language of protocol design
> and we should really be aspiring to higher levels of abstraction in this
> day and age.)
>
> Pete Cordell
> Read & write XML in C++, http://www.xml2cpp.com


This seems to be the 'stop people using JSON' working group.

Every single time someone suggests a variant of JSON, the response is 'NO'.
Which wouldn't be bad only then the same people get go off and design
something entirely different that doesn't match JSON at all.

So instead of adding binary extensions to JSON, we get CBOR, a completely
different specification that requires completely different tooling.

CBOR was not developed in an open fashion and now the same people who got
to benefit from that end run around the IETF rules want to block this work
in favor of their pet ponies again.

I suggest that we form a separate WG for encodings that are supersets of
JSON encoding but map back to the JSON data model. And if we can't form it
here, we take the work somewhere that is actually open and the insiders
club doesn't get to veto reasonable proposals so they can clear the track
for their own proposals.


A superset of JSON encoding optimized for human input makes a lot of sense.
In particular it should be possible for a single parser to read data in
either strict JSON or JSON-x. Which is what I did with JSON-B, JSON-C and
JSON-D.

I suggest the following additions:

1) Comments

2) Use of quotes on labels is optional if the label conforms to C-like
rules (does not start with a digit or contain white space, control or
punctuation marks.

3) Allow trailing comas

4) Punctuation optional in situations it is not ambiguous.