DMN15 — Enumerations can only be defined as strings

Item Definitions can share constraints and these constraints are specified as unary tests. This allows definitions such as requiring a positive number ( >0) or restricting a field to a specific value ("high", "medium", "low").

However this requires enumerations to be strings and does not allow enumerations to be managed (sorted for instance). In addition, an enumerated list might be used for a set of Information Items but it must be repeated in Decision Tables when columns are meant to be restricted to the list of values.

DMN should allow for the creation and management of enumerations:

• Name
• Description (optional)
• List of enumerated values (optionally with a sort order)

These enumerations should be considered symbolic constants, not strings

FEEL functions should be created to:
Get the list of of allowed values for a specified enumeration
Check a value against an enumeration to see if it is an allowed value for that enumeration
Check the sort order of some specified values in the context of an enumeration

Decision Tables should be able to reference an enumeration by name in the value list row
Information Items should be able to be linked to an enumeration

Not an issue in practice

It sounds like nobody is really affected by this.
Most users define a string item definition with a list of allowed values.
Developers sometimes expect to feed a Java enumeration into a string resulting in an error. But most users invoke decisions via JSON data, e.g. because of invocation via REST or JSON being the data model of a BPMN engine.