metadata captured in the Detector namespace

[bruceravel]

This is the first of a short string of issues I am opening up after doing some work on the specification document leading up to #28.

Items in this namespace are an area for which James advocated the use of tables in order to capture a full complement of information about the detectors. For example, an ion chamber might be identified by by any or all of length, gas content, voltage, gap, gas pressure, dark current offset, and details (shaping time, amplification, etc.) about the signal chain behind the detector.

The current spec does not provide any structure for a Detector header. The example XDI file in the specification document has lines like this:

# Detector.I0: 10cm  N2
# Detector.I1: 10cm  N2

Those contain some of the information James suggested should go into a table, but is actually just a free-form string.

Of course, something more complicated than an ionization chamber would require substantially more metadata.

The question is whether a free-form string is adequate for Detector-related metadata.

[newville]

I vote "free form string is good enough".

What is the intended use of this information?
If it is read by humans, then I'm not sure it matters much.
If it's to be read by machine, then probably JSON or related is preferred.

I'm not sure I see how the second scenario would be used. Would one ask the library for an XDI_File, and then ask for the "Detector" named "I0" and expect to get back some representation of that data? What would that representation be? Why not just a plain json string?

I'd happily change my vote if someone else issues a PR to implement and handle the parsing of a JSON (or similar) strings characterizing detector settings in the C, Fortran, and Python interface.