Triggered by a discussion in the CTA IRF group about what this standard says about file formats,
we need to clean up some inconsistencies.
E.g. the about section claims:
All of the data formats described here at the moment can be, and in practice mostly are, stored in FITS. Some experimentation with HDF5 and ECSV is ongoing. The data format specifications don’t explicity mention the serialisation format, but rather the key name and data type for each metadata or data field.
But the EVENTS documentation clearly states:
The EVENTS extension is a binary FITS table that contains an event list.
I guess we want to be open about this.
It might be difficult to remain file format agnostic in the definitions while still being normative enough for a specific file format.
So maybe we should mark sections specific to certain file formats clearly as such, right now mostly for FITS specific things, but maybe nicely extendable to e.g. HDF5.
Triggered by a discussion in the CTA IRF group about what this standard says about file formats,
we need to clean up some inconsistencies.
E.g. the about section claims:
But the
EVENTSdocumentation clearly states:I guess we want to be open about this.
It might be difficult to remain file format agnostic in the definitions while still being normative enough for a specific file format.
So maybe we should mark sections specific to certain file formats clearly as such, right now mostly for FITS specific things, but maybe nicely extendable to e.g. HDF5.