add target attribute to NXobject using new field super-type

[lukaspie]

Follow up to #1410.

This is an initial draft for how attributes that are always allowed could be added. The idea is that a new generic field (with the new super-dtype NX_DTYPE) is added to NXobject that contains these default attributes.

For now, only the attribute @target was added (see comparable discussion in #1410).

In general, I believe the issue is a bit bigger. The nxdl.xsd file defines multiple <xs:attribute> for the fieldType (like units, long_name, signal). However, some of these are used as XML attributes (i.e., writing something like

<field name="my_field" type="NX_NUMBER" units=NX_ANY"/>

Then again, some other of these attributes are (to my understanding) to be used like this

<field name="my_field">
    <attribute name="long_name"/> # same for axes, signal, primary, etc.
</field>

This may be due to me misunderstanding XML design, but I think with the definitions in the nxdl.xd file only the first use case (as XML attributes) is defined, whereas the second use case is not. To illustrate, this passes the schema validation:

<field name="my_field" long_name="a_longer_name" primary=0 signal=1</field>

I think this is not intended and rather these attributes should be defined somewhere else as attributes that each field can have. The mechanism given in this PR using a generic field in NXobject would be one way to define these.

[prjemian]

As described in a previous comment, the NeXus NXDL is a a set of XML specifications, each of which adhere to an XML Schema (nxdl.xsd). For certain attributes such as target, it is the XML Schema that defines when and where the attribute appears. In the case of target, the schema defines it as a required attribute of a link. Your proposal is to generalize the target attribute.

If NeXus is to continue use of nxdl.xsd, then refactor target's definition into:

definitions/nxdl.xsd

Line 607 in 2aede96

<xs:complexType name="basicComponent">

[prjemian]

FWIW: I've been adding the target attribute to fields and groups in NeXus/HDF5 files written from the apstools NXWriter code. These additions are in anticipation of their use as a link.

While the NeXus standard defines target only for links, it does not preclude similar use throughout. That's the basis for my use as shown.

[lukaspie]

If NeXus is to continue use of nxdl.xsd, then refactor target's definition into:

definitions/nxdl.xsd

Line 607 in 2aede96

<xs:complexType name="basicComponent">

Am I missing something on how XSD works?

To my understanding, with <xs:attribute, you define the attributes that you can use within the XML element of a given complexType. So, if I were to bring <xs:attribute name="target" use="required" type="nx:validTargetName"> to <xs:complexType name="basicComponent"> (as you suggest), I could do

<field name="my_field" target="some_other_field/>

in an nxdl.xml file afterwards (this is what's described e.g. here: https://www.w3schools.com/xml/schema_simple_attributes.asp).

However, with that you don't define

<field name="my_field">
    <attribute name="target"/> # this is of complexType attributeType
</field>

everywhere. You still need to define that attribute within some NXDL file to state that any field can have a @target attribute.

Am I missing something about how XSD works in this case? Or is the second case just convention (from the documentation) and not explicitly defined through the XSD file. If so, why not add it explicitly to NXobject?

[lukaspie]

This is generally confusing to me, see how the xs:attributes of fieldType are used within the NXDL files, e.g. long_name vs. type. One is used as a NeXus attribute (i.e., of type attributeType), whereas the other is used as an XML attribute of fieldType.

[prjemian]

NXobject has been in the NXDL suite for a long time. During most of that time, it has been a bare-bones definition, inheriting any and all of its contents, rules, etc from the XSD Schema (nxdl.xsd). The NXDL is not an object-oriented standard, yet NXobject was added so that all (other) NXDL definitions would have a common starting point (its addition pre-dates the NeXus GitHub repo). Still, again, the standard is based on the XML Schema. Attributes (and other content) defined by the XML Schema are allowed and are not necessary to write into each and every NXDL file. The target attribute is a good example.

Recently, some have found it interesting to add to the NXobject definition.

In my opinion, these additions contribute towards your confusion. Again, the standard is based on the XML Schema. Also, I agree that XML Schema is not particularly easy to read or write.

To develop nxdl.xsd and the NXDL files, we (the NeXus developer team) used editors (such as oXygen XML) that are aware of the rules for XML Schema and for applying them to the XML files that use them.

[lukaspie]

Recently, some have found it interesting to add to the NXobject definition.

In my opinion, these additions contribute towards your confusion. Again, the standard is based on the XML Schema. Also, I agree that XML Schema is not particularly easy to read or write.

I don't think that necessarily is the thing that confuses me. These additions (one of which came from me, by the way) were made exactly for the same reason why I made this PR: to define groups/fields/attributes that can be used in every group (as every group inherits from NXobject). This also effectively blocks part of the namespace, as e.g. any field that ends on _set should follow the definition in NXobject. So far so good.

What I wanted to achieve through this PR is similar: to define what it means to have the @target attribute in any field or group.

NXobject has been in the NXDL suite for a long time. During most of that time, it has been a bare-bones definition, inheriting any and all of its contents, rules, etc from the XSD Schema (nxdl.xsd). The NXDL is not an object-oriented standard, yet NXobject was added so that all (other) NXDL definitions would have a common starting point (its addition pre-dates the NeXus GitHub repo). Still, again, the standard is based on the XML Schema. Attributes (and other content) defined by the XML Schema are allowed and are not necessary to write into each and every NXDL file. The target attribute is a good example.

My confusion is exactly in the last two sentences here. I just don't understand how that can be achieved through the XML Schema (i.e., the nxdl.xsd). Again, if I just move the definition of <xs:attribute name="target" ... to basicComponent, from my understanding of XML that means you can use "target" as an XML attribute for fields/group, but that doesn't mean that it is defined as a NeXus attribute (i.e., of type attributeType), see my description above.

What would help me greatly is how to understand why by adding it to the XSD, the latter case is achieved and why I don't need to define in the NXDL files anymore (which is what you are saying, if I understand you correctly). Could you clarify: does the XSD actually define the NeXus @target attribute (i.e., )? Or is this something that’s only implied/assumed but not formally included in the schema?