Allow for open enumerations

[lukaspie]

The idea of this PR is to allow for open enumerations, i.e., to allow values not explicitly given in the enumeration list. An example is the type field in NXsource (https://manual.nexusformat.org/classes/base_classes/NXsource.html#nxsource-type-field) which is too restrictive for some experiments.

Note that by default enumerations will be closed as for some fields/attributes, the values given in the enumerations really are the only sensible ones (a prominent example being NXentry/definition field in most application definitions.

• Implement in nxdl.xsd
• Adapt sphinx to render it nicely. This is an example rendering of NXsource/type which is now an open enum:
  

Note that for some reason, the changes to the nxdl.xsd did not show up in my local build (would be in nxdl_desc.html#enumerationtype), so maybe this implementation is not yet correct. I could appreciate someone with more knowdledge of the NXDl language to chime in. This is also why this is currently still a draft.
EDIT: The changes to the nxdl.xsd are now also showing up in the HTML description of the NXDL:

Closes #1520

[phyy-nx]

There are a few places we want to consider open enumerations. #1486 adds identifierNAME and #1407 added changes to NXsource that would merit an open enumeration. @lukaspie you have made the latter change, but the former could be part of this PR as well. Consider rebasing this PR on the #1486 branch? Unless there was a third location we were considering?

Also in both locations, I think just adding open="true" is not enough. Consider adding language such as this: "Users are encouraged to use options from this list. However if your (identifier type or source type) is not listed, users can put their own values here. In that case, we encourage users to contact the NeXus developers to see if your (identifier type or source type) can be added to this list." That's a lot of words, I realize, but maybe there's a more succinct way to say this?

[lukaspie]

There are a few places we want to consider open enumerations. #1486 adds identifierNAME and #1407 added changes to NXsource that would merit an open enumeration. @lukaspie you have made the latter change, but the former could be part of this PR as well. Consider rebasing this PR on the #1486 branch? Unless there was a third location we were considering?

I brought in the changes from #1486 now and already make the enum for the identifier type open (with the possibility of reverting if #1486 yields a different outcome what was is proposed there)

Afterwards, I went digging a bit for possible other uses of open enumerations within existing base classes / application definitions, using this search in the GitHub GUI

repo:nexusformat/definitions enumeration (path:/^applications\// OR path:/^base_classes\//)

resulting in these search results.

Here is a list of concepts where it might make sense to reconsider if the provided values are complete. I also added a bit of reasoning why this might be a good place for an open enumeration:

#	Concept (with link)	Reasoning
1	NXsensor/measurement	There are many more sensor measurements that are possible (e.g. current, mechanical properties, etc.) and I don't see a way of making this list complete.
2	NXsource/mode	It is already stated with a comment there that other sources could add to this list.
3	NXsource/target_material	It is unclear to me if these are really all the possible target materials. This one is probably not urgent.

I think we could do 1 and 2 together with this PR and then subsequent changes to make other enumerations open in separate PRs. What do you think?

Also in both locations, I think just adding open="true" is not enough. Consider adding language such as this: "Users are encouraged to use options from this list. However if your (identifier type or source type) is not listed, users can put their own values here. In that case, we encourage users to contact the NeXus developers to see if your (identifier type or source type) can be added to this list." That's a lot of words, I realize, but maybe there's a more succinct way to say this?

I agree that would be helpful. Do you want to do this in the XML definitions themselves or just in the HTML rendering? Currently, I only modified the HTML, so if you look at the XML, you would only see the attribute open="true". We can add it in the XML as well, but then it must be done in every open enumeration separately. I would be open to both possibilities.