Re: [Json] Human JSON (Hjson)

Peter Cordell <petejson@codalogic.com> Thu, 26 May 2016 11:03 UTC

Return-Path: <petejson@codalogic.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B906012DD3C for <json@ietfa.amsl.com>; Thu, 26 May 2016 04:03:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level:
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo214TsmXgiF for <json@ietfa.amsl.com>; Thu, 26 May 2016 04:03:08 -0700 (PDT)
Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C336812DD33 for <json@ietf.org>; Thu, 26 May 2016 04:03:07 -0700 (PDT)
Received: (qmail 11106 invoked from network); 26 May 2016 11:58:15 +0100
Received: from host86-178-51-202.range86-178.btcentralplus.com (HELO ?192.168.1.72?) (86.178.51.202) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 26 May 2016 11:58:15 +0100
To: json@ietf.org
References: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com>
From: Peter Cordell <petejson@codalogic.com>
Message-ID: <82b2ba3f-a6c2-c98b-b365-b698ab285149@codalogic.com>
Date: Thu, 26 May 2016 12:03:02 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <9ec25767-7471-2ca3-ded5-afed67863742@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/rTM6csT-fPbf-zDoD8mDPchIAxA>
Cc: Christian Zangl <coralllama@gmail.com>
Subject: Re: [Json] Human JSON (Hjson)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 May 2016 11:03:11 -0000

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

On 24/05/2016 22:36, Christian Zangl wrote:
> JSON is used in a lot of places and has helped improve things like data
> exchange and data storage. It is also used in areas it's less suited
> for, like configuration files. People seem to prefer JSON for
> configuration over YAML and other config formats.
>
> I started Human JSON (Hjson) because I found the experience frustrating
> (for example missing/trailing comma problems, no comments). With Hjson
> you get a superset of JSON that allows you to
>
> - add #, // or /**/ comments,
> - omit quotes for keys,
> - omit quotes for strings (terminated by LF, no escapes),
> - omit braces for the root object,
> - omit the comma at the end of a line
> - add trailing commas and
> - use multiline strings with proper whitespace handling.
>
> These changes should make it easer to read and write configs while still
> preserving the power of JSON.
>
> Joe Hildebrand approached me with an idea to publish Hjson as a RFC. You
> can find the draft here: http://hjson.org/rfc.html There are also syntax
> diagrams and more at http://hjson.org/syntax.html
>
> Thoughts?
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
> .
>