Implement open enumerations

[lukaspie]

nexusformat/definitions#1521 introduced open enumerations, i.e., to allow values not explicitly given in the enumeration list. For this, a new attribute open was introduced for the enumerationTYPE, which defaults to "False". If open enumeration is used, this XML attribute should be "True".

In order to support this new feature, I suggest the following notation:

   <field name="mode">
   	<doc>source operating mode</doc>
   	<enumeration open="true">
   		<item value="Single Bunch"><doc>for storage rings</doc></item>
   		<item value="Multi Bunch"><doc>for storage rings</doc></item>
   	</enumeration>
   </field>

shall be expressed in nyaml as

  mode:
    doc: |
      source operating mode
    enumeration:
      \@open: True
      Single Bunch:
        doc: |
          for storage rings
      Multi Bunch:
        doc: |
          for storage rings

If \@open is not set, we default to <enumeration"> (i.e. open="False").

Using the \@ notation, we avoid situations where open is a valid enumeration value.

Opinions @sanbrock @mkuehbach @RubelMozumder ?

[lukaspie]

Our current notation like this

type:
    doc: |
      type of radiation source (pick one from the enumerated list and spell exactly)
    enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, ...]

will likely not be able to handle this.

Another option we could go for is to add another special keyword, like

type:
    doc: |
      type of radiation source (pick one from the enumerated list and spell exactly)
    enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, ...]
    open_enumeration: True

[mkuehbach]

enumeration:
  open: True

if combined with #52 will enable to process of an enumeration nest rigorously, i.e. convenience open: False the default

[lukaspie]

enumeration:
  open: True

if combined with #52 will enable to process of an enumeration nest rigorously, i.e. convenience open: False the default

This exactly won't work because currently we have enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, ...], you cannot have an additional key in YAML there.

[mkuehbach]

enumeration: [enum values]  # if closed
enumeration:  # if open
  value: [enum values]
  open: boolean

Consistent with how it will be with dimensionsType

[lukaspie]

enumeration: [enum values]  # if closed
enumeration:  # if open
  value: [enum values]
  open: boolean

Consistent with how it will be with dimensionsType

Hm, that makes the logic quite a bit more involved. How would that work for the first use case? Like so?

enumeration:
  open: True
  Single Bunch:
    doc: |
      for storage rings
  Multi Bunch:
    doc: |
      for storage rings

Then we need to distinguish enums

• that are just a list
• that are a dict with the open key and the value key (for this, we expect a list) (your case)
• that are a dict with the value keyword and several other keys that are the actual enum items (my case in this comment)

Note that this means that neither open nor value can be used as enumeration items anymore. Maybe I would actually go for items instead of values.