Telco 20240415

Date

Monday, 15th April, 15:00 UTC

Connect

Agenda

  • issues

Present

SB, AB, PM, WdN, PC, BW, LG, PJ,, HG, RO, BB, CZ, FS, HB + FAIRmat: Markus Kuehbach, Florian Dobener

Minutes

  • NIAC Conf: registration is needed for on site attendance, zoom attendance will be offered https://indico.esrf.fr/event/114/
    https://indico.esrf.fr/event/114/page/27-satellite-meetings

  • Calls and External fundings

  • SB: NeXus Ontology v2

    • HG: it would be great if ESRF could test it

    • WdN: Yes, we shall figure out how to integrate with other ontologies

  • Base Class Inheritance

    • SB: base class inheritance would be appreciated using extends= exactly on the same way as for AppDefs. It would help avoiding copy-pasting. 2 examples are shown: NXem_ebsd (specialising NXem_method) and NXdata_mpes (specialising NXdata). Note that although HTML generation accepts is already, tools like, but cnxvalidate shall probably be updated to support it as registered in a previous issue.

    • PJ: Note that it is not a real OO inheritance with all common concepts, but rather like java interfaces;

    • BW: software tools should also be able to follow the inheritance of the concepts. Is it supported?

    • SB: yes, a python code used for the HTML generation is already implementing it and produces the first reference linking

    • PM: 3D geometry description is another example to support this move and to help avoiding copy-pasting taht happens around NXtransformations. Note that composition is even more powerful than inheritance. How could we combine it? What about multiple inheritance?

    • SB: during composition, we indeed already also “inherit” (auto-copy the interface) and also specialise/extend in one go. Multiple inheritance of interfaces could be great for AppDefs to be used as a comma separated string of AppDef names in NXentry/definition to tell that the given ENTRY implements all those interfaces.

    • PJ (chat): Paul, your observation is correct and it was done with intent, to avoid “being” object designed. It’s high time to fix that. Part of that design included consideration of multiple inheritance, and its consequences. NIAC was not ready to consider how to handle that in NXDL.

    • RO (chat): https://www.nexusformat.org/Objects_or_Interfaces.html

    • RO: In 2011 there was an evaluation of going for OO (MK’s presentation in OO problems in NeXus from 2007: https://anl.box.com/s/afnrbx4yujjctnciit4bk5olr64usq6n). Note that the sw implementation does use OO, e.g. for NXdata

    • PC (chat): A previous discussion of the NIAC: https://www.nexusformat.org/NIAC2018Minutes.html

    • PJ (chat): extends - https://github.com/nexusformat/definitions/blob/main/nxdl.xsd#L237 The extends attribute allows this definition to subclass from another NXDL, otherwise extends="NXobject" should be used.

    • AB: anybody against this?

    • HB: objection against multiple inheritance as it is in C++. This is very problematic! Java style single inheritance would work fine, and also implementations of multiple interfaces as in Java.

    • AB: yes, problems are with multiple inheritances also in python. SB, let us set up a github issue to carry on it!

  • XAS Working Group

    • WdN: from XAS working group (https://indico.esrf.fr/event/114/page/27-satellite-meetings) reusable list of enumeration items could be useful

    • MK: EM, APM, XPS also having similar problems, solution may be a corresponding base class, like NXabberation

    • AB: new base class for these could be an overkill, but a new functionality in NXDL or an xml feature which would support that in NXDL could also be a solution

    • HG: what about a reference to external ontology/vocabulary

    • PM: it would be good to have a link between enumerations we use in NeXus at different places

  • Promoting Contributed Definitions

    • AB: list of contributed definitions to be promoted in Sept should be set.

    • 3 member committee to do it for May Telco: SB, BW, PC

May Telco

Please help to choose the date by responding to the poll by May 3. We are planning to hold the telco in the regular slot of UTC 15:00. Check your local time to avoid scheduling surprises!