Thursday, 16th Jan, 15:00 UTC
SB, AB, FS, WdN, HB, PC, BW, CZ, BB, RB, TC, RO + LukasP, MarkusK (FAIRmat)
AB: CodeCamp
BW: CC used to be organised in the year between full NIAC meetings.
AB: Let us make a poll for dates over the Summer.
PRs
1396
WdN: NXdata documentation with visual summary and pages with detailed descriptions.
AB: nice improvment. Since it does not change the standard itself, but improves the documentation. After careful review, it can be merged. PC, and SB volunteered for doing that.
Telco participants accepted it.
1511
PC: Make detector channel recommended instead of being required.
SB: If nothing mentioned then it is interpreted as required.
AB: It must be a mistake, so let us verify with Dectris and propose a fix afterwards.
Telco participants accepted it.
1521
Enable Open Enumerations.
AB: The requested modifications for clarity in documentation are addressed. Note that NXsource/type should be a closed controlled vocabulary.
BW: For open enumerations, validator may need the optional attribute ‘custom’ be represent that declares data items shall not be checked.
TC: Validator could use configuration file to see how to handle open enumerations. This configuration could add enumeration items
HB: Maybe more level could be added to open, and close, like regexp
SB: give WARNING if custom value is provided
RO: agreed with giving WARNING, but it is a question if it is needed to do any extra steps. INFO level message could be suppressed if needed.
Telco voted for suggesting optional attribute ‘custom=true’
1528
Resubmission because the composition from NXpid has been accidentally missed from 1522.
BW: documentation could make it clear. BW volunteered for doing that.
AB: we can vote afterwards.
1408
BW: Beam_progression or Beam_path could be a better choice than beam_device
AR: +1, could be organised as NXbeam_path.
BW: NXbeampath_elements could be organised in NXbeam_path
RO: why not to add previous_element to any devices
MK: we could use NXcomponent for for this purpose
AB: +1
BW: +1
RO: +1
TC: If there is way to handle generic and even complex scenarios, it is not worth having an alternative solution specifically for simple use cases.
SB: This is proposed to enable describing simple use cases in a very simple and intuitive way where no complex structures are involved with long documentation.
AB: Let us reformulate the question and propose a solution with NXcomponent which implements NXbeam_device.
BW: If inheritable NXcomponent supports multiple input and output, there is no need for a special complex description using previous_device/next_device in NXbeam. but the same solution can cover both the simple and the complex use cases.
SB: Yes, at the time of the proposal there was no support for base class inheritance. Indeed, the required solution can be implemented by NXcomponent and inheriting it by all elements. The use of NXcomponent directly also allows creating instances which would not have been able to be modelled in NeXus beforehand and which required NXbeam_device in the past.
AB: Let us drop then this proposal and continue with NXcomponent.