Use of a convention for XML to JSON translation

[ilpint]

There are some convention, already widely used for mapping XML and JSON.

Using a convention is suggested for the parts of the XML where there is the possibility of 1:1 conversions, just to have a way to express an element or an attribute consistently.
The chosen convention will not apply to new objects that shall exists only in the JSON format.
The chosen convention will not apply to StationXML elements that need to be profoundly changed.

List of possible conventions:

BadgerFish
gdata
JsonML

more ...

We need to choose a suitable convention.

Some examples are added.

IV-Z3.badgerfish.json
IV-Z3.gdata.json
IV-Z3.jsonml.json

[crotwell]

This idea of a convention is wise to think about, and in general, I think following existing conventions is a really good idea. However, I think all three of these are more than just xml to JSON conventions, they are trying to preserve the XML structure within JSON in way that allows reversing the mapping back to the XML. I do not think we need to do that. I feel a mapping from XML to JSON that preserves (most of) the content is important. But preserving the element-attribute-subelement structure is not. The resulting JSON must feel natural. In other words we are designing a new seismic metadata format using JSON, we are not cloning StationXML into the guise of JSON.

A simpler mapping might be:

1. Elements with complex content (subelements or many attributes) map to object, either with a "type" key, value pair or the key within the parent object being the element name
2. Attributes and Elements with simple content (string, number, boolean) are mapped to simple key value pairs within the parent object.
3. Repeating elements within a parent become an array
4. None of rules 1-3 are absolute and can be modified if the mapping feels awkward or inefficient.

This is roughly what I have done in the strawman examples I have created.

[marcelobianchi]

I also have the feeling that using any of those more structured translations remove the readability of the file other than by code, something that we gainned when we moved from SEED to station xml. Another points that they will retain the current structure.

My view is to start simple (objects, key-pairs and lists), and as we move, if it is absolutly needed we could re-consider.