Telco 20251020

Date

Monday, 20th Oct, 15:00 UTC

Connect

Agenda

  • PRs for the Release

Present

SB, WdN, FdA, PM, PC, RO, FS, BW, ZM, AB, CZ, FA - MarkusK, LukasP (FAIRmat)

Minutes

  • PM: use of PIDs in Nexus as motivated by the use of PANET IDs (as PIDs refering to experiment techniques)

    • MK: could/should be included in the NeXus documentation as a best practice, but the use of identifiers can be extended at a later stage also to Fields and Attributes and not only to Groups as supported now.

    • RO: it is always important to produce examples which show how to use in practice the different elements in NeXus

    • MK: attribute of attributes is not supported in HDF5 which causes a practical problem when trying to extend identifiers to Attributes.

    • RO: this limitation can be overcome by the use of prefixes in Attribute names.

  • WdN: NXxas (https://github.com/nexusformat/definitions/pull/1352#issuecomment-3422349124 ) has a tricky question: the meaning of certain fields (and their being required) depend on the actual mode in use.

    • SB: maybe one can use ChoiceType

    • BW: it would not support situations when multiple modes are used simultanously. Hard and Soft Xray XAS can have different needs, so it is not a problem to have even multiple application definitions which fulfills the need of respective communities.
Alternatively, different detectors could be kept optional and inside respective detector definitions for the different modes, can one specify what is required.

    • RO: ChoiceType could be revisited to make it more useful.

  • PRs for new release

    • PR #1577 on Azimuthal integration:

      • ZM: current status is robust, but future extensions shall still be possible.

      • RO: another issue: nameType=”any” (by using ALL CAPS) is dangerous for NXprocess groups, please give a specific name.

      • ZM: accepted that it should be lower case. Let us discuss with the community again.

    • PR #1427 on updating on contributed definitions to make them consistent with the latest and accepted state of base classes.

      • AB: as it is contributed, let us just go for these fixes. It is too much to check them all individually.

      • MK: let us check again and then we can merge it.

      • AB: we can already accept it now.

      • Telco agrees.

    • PR #1412 on extending NXentry

      • AB: did not pass the vote

      • LK: let us skip it for now

      • MK: +1

    • PR #1587 on wavelength shifter: vote accepted

      • AB: let us merge it

    • PR #1560 on NXparameter documentation

      • AB: GitHub conflicts are still blocking

      • LP: it would be nice to harmonize with NXfit_function. A corresponding modification can be adde to this PR.

      • MK: LMFIT specific fields could be put into a specialized NXparameters specialized for LMFIT.

      • AB: we can bring it in only if we have universal agreement.

      • RO: NXparameter was and is in use even before NXfit_function existed.

      • WdN: this is used a lot, but looking it one can assume that it is only for fitting

      • AB: what is the expected behavior of a NeXus validator if derived class is provided when a superclass is expected? In NeXus we only used inheritance for subclassing, but we have not fully defined the expected behavior of validotors. This should be done in the future.

      • ZM: refineable and static parameters are not separated here at all which can cause confusions.

      • AB: with these confusions, let us bring this in to the follow up release and not to the coming one at the end of October.

    • PR #1428 on grouping definitions in documentation

      • SB: is it possible to list the definitions for each groups, just as a simple list below.

      • AB: it is nice as is. As it is only documentation, it does not need a vote. Further improvements can be made subsequently. After suggestion added, we can merge it.

    • PR #1582 on spell checking

      • AB: approved by PC, can be merged in

    • PR #1561 on NXgoniometer

      • RO: suggestions are taken, so NXtransofmration and reference to it has also been added.

      • AB: It looks nor OK

      • PC: +1

      • RO: doc generation is currently failing.

    • Release:

      • AB: either we wait until Nov 3, or postpone those still needs vote?

      • RO: let us start a vote and if enough votes come on time, we could keep for the next release

      • AB: this is against the constitution because people can also change their vote in the 2 weeks period.

      • PC: we can do the release either next week, or later the week after.

      • LP: it should be acceptable

      • MK: +1

      • AB: RO/ZM shall make the PRs ready for vote, so vote can start ASAP.

Nov Telco

Please help to choose the date by responding to the poll by Nov 7th.

We are planning to hold the telco in the regular slot of UTC 15:00. Check your local time to avoid scheduling surprises!