Subject: [Json] Human JSON (Hjson)

From: Christian Zangl <[email-masked]>
Date: Tue, 24 May 2016 23:36:35 +0200

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?

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 25 May 2016 01:52:11 +0200

First, the name. If something calls itself X, it should be an X.

HJSON is not JSON.  It is a Hacked JSON.

Second,

> People seem to prefer JSON for

Can't be.  YAML *contains* JSON.
If you like JSON, you already like YAML, because every JSON file is a
YAML file.
(You may not like what else YAML brings to the table, but that would be
a mistake.)

(If you like JSON mostly because everything is JSON, well: HJSON isn't.)

Third, YAML also isn't stuck with the limitations of the JSON data model.
Binary data, maps with keys that aren't strings, etc.

I'm not opposed to writing a spec for a Hacked JSON.  However, I think
the time spent for doing that would be much better invested in an
updated spec for YAML.

Grüße, Carsten

---

From: Sean Leonard <[email-masked]>
Date: Tue, 24 May 2016 22:31:54 -0700

> the time spent for doing that would be much better invested in an

Yeah I pretty much agree with Carsten. A nice effort, but I do not 
support moving forward with this as-is. More thoughts in a separate 
e-mail (eventually).

Regards,

Sean

---

From: Sean Leonard <[email-masked]>
Date: Tue, 24 May 2016 23:48:02 -0700

On 5/24/2016 2:36 PM, 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 
> 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
>
> These changes should make it easer to read and write configs while 
> still preserving the power of JSON.

> Thoughts?

I read through the document with interest. It's a nice idea. I don't 
discourage it in general. But...

It seems that what you want is a configuration file format. There are 
already many config file formats, as well as many textual data formats. 
YAML comes to mind. This looks like YAML (certainly, a subset of it) a 
lot more than JSON or even JavaScript.

Why not just embed completely valid JSON items in the configuration file 
format of your choice? That seems a lot more practical. Configuration 
files usually say "name=value" anyway, not "name: value".

# is not comment syntax in JSON, or JavaScript. It's from config files 
and scripts. Hence demonstrating that this is not really JSON-related.

You say "omit braces for the root object", but then it's not JSON. If 
you include the braces, then it's JSON, and it's annoying for humans to 
write. Humans are lazy and don't like to balance < > tags or { } braces. 
They like line breaks by hitting Enter to separate things. But line 
breaks are not separators in JSON/JavaScript. JSON/JS are designed to 
let the author put in line breaks wherever he/she/it wants, to aesthetic 
taste. And vice-versa for commas. It's easy to balance { } braces when 
you just have a couple of them, i.e., a simple JSON object that is the 
single value of a single config element on a single line.

Your format should not get a media type. If it is for "humans", it needs 
to be text/*, such as text/plain. Humans edit things with editors, that 
work on text. As text, you cannot assume UTF-8 encoding. It's just a 
stream of text. If a user chooses to author this format in Shift-JIS (or 
if that's the locale/code page in effect on the local machine), that's 
the user's choice. You cannot ignore the implications of the charset 
parameter.

Finally, since the draft explicitly disavows use in transfer protocols 
and so forth, it's not appropriate for Standards Track. I'd suggest 
Experimental.

Regards,

Sean

---

From: Christian Zangl <[email-masked]>
Date: Wed, 25 May 2016 09:22:14 +0200

> If you like JSON, you already like YAML, because every JSON file is a

Hjson *contains* JSON, every JSON file is also a Hjson file, so you must 
like Hjson?

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 25 May 2016 10:16:03 +0200

> Hjson *contains* JSON, every JSON file is also a Hjson file, so you must

Since you ask what I like:

HUMANS SHOULD NOT BE WRITING JSON *), so, no, I don't like JSON as a
configuration file format.

The people I have met who didn't know about YAML usually liked
.ini-style **) configuration file formats, as exemplified by TOML ***).

Since my experience is that every configuration file format turns more
and more complex over time, I prefer to base them on a powerful generic
format such as YAML.  YAML is also pretty good in noise reduction.
(And, as I noted, if you are really itching to write JSON, or have some
JSON data that you just want to paste in, you can do so in YAML.)

As another data point, CBOR diagnostic notation is based on JSON.
Ouch; this is actually meant to be written and read by humans.
The CDDL draft then goes ahead and defines an extended diagnostic
notation to reduce some of the hurt (not needed for CDDL itself, but it
helps for notating CBOR examples, e.g., in the COSE draft).

Grüße, Carsten

*) https://mumble.org.uk/blog/2014/09/23/json-and-the-arguments/ and a
million other people have found that out...

**) https://en.wikipedia.org/wiki/INI_file

***) https://github.com/toml-lang/toml

---

From: Christian Zangl <[email-masked]>
Date: Wed, 25 May 2016 10:36:51 +0200

> lot more than JSON or even JavaScript.

Yes this is another config file format. Why? Because I think that using 
JSON for configs is an antipattern. Since YAML&others are not a good 
option (to some people) Hjson is positioned as a reasonable alternative.

> files usually say "name=value" anyway, not "name: value".

I'm not sure what you mean here. If I embed JSON in the config I have 
the same problems as using JSON for configs in the first place.

> and scripts. Hence demonstrating that this is not really JSON-related.

JSON was 'discovered' in JavaScript, hence it's name, but has since been 
ported to 50+ languages. While JavaScript is evolving, JSON is fixed at 
v1 (not a bad thing). So to me, apart from the name, JSON isn't 
JavaScript anymore.

JSON doesn't allow comments so selecting # seemed practical (IMO it's 
nicer to read than //). // and /**/ comments were added because it was a 
popular request.

> single value of a single config element on a single line.

Hjson is a superset of JSON. You don't have to omit them but they are 
optional for the root.

You need something to define the structure. Braces are there because 
JSON has them and because the alternatives (like indentation) seem worse.

Hjson allows line breaks to be separators instead of commas.

> the user's choice. You cannot ignore the implications of the charset

I can remove the media type but wouldn't it help with file 
associations/editor syntax?

Joe suggested to require UTF-8, it made sense to me. 
https://github.com/laktak/hjson/issues/43

> and so forth, it's not appropriate for Standards Track. I'd suggest

OK. Thanks for the feedback!

---

From: Stefan Reich <[email-masked]>
Date: Wed, 25 May 2016 18:27:32 +0200

---------- Weitergeleitete Nachricht ----------
Von: "Stefan Reich" <[email-masked]>
Datum: 25.05.2016 18:27
Betreff: Re: [Json] Human JSON (Hjson)
An: "Christian Zangl" <[email-masked]>
Cc:

I did a similar thing called JSON+C (JSON with comments).

Stefan
Am 24.05.2016 23:36 schrieb "Christian Zangl" <[email-masked]>:

> 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.
>
> (for example missing/trailing comma problems, no comments). With Hjson you
> get a superset of JSON that allows you to
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Christian Zangl <[email-masked]>
Date: Wed, 25 May 2016 23:42:52 +0200

> configuration file format.

Couldn't agree more!

> .ini-style **) configuration file formats, as exemplified by TOML ***).

While those are certainly better options it's not uncommon to see JSON 
configs. I'd like to get people to switch. If they switch to 
YAML/INI/TOML that's fine too. Even if you don't like the name, "Human 
JSON" signals that it's a format they already know. You can in fact just 
replace the parser and everything keeps working.

> format such as YAML.  YAML is also pretty good in noise reduction.

JSON is such a nice format because it's easy and requires almost no 
explanation. When you look at YAML it's not easy to guess what it does 
and yaml.org only makes it worse.

-chris

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 25 May 2016 23:58:55 +0200

Christian Zangl wrote:
> When you look at YAML it's not easy to guess what it does 

Not so sure about that -- kramdown-rfc is using YAML as its structured
part and people seem to be picking it up from the examples nicely.  (I
probably still have to improve those examples some more.)

> only makes it worse.

Now, there we have strong agreement.

(But that would be true for any format that tries to offer its spec as
its only documentation, or worse, its documentation as its spec :-)

This could be fixed without even changing the format at all.

Curious question: What part of HJSON is actually a subset of YAML?
What did you do that YAML doesn't have?

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 26 May 2016 06:53:59 +0200

Adding comments to JSON would IMO solve the "human" part.
It is already used in Chrome config files since ages back.

Anders

---

From: Stefan Hagen <[email-masked]>
Date: Thu, 26 May 2016 13:00:18 +0200

> On 2016-05-26 at 06:53 Anders Rundgren <[email-masked]> wrote:
> 

I second that. Nearly always switcted to using python dicts for edited config / foxtite files from JSON for the good readabiloty of commented entries and editor support.

"Stefan" # Like so ;-)

---

From: Peter Cordell <[email-masked]>
Date: Thu, 26 May 2016 12:03:02 +0100

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:
> .

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 May 2016 10:01:51 -0400

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

> 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.
>
> 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.
>

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.

---

From: Stefan Hagen <[email-masked]>
Date: Thu, 26 May 2016 16:31:36 +0200

> Am 26.05.2016 um 16:01 schrieb Phillip Hallam-Baker <[email-masked]>:
> 
> 
> 
>> On Thu, May 26, 2016 at 7:03 AM, Peter Cordell <[email-masked]> 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
> 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.
> 
> 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
> 

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?

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 May 2016 17:08:04 +0200

I don't normally reply to messages of this kind.
But since there are probably some new people around here who are not
used to these antics:

Phillip Hallam-Baker wrote:
> CBOR was not developed in an open fashion

Nope, you don't get to perpetuate that myth here.

(And, no, I'm also not interested in long messages redefining "open"
long enough that this statement turns into a form of true.)

> and now the same people who
> got to benefit from that end run around the IETF rules

You also don't get to bolster your arguments by personal attacks.

> want to block
> this work in favor of their pet ponies again.

And it also doesn't help if you frame the discussion in a destructive way.
Legitimate questions have been asked, facts have been stated, and
opinions (some more, some less well-founded) have been made known.
Enabling that kind of discussion is an important part of openness.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 May 2016 17:10:38 +0200

Carsten Bormann wrote:
(Things that I don't like to write.)

And back to something productive:

I think there is consensus that something would need to be added to JSON
to make it more amenable to configurations and other data entered and
edited by humans.  We all have different experience with the various,
well-tried approaches here (e.g., some found YAML too complex, some have
good experience with it; various other extensions to and variations of
JSON are embodied in various open source projects, and there are even
other approaches like TOML where it would be nice to understand the
reasons for their existence).  Based on these different experience
backgrounds we also have different opinions.

But that doesn't mean we can't converge on something.  The nature of a a
JSON working group is that it would tend to converge on "fixing" JSON.
Since this natural tendency (hammer/nail) always needs a bit of a
counteraction, I've been stressing that there are other approaches, such
as formalizing existing standards in this space.

Grüße, Carsten

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 May 2016 11:23:29 -0400

> long enough that this statement turns into a form of true.)

I was specifically told that my contributions were not wanted and unwelcome
because the work was being done by a private group that was not required to
be open or consider any external requirements.

That is a fact. It may not be a fact you want to hear but it is what
happened. That was the basis on which I made an appeal which also didn't
actually get heard because the AD didn't act on it until he decided it was
too late to do so.

> You also don't get to bolster your arguments by personal attacks.

I am simply stating what happened. If you are upset that the facts put the
behavior of some of the people supporting your proposal in a bad light,
that is not my fault.

Perhaps instead of attacking me for daring to raise the complaint you would
want to say 'I am sorry if your proposals were ignored unfairly'.

There is a reason I am angry about that behavior and I think I have every
right to be in the circumstances. And yes, I will continue to raise it each
and every time it appears something similar is happening.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 May 2016 17:15:21 +0200

Peter Cordell wrote:
> the same things, so I end up getting confused.  

I think it would be a great academic subject to study *where* people
stumble that try to pick up something like YAML.  Can you relate your
experience in some more detail (off-list if that helps)?

> It clearly fails at at

JSON was meant as an interchange format between programs, which don't
need comments to talk to each other.  (Also, if you do need to include
commentary material, you way want to process this together with the
other data, so you just add it as fields to your structure, keeping your
data model simple.)
[Just trying to relate the rationale as I have heard it expressed many
times.  Doesn't apply that much to config files, of course.]

Grüße, Carsten

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 May 2016 11:36:09 -0400

> as formalizing existing standards in this space.

YAML is not a markup language, it is called  "YAML Ain't Markup Language".

It is actually a schema format. While it might be useful to look at how
they solved the issues, 'use YAML' isn't actually very helpful.

What I do very much like about YAML is that it is indentation delimited
like Python, occam and most of my languages I have developed using Goedel.
However making that work with JSON which is brace delimited may be hard.

The way I avoided this issue in Goedel is that the language is indentation
delimited by default but it switches to brace delimited as soon as it hits
a brace and continues to be brace delimited until it hits the matching
close brace.

So the following would all be equivalent:

{ "Tag1" : { "Tag2" : { "Tag3" : "Data" } } }

Tag1
    Tag2
        Tag3 "Data"

Tag1 { "Tag2" : { "Tag3" : "Data" } } }

The second version is pretty much the Goedel syntax. I can show that is
unambiguous as I define it as a FSM and then produce the grammar from the
FSM.

---

From: Peter Cordell <[email-masked]>
Date: Thu, 26 May 2016 18:15:30 +0100

> experience in some more detail (off-list if that helps)?

I'll do one round on-list in the hope that it's helpful for some 
possible future work:

- The specification is long!

- Having two forms - block style and flow style - doubles the confusion

- As a C family programmer, the block format doesn't 'speak' to me,
   (whereas the JSON format does)

- I haven't done YAML for the other reasons, but I imagine getting the
   indentation right with lists started by '-' is annoyingly fiddly.
   Hence I'm put off going down that path before even trying it.

- Perl-esq levels of non-intuitive magical characters

- There looks to be things like namespacing which for most things I
   probably won't need.  Alas, because they are there, at some point
   some bright spark will use them, which means I will have to support
   them.  So though I could look at things like that as 'optional' at
   some point they probably won't be, in much the same way that if you
   attempt to use a simplified XML processor, at some point it will bite
   you!

> times.  Doesn't apply that much to config files, of course.]

While I understand that rationale, when you have a text based format 
that can be consumed by services I still think it was naive to not 
anticipate that people would want to create their own hand edited 
versions, perhaps for test purposes, and squirt them into services to 
see what happens.   From there, config files are a small step.  Indeed, 
it's also naive to not expect a successful 'thing' to be used beyond the 
scope it was originally intended for.

But that's all water under the bridge, and there's little point crying 
over it, other than to perhaps note that "anything that can be edited in 
an editor will be edited in an editor, and anything that will be edited 
in an editor should allow comments" ;-)

Pete.

---

From: Christian Zangl <[email-masked]>
Date: Thu, 26 May 2016 23:44:21 +0200

On 2016-05-26 16:01, Phillip Hallam-Baker wrote:

> 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.
>

You still have a problem with the backslash in strings. On Windows you 
can't just copy&paste a path because all \ need to be escaped. Also 
config files sometimes contain regular expressions and having to escape 
the \ makes them unreadable.

That's why Hjson has quoteless strings that are raw strings ending at LF.

---

From: Christian Zangl <[email-masked]>
Date: Thu, 26 May 2016 23:44:44 +0200

> Curious question: What part of HJSON is actually a subset of YAML?

There is no relation to YAML (other than being a superset of JSON), at 
least not on purpose.

> What did you do that YAML doesn't have?

I think it's the other way around. Hjson is less complex and easier to 
understand.

Also YAML is based on whitespace for structure while Hjson uses braces. 
(there are apparently two camps on what is better)

---

From: Christian Zangl <[email-masked]>
Date: Thu, 26 May 2016 23:44:56 +0200

> It is already used in Chrome config files since ages back.

Most mistakes are made by either missing a comma or adding a trailing one.

---

From: Christian Zangl <[email-masked]>
Date: Thu, 26 May 2016 23:52:31 +0200

You are quite right that there are a lot of solutions to this problem. 
The most known ones are JSON5 and maybe CSON. Others are not that easy 
to find though I remember at least three variants that shared some 
syntax with Hjson. Most of them, including Hjson, were started because 
there was no recommended format to be found.

---

From: Christian Zangl <[email-masked]>
Date: Fri, 27 May 2016 12:06:07 +0200

On 2016-05-27 00:07, Phillip Hallam-Baker wrote:

>     You still have a problem with the backslash in strings. On Windows
>     you can't just copy&paste a path because all \ need to be escaped.
>     Also config files sometimes contain regular expressions and having
>     to escape the \ makes them unreadable.
>
> I don't like quoteless strings with spaces. I think they are going to
> cause serious problems.

Please explain.

> What I suggest instead is using the convention Windows itself uses, the
> 'verbatim string literal'.
>
> var path = @"C:\Users\Phillip\OneDrive\Repositories\Dalek Plans"
>
> is equivalent to:
>
> var path = "C:\\Users\\Phillip\\OneDrive\\Repositories\\Dalek Plans"
>
> The big limitation on @ strings is that the only escape you are left
> with is for quotes which are doubled up:
>
> "quoted" is written """quoted"""

@"" does not help readability. Not having quotes is IMO more elegant, 
makes copy&pasting easier and requires no explanation.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 May 2016 12:32:22 +0200

>> I don't like quoteless strings with spaces. I think they are going to

They sure work very well in YAML.
But the rules for what you can and cannot do there are sometimes
perceived as complicated (why do you need quotes here? Oh, the colon.):

    title: "6LoWPAN: the Wireless Embedded Internet"

But then YAML has additional, more powerful quoting mechanisms, such as:

    title: >-
      Information Technology -- ASN.1 encoding rules:
      Specification of Basic Encoding Rules (BER), Canonical Encoding
      Rules (CER) and Distinguished Encoding Rules (DER)

Grüße, Carsten

---

From: Peter Cordell <[email-masked]>
Date: Fri, 27 May 2016 12:06:45 +0100

>     title: "6LoWPAN: the Wireless Embedded Internet"

And the '6' would prevent you using unquoted strings in HJSON.  That 
seems a bit error prone and worries me.

Something like the following might work:

     title :> 6LoWPAN: the Wireless Embedded Internet

But then it's not that much harder just to quote the whole string.  Hum!

Pete Cordell
Codalogic Ltd

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 May 2016 13:14:15 +0200

Peter Cordell wrote:
> And the '6' would prevent you using unquoted strings in HJSON.  

Hmm,

http://hjson.org/syntax.html

says something different (but what it says clearly cannot be true).

Grüße, Carsten

---

From: Peter Cordell <[email-masked]>
Date: Fri, 27 May 2016 12:25:02 +0100

> says something different (but what it says clearly cannot be true).

I was going by section 8.2 of http://hjson.org/rfc.html

Pete.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 May 2016 08:08:04 -0400

>       Rules (CER) and Distinguished Encoding Rules (DER)

Where does whitespace get added to the final string and what whitespace is
added? Does the string have two newlines or none?

Are these strings different or identical?

     This is a test string.

     This is a
     test string.

     This is a
     test string.

I am not even sure that the example will survive email. It certainly won't
survive auto formatting on a lot of editors that prune away trailing spaces.

Verbatim strings have a long history going back to Pascal. The @ escape
isn't pretty but it is a well established mechanism familiar to millions of
coders. The user base of YAML really isn't in the same league as C#.

---

From: Christian Zangl <[email-masked]>
Date: Fri, 27 May 2016 22:46:43 +0200

>     title: "6LoWPAN: the Wireless Embedded Internet"

If you look at the syntax it says "Because the punctuator characters 
{}[],: are used to define the structure of the Hjson text, you need to 
use quotes [..] if your string starts with a punctuator"

so your example is valid without quotes, after the first character 
anything is allowed.

      title: 6LoWPAN: the Wireless Embedded Internet

>       Rules (CER) and Distinguished Encoding Rules (DER)

This is similar to Hjson's multiline except that Hjson will keep all LFs 
while YAML eats them sometimes.

---

From: Christian Zangl <[email-masked]>
Date: Fri, 27 May 2016 22:52:52 +0200

> seems a bit error prone and worries me.

That's not correct. The following is a valid unquoted string:

In fact you can just paste this line into http://hjson.org/try.html

---

From: Christian Zangl <[email-masked]>
Date: Fri, 27 May 2016 22:59:47 +0200

> I was going by section 8.2 of http://hjson.org/rfc.html

Not sure how you came to that conclusion. My (S)ABNF is IMHO correct as 
it passes all test cases. 8.2 also has some examples:

A Hjson parser must still detect values (number, true, false or null) 
and parse them correctly. For example

      ‘3’ is the number 3
      ‘5 times’ is the string “5 times”
      ‘true’ is the boolean true
      ‘7 # minutes’ is the number 7 followed by a comment
      ’\s#([0-9a-fA-F]{3})’ is the string “\\s#([0-9a-fA-F]{3})”

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 30 May 2016 10:56:32 +0900

> unambiguous as I define it as a FSM and then produce the grammar from the

Just a quick comment: As far as I understand, a FSM (finite state 
machine) isn't able to grok any of the above, unless you limit the 
number of indentation/nesting levels. An FSM leads to a regular grammar, 
whereas a context-free grammar is needed to parse nesting constructs 
with arbitrary depth. The corresponding automaton is a push-down automaton.

Regards,   Martin.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 29 May 2016 22:02:04 -0400

On Sun, May 29, 2016 at 9:56 PM, Martin J. Dürst <[email-masked]>
wrote:

> Just a quick comment: As far as I understand, a FSM (finite state machine)
> isn't able to grok any of the above, unless you limit the number of
> indentation/nesting levels. An FSM leads to a regular grammar, whereas a
> context-free grammar is needed to parse nesting constructs with arbitrary
> depth. The corresponding automaton is a push-down automaton.
>
> Regards,   Martin.
>

You have to add a stack. But you have to do that to parse JSON anyway to
parse the braces.

Indentation delimited is pretty easy to code, just count leading spaces, if
the number increases, emit a brace, if it reduces emit as many braces as
necessary