Proposal:

• NXcollectioncolumn
  features: scheme, extractor_voltage, extractor_current, working_distance, node, lens_mode, angular_acceptance, spatial_acceptance, magnification, TRANSFORMATION, APERTURE, FABRICATION
• NXelectron_level: Electronic level probed in X-ray spectroscopy or resonance experiments.
  features: element, level_iupac, level_electron_config
• NXelectronanalyser
  features: description, name, short_name, work_function, voltage_energy_range, energy_resolution, momentum_resolution, angular_resolution, spatial_resolution, [fast/slow]_axes, transmission_function, TRANSFORMATIONS, COLLECTIONCOLUMN, ENERGYDISPERSION, SPINDISPEDSION, DETECTOR, DEFLECTOR, LENS_EM, FABRICATION
• NXenergydispersion
  features: scheme, pass_energy, kinetic_energy, drift_energy, center_energy, energy_interval, diameter, radius, energy_scan_mode, tof_distance, depends_on, APERTURE, DEFLECTOR, LENS_EM, FABRICATION, TRANSFORMATIONS:
• NXspindispersion
  features: type, figure_of_merit, shermann_function, scattering_energy, scattering_angle, target, target_preparation, target_preparation_date, depends_on, TRANSFORMATIONS, DEFLECTOR, LENS_EM
• NXfit, NXpeak, NXfit_background, NXfit_function
  all describing a fit procedure (e.g. a peak fitting in spectroscopy)
• NXprocess_mpes -> extending NXprocess
  features: energy_calibration: (NXcalibration), kN_calibration: (NXcalibration), angularN_calibration (NXcalibration), spatialN_calibration (NXcalibration), delay_calibration: (NXcalibration), polarization_angle_calibration: (NXcalibration), ellipticity_calibration (NXcalibration), energy_referencing: (NXcalibration), REGISTRATION, DISTORTION, CALIBRATION
• NXmpes - base AppDef for Photoemmission Spectroscopy
• NXmpes_arpes - extended arpes
• NXxps - specific for xps

new application definitions:

• NXmpes
• NXmpes_arpes
• NXxps

new base classes to be discussed here:

• NXcircuit
• NXcollectioncolumn
• NXcomponent
• NXdata_mpes
• NXdata_mpes_detector
• NXdeflector
• NXdistortion
• NXelectron_level
• NXelectronanalyser
• NXenergydispersion
• NXfit
• NXfit_background
• NXfit_function
• NXfit_parameter -> replaced by NXparameters
• NXlens_em
• NXmanipulator
• NXpeak
• NXprocess_mpes -> shall be integrated into NXmpes directly
• NXprogram
• NXspindispersion

new base classes discussed elsewhere:

• NXactivity -> FAIRmat 2024: additional base classes in NXinstrument #1419
• NXactuator -> Fairmat 2024: actuators and sensors in NXenvironment #1414
• NXcalibration -> FAIRmat 2024: additional base classes in NXinstrument #1419
  - NXchemical_process -> removed
• NXcoordinate_system -> Fairmat 2024: mention NXcoordinate_system in NXtransformations #1415
• NXcoordinate_system_set -> Fairmat 2024: mention NXcoordinate_system in NXtransformations #1415
• NXfabrication -> Fairmat 2024: actuators and sensors in NXenvironment #1414
• NXhistory -> FAIRmat 2024: additional base classes in NXinstrument #1419
• NXidentifier
• NXphysical_process
• NXpid -> Fairmat 2024: actuators and sensors in NXenvironment #1414
• NXregistration -> Fairmat 2024: add base classes to NXprocess #1420
• NXrotation_set -> Fairmat 2024: several new base classes in NXsample and NXsample_component #1413
• NXresolution -> FAIRmat 2024: additional base classes in NXinstrument #1419
• NXsample_component_set -> Fairmat 2024: several new base classes in NXsample and NXsample_component #1413
• NXserialized
• NXsingle_crystal -> Fairmat 2024: several new base classes in NXsample and NXsample_component #1413
• NXsubstance -> Fairmat 2024: several new base classes in NXsample and NXsample_component #1413
• NXunit_cell -> Fairmat 2024: several new base classes in NXsample and NXsample_component #1413

depends on changes in these applications:

• NXarpes -> FAIRmat 2024: change docs of NXarpes #1406

Discussion on the related PR #1424 during the NIAC Telco:

*) LP presentation:

• the 3 AppDefs in the proposal (NXmpes, NXmpes_arpes, NXxps), their relationship and
• the new specific base classes used inside
• the outcome of meetings with Technology Partners (instrument manufacturers)

Specific discussions:

*) Sample Environment
SB: @pm What is the status with SECOP describing Sample Environment? We try to make our suggestion to be compatible to the suggestions which may come from SECOP in the future.
PM: No update yet. harmonisation between SECOP and NeXus is still under discussion.
LP: described the proposed way for defining sensors and sample environment
PM: An ontology on beamlines and Sample Environments is under preparation for the initiative 'Way For Light' which would also be nice to be aligned with.
LP: Yes, we are already proposing a way of alignment with external definitions (ontology terms, iso standard vocabularies, etc.) as references using specially phrased sentences in the documentation.

*) no formalised enumerations
instead of having an incomplete list of enumerations, the community rather stays at this moment using a convention for naming certain data fields (e.g. in NXdata). These conventions are described in the documentation string.
PC: it is not really machine readable when only doc string contain this list. Suggestion for the future: enumeration could have a flag if the list is open or close.

*) coordinate system
LP: we shall align to and extend the existing ISO standard for XPS. The concept of coordinate systems allow connecting multiple conventions.
PM: Which use cases needs a different coordinate system?
LP: ISO standard requires a different coordinate system
SB: Another example is when NeXus coordinate system being linked to incident beam does not exists because no beam exists in a specific experiment type, like temperature dependent IV measurement.
PM: shall we make this a standard, so all sw shall implement the ability of changing coordinate systems?
HB: NeXus shall allow multiple coordinate systems, as MX is also using it and other fields also require that. It is preferred to have a clearly described way how to do that.
PC: NeXus uses McStas as default, but other coordinate systems can also be used. Important is that the use of NXtransformations shall be consistent throughout the datasets.
SB: This is exactly what the proposal is about: provide a simple solution either on how to use NXtransformations when a base change is required to connect two coordinate systems, or on describing a coordinate system which is used in the definition and data file.
PM: Cannot we use a label for this purpose?
SB: Indeed that is what hapenning: Currently, the NXtransformations chain is followed along @depends_on until it ends with '.'. The proposal is that instead of ending with a '.', it could end with a label pointing to a Coordinate System which either describes a coordinate system on its own, or connetcs it to another coordinate system using NXtransformations.

*) steps needed before a vote
PC: small things need to be cross checked so it is properly prepared for vote, but in general the structure and definitions look good. One thing to check in particular is atom_type requesting a comma separated list.
LP: Yes, sure! The tech partners are eagerly waiting for its being standardised.
PM: extending NXDL to support open enumerations can be a nice way forward. This would provide a solution for the problems we have seen also elsewhere where we add now the option "other".
PM: external references to be put into doc string is a nice good first step, but the ability of properly linking our nxdl vocabulary items to external concepts would be great and needed.
SB: Exactly. Similarly to the Identifier to link a specific data object to external PIDs, we could also link the NeXus vocabulary elements to external concepts (with triplets like in ontologies). This would require the change of the NXDL language, it would be useful.
others: no further suggestions and/or objections

Final conclusions:

• a crosscheck and a fix of potential minor things need to be done in the next 2 weeks before the next meeting
• voting can be initiated in the next meeting in December, so the vote can be finished still before the end of 2024
• further proposals can be discussed and prepared:
  • enumerations could have the option 'open' with having 'open=False' the default. If open=True and a data instance does not match, verification sw shall only drop a WARINING and not an ERROR. With this, we could also deprecate the use of "other" as an enumeration item.
  • an NXDL extension could enable us connecting vocabulary elements to external definitions