extends attribute to fields to 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"/>
        </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 interpretation 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.

As a fix, we add an extra attribute extends to fieldType where one can explicitly say which field in the inheritance shall be extended. The language is specifically chosen to indicate that this is only possible for the use case outlined above and not for any arbitrary case (to prevent people from just extending any arbitrary field defined somewhere else).