Continuing the discussion in #417
The processing section should ideally be either dynamic since new methods might be added in future. And even if not, putting an /ENTRY[entry] for each of the processing methods seems cumbersome.
I think with a decorator, this could section could perhaps be entirely autogenerated e.g.
"/ENTRY[entry]/PROCESS_MPES[process]/energy_calibration":{
"coefficients": "@attrs:metadata/energy_calibration/calibration/coefficients",
"fit_function": "@attrs:metadata/energy_calibration/calibration/fit_function",
"original_axis": "@attrs:metadata/energy_calibration/tof",
"calibrated_axis": "@attrs:metadata/energy_calibration/calibration/axis",
"calibrated_axis/@units": "eV"
},
has all keys heirarchically arranged, so one just needs to parse them (it should rather be calibration/energy_calibration/.. than energy_calibration/calibration, so that all calibrations can come under that section).
Also, in/after #429 we should definitely add package name/version/etc. to the metadata so the workflow is completely reproducible.
Continuing the discussion in #417
The processing section should ideally be either dynamic since new methods might be added in future. And even if not, putting an /ENTRY[entry] for each of the processing methods seems cumbersome.
I think with a decorator, this could section could perhaps be entirely autogenerated e.g.
has all keys heirarchically arranged, so one just needs to parse them (it should rather be calibration/energy_calibration/.. than energy_calibration/calibration, so that all calibrations can come under that section).
Also, in/after #429 we should definitely add package name/version/etc. to the metadata so the workflow is completely reproducible.