Requirement: Joint evolution of StationXML

[krischer]

Any NGF should jointly address an evolution of StationXML to optimize and complement the new format.

[chad-earthscope]

As written this requirement could be interpreted such that the next generation data format will be developed in tandem with an evolution of StationXML. The cross-over between the formats is primarily (completely?) limited to the time series identifiers. As long as the identifiers used in the NGF are directly comparable to or trivially mappable to the identifiers in StationXML then the development of both formats do not need to be locked together.

Of course care must be taken to make sure the identifier scheme allows association of time series in the NGF and metadata in StationXML. This could be simply done. For example, if a scheme for identifiers as outlined in issue #4 is adopted, then no changes to StationXML are strictly needed. If said proposal is adopted, it would be nice to add a "time series identifier" field to StationXML so channel entries could be directly related via a single identifier, but even that would not be necessary.

I think this should be a guideline, something to keep in mind, and not a requirement.

[crotwell]

I agree with Chad this is mostly just channel identifiers and likely can be done without a new StationXML, but keeping the two specifications compatible is a requirement. So perhaps rephrase to imply a revision of StationXML only if needed. Similarly the FDSN web services specification should also be kept compatible.

Any NGF should jointly address the evolution of StationXML and FDSN Web Services, if needed, to maintain compatibility with the new format.

[tim-iris]

I too agree with Chad and Philip on this. The naming conventions will impact StationXML necessarily but it would do this in a very straightforward manner that should not be controversial. Many issues int he time series format will not have impact in the metadata in StationXML

[megies]

Yeah, NSLC codes seem the only strong link and StationXML has no restrictions on them (besides type="xs:string"), so probably no adaptions necessary.

• https://github.com/FDSN/StationXML/blob/61fa828129eb50cb2a29599bd829116e84fa5ec2/fdsn-station.xsd#L329
• https://github.com/FDSN/StationXML/blob/61fa828129eb50cb2a29599bd829116e84fa5ec2/fdsn-station.xsd#L1052

[krischer]

Summary

(Please let me know if I missed a point or misunderstood something)

I'm not bringing this to a vote as the unanimous consensus is that only moderate changes to StationXML will be required (if any at all). Any incompatible changes in the new data format must force changes to the meta-data format in any case so this is not something that must be discussed but it must rather be kept in mind.