Data center added namespaces in StationXML

[ilpint]

Data centers usually extends with proprietary namespaces the StationXML file format.
We need to decide if and how to express this information in the JSON format.

[crotwell]

Two possibilities I can think of, maybe not mutually exclusive:

1. Mapping non-stationxml elements and attributes is out of scope for this specification and is it is up to the creators to define how to map them into FDSN_JSON
2. Provide some kind of meta object at various places within the objects (top, network, station, channel?) as a container for other stuff.

[marcelobianchi]

• Any of the possibilities would need a custom reader that handle the proprietary extensions.

• Option 2 at least defines an extension namespace to be populated and inhibts name clashes. And even a reader that is not aware of the extensions could easily ignore and remove them properly without any effort. This is the most important thinking for the future to me.

the number 2 would be something like:

1. Add a meta to the top-level, with some basic meta tags (like version, and generator, and ... ). The meta would have a special key named like 'extensions' : ... with a list of extensions that used in the current file.

2. Extensions are defined by its creators but they live inside a { 'extension' : } object in any of the allowed objects.

3. Btw. I would prefer to decide not on the levels that could have an extension, but we should focus on levels that should not be allowed.

[ilpint]

I agree with @marcelobianchi's last comment on everything except point 3. I don't understand why a certain level should be considered closed to extensions. Is there a general criterion to apply when choosing, or do you plan to proceed on a case-by-case basis? Could you provide an example?

[marcelobianchi]

Could you provide an example?

I was thinking on very basic types, like 'latitude', 'longitude' ... , or even response type elements like poles, zeros, .... .