Clarify if a field in a specified NXdata is a AXISNAME or DATA

[lukaspie]

NXdata contains two renameable fields, AXISNAME and DATA, that are both of type NX_NUMBER. This naturally presents a problem in that any instance of any of the two must be properly allocated to either of the two concepts.

On the data level, this is not a problem since this can be handled by properly assigning the @signal and @axes attributes and thus it is immediately clear which data field belongs to which concept (see here).

The problem is however not solved on the conceptual, data modelling level, i.e., when writing base classes and application definitions.
Consider the following situation (borrowed directly from contributed_definitions/NXiv_temp):

<definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="application" name="NXiv_temp" extends="NXsensor_scan" type="group" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
    <doc>
         Application definition for temperature-dependent IV curve measurements.
    </doc>
    <group type="NXentry">
        <group type="NXdata">
            <doc>
                 This NXdata contains multiple fields. Temperature and voltage are supposed to specialize `AXISNAME`, whereas 
                 `current` is specializing `DATA`.
            </doc>
            <field name="temperature" type="NX_NUMBER"/>  
            <field name="voltage" type="NX_NUMBER"/>
            <field name="current" type="NX_NUMBER">
            </field>
        </group>
    </group>
</definition>

Here, we as humans know which field in /NXiv_temp/NXentry/NXdata is associated with which field in NXdata. However, there is no way for any interpreation tool to automatically understand this. Note that currently the way that each conceptual field is assigned to AXISNAME or DATA is by doing namefitting, i.e., by comparing whether the name of the field more closely resembles "axisname" or "data". For this particular example, this would lead to an assignment (on the conceptual level) of /NXiv_temp/NXentry/NXdata/temperature to DATA, i.e. temperature would be specializing NXdata/DATA. See the pop-up link on the bottom of this screenshot, here we actually visualize which concept temperature is inheriting from.

During file writing with actual data, we will assign temperature to AXISNAME by adding it to the axes. However, any proper data management system will complain here because what we define on the conceptual level will not be the same as what the data provider will injest.

So what I think is needed is a way to already define on the data modelling level which field is an axis and which one is a data field. One possible solution would be to add an extra attribute extends to fieldType and attributeType where one can explicitly say which field in the inheritance shall be extended.

[lukaspie]

Another case to consider:
NXsensor_scan/ENTRY/INSTRUMENT/ENVIRONMENT/SENSOR is a specialized concept that overwrites NXenvironment/SENSOR which is an NXsensor. According to current naming convention, any NXsensor in the given location in NXsensor_scan shall be an instance of the specialized concept.
But, what happens if someone would like to put just an NXenvironment/SENSOR or a generic NXsensor here? Such a sensor is also inherited as optional and NeXus could even interpret it, but it is now forbidden.
The introduction of extends=NXenvironment/SENSOR could enable its use.

This is however also a conceptual question of how "specializing/extending" actually means in NeXus. Does it mean that the concept is

• overwritten, i.e., once you have specialized a concept, you actually can't use the inherited, non-specialized concept anymore. In the case above, that would mean that in any implementation of the NXsensor_scan application definition, you can only add sensors that are compliant with NXsensor_scan/ENTRY/INSTRUMENT/ENVIRONMENT/SENSOR, but not any generic NXsensor.

or

• added to the existing concepts, i.e., when you specialize a concept, you now have both the new, specialized concept and the non-specialized concept in your definition. In the case above, that would mean that in any implementation of the NXsensor_scan application definition, you can also add sensors that are compliant with a generic NXsensor or NXenvironment/SENSOR, but not necessarily with NXsensor_scan/ENTRY/INSTRUMENT/ENVIRONMENT/SENSOR.

[lukaspie]

Continuing on the previous item, consider this:

Currently, if you have NXsensor_scan/ENTRY/INSTRUMENT/ENVIRONMENT/SENSOR_special, then these would have to comply with that (assuming overwritten is correct in the previous post):

• NXiv_temp/ENTRY/INSTRUMENT/ENVIRONMENT/SENSOR_special and
• NXiv_temp/ENTRY/INSTRUMENT/ENVIRONMENT/my_sensor_special .

However,

• NXiv_temp/ENTRY/INSTRUMENT/ENVIRONMENT/temperature_controller and
• NXiv_temp/ENTRY/INSTRUMENT/ENVIRONMENT/SENSOR

would not inherit SENSOR_special, but only NXenvironment/SENSOR. So far, so good.

On the other hand, if we have NXsensor_scan/ENTRY/INSTRUMENT/ENVIRONMENT/SENSOR, then all sensors in NXiv_temp/ENTRY/INSTRUMENT/ENVIRONMENT (i.e. sensors described above) inherit from that and therefore must be compliant with it.

With the extend keyword, we could define exceptions for the second case. I.e., if we add add a sensor NXiv_temp/ENTRY/INSTRUMENT/ENVIRONMENT/SENSOR_special, we could say that it doesn't have to inherit, but rather just from NXenvironment/SENSOR by saying

<definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="application" name="NXiv_temp" extends="NXsensor_scan" type="group" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
	<group type="NXentry">
		<group type="NXinstrument">
			<group type="NXenvironment">
				<group name="voltage_controller" type="NXsensor" extends="/NXenvironment/NXsensor"/>
			</group>
		</group>
	</group>
</definition>

This is of course a much bigger change that the AXISNAME/DATA discussion above because then the extends keyword could (but not should) be used everywhere, i.e., in groups, fields, and attributes.