Telco 20240820¶
Date¶
Tuesday, 20th Aug, 15:00 UTC
Connect¶
ZOOM VC link: https://hu-berlin.zoom.us/j/65272091306?pwd=WUxEa0ZtVXp1ZHlsSlVjU2lmclMrQT09
Meeting ID: 652 7209 1306
Passcode: nexus
Agenda¶
Present¶
AB, SB, HB, WdN, RO, BW, PC, PM, RB, TC, ZC, Zdenek + Markus Kuehbach (FAIRmat)
Minutes¶
*) NIAC
14+ on site participants
project page: https://github.com/orgs/nexusformat/projects/5
FAIRmat modifications: issues shall be created for discussion and Project page shall have links to the issues
Project page for non-FAIRmat contributions: https://github.com/orgs/nexusformat/projects/4
*) scaling_factor and offset in NXdata https://github.com/nexusformat/definitions/pull/1343
SB: another suffix in NeXus is _errors, but it is defined as reserved suffix. Is that reserved everywhere or only in NXdata? Shall not we extend the meaning of the proposed suffix _offset to a generic use for any NeXus Field?
AB: Let us make a new issue for these questions
MK: It is not needed to specify in a base class that these new fields are optional
AB: let us discuss the language of optionality in a separate issue
BW: yes, and after a decision, we can make it consistent in all base classes
AB: Note that when not specified, scaling_factor is assumed to be 1 and the offset 0? As there were no objectstion, we shall move to an online vote. The vote will start and have a 2 week cycle as normal.
*) axes attribute in NXdata https://github.com/nexusformat/definitions/pull/1396
AB: simple case and complex case (like multi dimensional case) shall be split. Complex description could be separated out. - WdN: it is better to have a comprehensive description in one location
SB: we should avoid confusing statements and contradictions in different locations in documentation. See another appearance which need to be harmonised: https://manual.nexusformat.org/datarules.html#version-3
BW: detailed reference and simple user guide is mixed here. A comprehensive reference should be separated from simple documentation which shall have links to the detailed description
TC: documentation shall follow the expectation of the reader. so different description for separate target audience can be set up.
RO: It is nice that everything is explained together. Actually only the multi-dimensional case is complex, so it shall be put into a separate section, so simple user can easily skip this part if not needed.
WdN: pathological cases can occur and shall be explained, like _indices=[0,0]
MK: are _indices 0 based or 1 based?
WdN: yes, it is stated that it is 0-based.
RO: documentation shall concentrate on the generic use cases and not all pathological use cases shall be explained in details. Let us discuss it in Grenoble!
Nov Telcos¶
As suggested on the NIAC meeting, we will try to have two, longer meetings in November to be able to cover the issues, we could not complete in Grenoble. Please help to choose the date by responding to the poll by Oct 27th. We are planning to hold the telcos in the regular slot of UTC 15:00. Check your local time to avoid scheduling surprises!