silx.io.nxdata: Fixed parsing of NXcanSAS's @uncertainties

[t20100]

Regarding parsing of NXData, this PR:

• fixes the parsing of axes @uncertainties where a fallback was loading signal's @uncertainties: This is removed since it's nowhere in the specification and in contradiction with NXcanSAS application definition.
• adds support of NXcanSAS signal's @uncertainties. The implementation does not check whether it's inside a NXcanSAS application definition.

[kif]

Fixes the bug ...

[kif]

LGTM

[woutdenolf]

I vote against supporting this.

Required for generic NXdata plotting:

/entry/transmission_spectrum/T
/entry/transmission_spectrum/errors

Add NXcanSAS requirements (irrelevant for silx):

/entry/transmission_spectrum/Tdev -> ./errors
/entry/transmission_spectrum/T@uncertainties="errors"

Related issue: nexusformat/definitions#1185

[vasole]

Just in case, do not forget about the generic DATASET and DATASET_errors approach. This approach is becoming the preferred one in order not to rely on attributes (that are dangerous when using external links).

[woutdenolf]

Indeed, I have a proposal to make that part of the standard: nexusformat/definitions#1047. We already handle this in silx and h5web.

[t20100]

We can revert it if you want, up to you.

It would be best to have a single way to express uncertainties, but since @uncertainties is added as a fallback after DATASET_errors to me it is not a big deal to support it: it's not incompatible with NXdata and offers support for NXcanSAS.
BTW, it would be best to update NXcanSAS to be consistent with NXdata.

[woutdenolf]

BTW, it would be best to update NXcanSAS to be consistent with NXdata.

nexusformat/definitions#1185

[woutdenolf]

We can revert it if you want, up to you.

I personally would revert this as it sets a precedent for a direction we don't want to go in.

[t20100]

OK, then I'll revert