what _is_ the array? Is it a patch? A canvas? A file? When you use a

dictionary, the name of the key is helpful in clearing this up.

Well ... this just cosmetics ... I think the array is very flexible, in that you can just stuff objects in there. And, there will be arrays anyways. What you suggested is actually not possible :

{ "elements" : { "obj" : {"id" : 0, "type": "osc~", "args": [440]}, "obj" : {"id" : 1, "type": "dac~"}, "connect" : {"from": [0, 0], "to": [1, 0]}, "connect" : {"from": [0, 0], "to": [1, 1]} } }

In a map, keys need to be unique. So, you would need to write :

{ "elements" : { "obj" : [ {"id" : 0, "type": "osc~", "args": [440]}, {"id" : 1, "type": "dac~"}, ], "connect" : [ {"from": [0, 0], "to": [1, 0]}, {"from": [0, 0], "to": [1, 1]} ] } }

Which imo, is not much better than :

[ {"class": "object", "id" : 0, "type": "osc~", "args": [440]}, {"class": "object", "id" : 1, "type": "dac~"}, {"class": "connect", "from": [0, 0], "to": [1, 0]}, {"class": "canvas", ...}, ]

in that there is less nesting, it is thus a bit simpler... but I guess that's a detail.

It can also simplify parsing order

That's true ...

I think [GUI info] deserves a classification higher than 'extra info'. A formal extension of the format, so to speak, since the majority of use cases involving a pd patch will require a visual layout.

That's a very good point, ... it's a good idea to specify GUI infos, for better interoperability, but it should be explicitly said that this is optional information, and parsers must handle the case when those are missing.

@Jonathan : Yes, backward compatibility is mandatory, in that the new format must be a subset of the old format - I mean, "semantical" subset : it must be able to contain all the infos contained in old file format And we suggested to write a converter to help this.