XSLT file for translation

[ilpint]

It is useful to provide an XSLT file for the transformation from StationXML.
The file could be used by early adopters of the JSON format to easily extend their fdsnws/station webservice adding just a translation layer on the web server or at the final application layer.
This resource will be provided as an example of implementation of the specification.

[crotwell]

Very much agree with needing a transformation tool. I am less sure that it should be XSLT, but perhaps there is room for many tools, as long as they are not all seen as normative..

[marcelobianchi]

While reading this, and the original issue some things came to my mind and I think we should consider:

1- Datacenter (as data holders) are not the authoritative source of metadata. They do hold large amount of metadata information. But they don't generate them and are normally not authoritative. Data producers are.

2- In my view xslt tools could be usefull for fast translation but are not ideal for handling it. In the long term would be more usefull to have a proper tool designed for the format, and not focused on translating.

My point here is that I think that we should focus on tools that allow for the mess to be reduced. I.e today datacenters records 1000 times the same information in response for exemple. Also, sometimes we find channels that don't fit stations, stations that don't fit networks (by dates). If we could tackle that during conversion, would be nice addition to the community.

[ilpint]

1- Datacenter (as data holders) are not the authoritative source of metadata. They do hold large amount of metadata information. But they don't generate them and are normally not authoritative. Data producers are.

Exactly, we at INGV are both data holders and producers for much of the metadata offered, so the boundaries between the two roles are a bit blurred. However, you were right to clarify to avoid ambiguity.

2- In my view xslt tools could be usefull for fast translation but are not ideal for handling it. In the long term would be more usefull to have a proper tool designed for the format, and not focused on translating.
My point here is that I think that we should focus on tools that allow for the mess to be reduced. I.e today datacenters records 1000 times the same information in response for exemple. Also, sometimes we find channels that don't fit stations, stations that don't fit networks (by dates). If we could tackle that during conversion, would be nice addition to the community.

I also think that in the long run all metadata workflow will shift to JSON also in databases and other software and services.
But I'm not sure to have understood what kind of features a "proper tool designed for the format" should have.

[marcelobianchi]

I was refering to have tools to be able to load the metadata into a code were validation logic could be added more easily. And not just manipulate to change format from tag to tag. Was thinking more on the user and usertools.