Subject: [Json] Meanwhile, out there...

From: Mark Nottingham <[email-masked]>
Date: Sun, 2 Mar 2014 08:38:13 +0000

<http://json5.org/>

> JSON5 is a proposed extension to JSON that brings ES5 enhancements to its syntax. It remains a strict subset of JavaScript, adds no new data types, and is astrict superset of existing JSON.

<https://news.ycombinator.com/item?id=7325735>

--
Mark Nottingham   http://www.mnot.net/

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 2 Mar 2014 09:46:42 +0000

>> JSON5 is a proposed extension to JSON that brings ES5 enhancements to its syntax. It remains a strict subset of JavaScript, adds no new data types, and is astrict superset of existing JSON.

This appears to only be meant to work in a Javascript program, yes? Otherwise, what the heck does "Object keys can be unquoted if they're valid identifiers" mean?

--Paul Hoffman

---

From: Tim Bray <[email-masked]>
Date: Sun, 2 Mar 2014 01:58:57 -0800

It says “this implementation doesn’t handle Unicode characters”.
 Unfortunately, that’s more or less all the characters I use.

Actually, quite sensible on the surface, aside from allowing +/-Infinity.

On Sun, Mar 2, 2014 at 1:46 AM, Paul Hoffman <[email-masked]> wrote:

> >> JSON5 is a proposed extension to JSON that brings ES5 enhancements to
> its syntax. It remains a strict subset of JavaScript, adds no new data
> types, and is astrict superset of existing JSON.
>
> This appears to only be meant to work in a Javascript program, yes?
> Otherwise, what the heck does "Object keys can be unquoted if they're valid
> identifiers" mean?
>
> --Paul Hoffman
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 2 Mar 2014 11:41:59 +0000

> <http://json5.org/>

In other news, there are $ NI * NV + 1 $ JSON variants (where $ NI $ = number of implementations, $ NV $ = average number of configuration variants per implementation, $ + 1 $ for the standard itself).

Embrace and extend works for open source, too.
Putting in a clever extension to JSON can be exploited to create customer lock-in for an open-source library.
That’s why smart people use standards.

Grüße, Carsten

---

From: "Pete Cordell" <[email-masked]>
Date: Sun, 2 Mar 2014 12:15:34 -0000

Actually, I really wish the IETF would grab the bull by the horns and define 
a notation that is geared towards it's purposes rather than continually 
making do with everyone else's second-hand cast offs!

I think something JSON like would be good, but with a few modifications. 
For example SHON - Simple Humanized Object Notation:

// Implicit initial object - no {
// Comments are allowed
a_name_without_space: 12
// Unquoted whitespace without a comma separates records
"a name with spaces": 14
an_array: 15, 16, 17    // Commas implicitly create an array
an_array: 18    // Another member for an_array
a_string: "A string"
another_string: 'Another string'
an_object: { /* as JSON */ }

</rant>

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
----- Original Message ----- 
From: "Tim Bray" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>
Cc: "Mark Nottingham" <[email-masked]>; "JSON WG" <[email-masked]>
Sent: Sunday, March 02, 2014 9:58 AM
Subject: Re: [Json] Meanwhile, out there...

> Otherwise, what the heck does "Object keys can be unquoted if they're 

--------------------------------------------------------------------------------

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 2 Mar 2014 12:50:48 +0000

On 02 Mar 2014, at 12:15, Pete Cordell <[email-masked]> wrote:

> SHON - Simple Humanized Object Notation

YAML already fills this niche rather nicely.
It is a stable, widely implemented specification.
(It also happens to include JSON as a subset.)

There often is confusion because JSON is “human-readable”.
However, JSON is for app-to-app, not for human-to-app.
Most naive JSON extension proposals are based in not understanding this fine point.

In a pinch, JSON can be used for human-to-app.
But instead of trying to extend JSON to become another YAML, just use YAML for human-to-app.

(Human-readable, more generally speaking text-based, formats have certain advantages over binary formats even for app-to-app.
Insert MEGACO flip-a-coin story here.)

Grüße, Carsten

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 2 Mar 2014 15:24:07 +0000

On Sun, Mar 2, 2014 at 12:15 PM, Pete Cordell <[email-masked]>wrote:

> Actually, I really wish the IETF would grab the bull by the horns and
> define a notation that is geared towards it's purposes rather than
> continually making do with everyone else's second-hand cast offs!
>

Well I could add these as variant syntax in JSONSchema

https://sourceforge.net/projects/jsonschema/

It is a bit of a misnomer now because I had to write a HTTP server so I
added in a parser/encoder module for RFC822 headers.

At the moment I have three variations on JSON that extend the JSON core
incrementally

JSON-B   Adds length delimited binary blobs and strings so that it is not
necessary to mess about with BASE64 encoding or escaping UNICODE strings.
This makes modularity a lot easier as it is now easy to wrap one JSON
structure inside another.

JSON-C  Adds in the compression capabilities people often insist are needed.

JSON-D Supports a full range of binary encodings for data etc.

I am thinking about adding in JSON-A which would be an extension to the
ASCII control codes. While people say JSON is a UNICODE format this is only
actually true of JSON strings. It is not legal for a JSON encoding to have
UNICODE characters anywhere else.

Comments are a commonly requested feature. They are essential for using
JSON for configuration so lets add them.

Another essential capability is being able to use JSON for append-only log
file updates. Most operating systems have handlers that can be used to make
append only access transactional.

I will think about the consequences of making LF an implicit comma.

-- 
Website: http://hallambaker.com/

---

From: John Cowan <[email-masked]>
Date: Sun, 2 Mar 2014 11:41:16 -0500

> Actually, quite sensible on the surface, aside from allowing

I was thinking just the opposite; that's one of the few advantages
of JSON5.  The rest is nothing but surface syntactic variation, and the
only time that helps is when you're writing JSON by hand.  (Comments can
be handled using conventional object keys.)

Paul Hoffman scripsit:

> This appears to only be meant to work in a Javascript program,
> yes? Otherwise, what the heck does "Object keys can be unquoted if
> they're valid identifiers" mean?

It means just what it says: that you can omit the quotes around a JSON5
key if it happens to also be a valid JavaScript identifier.  The only
reason this isn't already so is that the inventor of JSON didn't want
to burden the definition of JSON with the list of 57 JavaScript reserved
words (as of ES3) that can't be identifiers.

In ES5 this isn't a problem any more, but there's a lot of legacy ES3.

-- 
By Elbereth and Luthien the Fair, you shall     [email-masked]
have neither the Ring nor me!  --Frodo          http://www.ccil.org/~cowan

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 2 Mar 2014 21:58:45 +0000

> In ES5 this isn't a problem any more, but there's a lot of legacy ES3.

Since at this point we are far beyond JavaScript, this does not concern me
at all.

For purposes of IETF specs it is probably imprudent to use any reserved
word from SQL, Java, C# or C as a field name.

---

From: John Cowan <[email-masked]>
Date: Sun, 2 Mar 2014 20:13:13 -0500

Phillip Hallam-Baker scripsit:

> Since at this point we are far beyond JavaScript, this does not concern
> me at all.

Since JSON is, always has been, and I trust always will be a subset of
ECMAScript 3, I don't know what that even means.

-- 
John Cowan   <[email-masked]>   http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script.  One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.'  --Beverly Erlebacher