[Nexus] Correct way to specify multiple signals

[V. Armando Solé]

On 12/01/2018 11:43, Peter.Chang at Diamond.ac.uk wrote:
> We don't need to have one solution to fix everything. I consider multiple signals to be a separate problem needing a separate solution.

Fine.
Can you take a look at the subject of this thread?
Let's not diverge again.
I consider the sentence "multiple signals need a separate solution" in a
thread entitled  "Correct way to specify multiple signals" quite meaningful.
Many good ideas have shown up in this thread but what we want is in the
subject.

If somebody else wants something else, please open a different thread.

We (ESRF) need a solution to specify multiple signals. There are several
clear use cases and the fact that many people had been using signal="1",
signal="2", and so on in the past should be enough to tell this
community that there is a clear need.

There are other cases, but the one most in-line case with the current
use of NXdata is to be able to specify the default plot associated to a
measurement where the user was visualizing multiple counters at
acquisition time:

- CASE1: EXAFS energy scan with multielement detectors where a ROI is
plotted for each detector element.
- CASE2: Contents of ROIs of different elements on single XRF spectra
collected as function of a motor position
- CASE3: Measurement of a simple rocking curve before and after some
beamline optical element
- ...

Please, do not tell me that at your beamlines you never visualize more
than one signal at acquisition time on the same plot.

When I started the thread I was aiming for something allowing me to
specify more than one signal by passing an array of strings as the
signal attribute or a single string with datasets separated by ",". The
auxiliary_signals option is fine for us too as it has the non-negligible
merit of not conflicting with any existing code. Because of that, my
feeling is that it is so cheap and clean that we are going to implement
it in any case and if one day the signal attribute is allowed to be an
array of strings or any other official solution is adopted we'll drop it.

Best regards,

Armando