Re: [Json] Human JSON (Hjson)

[Stefan Hagen <[e-mail]>]

> Am 26.05.2016 um 16:01 schrieb 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.

I support all 4 selected additions proposed.

1 I already suggested

2) is nice albeit eg in dot language I never know if it irritates me more to have to add quotes for those labels needing them or that then the quoted and unqupted ones look somehow like from different classes ...

Ad 3)
It is not cool IMO to state the end of a sequence by absence of an element separator when there is in any case a terminating "embedding" token following.

Ad 4)
Iff we find a way to compactly describe these situations ;-)

Best, Stefan  # a valid array to the right?