Here is a working version of the input side as well.  It now has methods to export and import the Layout globals as well, and on import it compares the original with the imported version of the global.   The export and import distinguish between string and non-string types in a $List, which is necessary for a faithful round-trip.

I also ran into an issue where the JS output encoding erroneously escapes $C(11) as \v.  According to RFC 4627 it should not. 

However in order to successfully round-trip I had to add \v unescaping in the parser.

I'm not sure I've covered every possible round trip issue but it works for the Layout globals now.

The class that contains all the import and export methods is in the attached zip file. This is a rough cut but working.

Ted

tedjson1.zip

OK, I did the output side. It's fairly simple although the format options fatten it up a bit. There's also a method in here related to my Trak use case; it may be instructive as an example but probably not more than that.  After I do the input side we'll see where the round-trip holes turn up.

Ted

tedjson0.zip

I'm looking into this now. My use case is exporting a global tree in human-friendly form to facilitate tracking and editing in source control. Specifically I want to manage the Trak Layout export globals.

Conceptually it seems straightforward. These are my observations:

- $List is isomorphic to JSON array.

- String is isomorphic to a JSON string, with JS escaping. For binary values the escaping is not very compact, but it should be unique.

- a global node is isomorphic to a JSON "object", with the addition of a "special" property for the node's top value.

There are only a couple glitches I've thought of so far and they seem surmountable. Please let me know if you think of problems besides these.

- Empty-string is a valid $List. I propose to always output empty-string as "" and not [].  This should round-trip all right in either case but "" is simpler.

- The name of the special top-value property must never collide with an actual subscript name. I propose to use "^_" for this name. If that ever appears as a literal subscript I would fail with an error and advise the user to override the default top-node name to something that never appears in their global.

- There might be problems with round-tripping binary data or obscure Unicode strings through the JS escaping and UTF8 transformation but I haven't thought of any specific problem yet.

I'm going to try it and I'll let you know how it turns out.  If you think of any reasons it can't work please let me know. Even if it  only works in restricted cases it might still be useful.