Can we have a standard rule in NeXus to validate presence of one item from a list of possibles?

[prjemian]

You raise a good point:

Can we have a standard rule in NeXus to validate such content?

_Originally posted by @prjemian in #1064

[benajamin]

I think we need to narrow down what we want. We already have the choiceType element in NXDL that allows validating the presence of a base class from a set

definitions/nxdl.xsd

Lines 359 to 390 in 1af5f99

	<xs:complexType name="choiceType">
	<xs:annotation>
	<xs:documentation>
	A ``choice`` element is used when a named group might take one
	of several possible NeXus base classes. Logically, it must
	have at least two group children.
	</xs:documentation>
	</xs:annotation>
	<xs:sequence>
	<xs:element name="group" type="nx:groupType" minOccurs="2" maxOccurs="unbounded">
	<xs:annotation>
	<xs:documentation>
	NeXus base class that could be used here.
	The group will take the ``@name`` attribute
	defined by the parent ``choice`` element
	so do not specify the ``@name`` attribute of
	the group here.
	</xs:documentation>
	<!-- TODO: How to enforce the name rule in the schema? -->
	</xs:annotation>
	</xs:element>
	</xs:sequence>
	<xs:attribute name="name" use="required" type="nx:validItemName">
	<xs:annotation>
	<xs:documentation>
	The name to be applied to the selected child group.
	None of the child groups should define a
	``@name`` attribute.
	</xs:documentation>
	</xs:annotation>
	</xs:attribute>
	</xs:complexType>

This is used twice in NXdetector: (and nowhere else)

definitions/base_classes/NXdetector.nxdl.xml

Lines 861 to 874 in 2bb99a4

	<choice name="pixel_shape">
	<group type="NXoff_geometry">
	<doc>
	Shape description of each pixel. Use only if all pixels in the detector
	are of uniform shape.
	</doc>
	</group>
	<group type="NXcylindrical_geometry">
	<doc>
	Shape description of each pixel. Use only if all pixels in the detector
	are of uniform shape and require being described by cylinders.
	</doc>
	</group>
	</choice>

definitions/base_classes/NXdetector.nxdl.xml

Lines 875 to 888 in 2bb99a4

	<choice name="detector_shape">
	<group type="NXoff_geometry">
	<doc>
	Shape description of the whole detector. Use only if pixels in the
	detector are not of uniform shape.
	</doc>
	</group>
	<group type="NXcylindrical_geometry">
	<doc>
	Shape description of the whole detector. Use only if pixels in the
	detector are not of uniform shape and require being described by cylinders.
	</doc>
	</group>
	</choice>

The full set of choice rules that we may want to have are:

1. a choice of a single base class from a set (we already have this)
2. a choice of a single field from a set
3. a choice of a single object from a set of fields and base classes

Creating these NXDL rules should not be too hard, but testing that they work as expected feels like a lot of work - do we want to include this in the current milestone? I suppose that if we only create new NXDL rules that are not actually used yet, then we shouldn't be able to break anything and it will give us a basis for testing various usages.

[benajamin]

@prjemian My understanding is that we use XML to define the NXDL language and then we use NXDL to write the base classes and application definitions. Is that exactly true? Could we also use some XML together with the NXDL to write a base class or application definition?

[prjemian]

@prjemian My understanding is that we use XML to define the NXDL language and then we use NXDL to write the base classes and application definitions. Is that exactly true?

Yes

Could we also use some XML together with the NXDL to write a base class or application definition?

Not at this time. It would require some changes in how we define NXDL in the schema. It is likely this would increase the difficulty to validate NXDL files.

[prjemian]

@benajamin Are you planning to work on this issue in the next week?

[prjemian]

We'll move this to the next milestone.