According to Section 10.3.2.14, range expressions are not allowed as iteration context. For example, 1..2 is supported but not (1..2].

I suggest extending the specification to allow such syntactic constructions

According to 13.3.2 References within the DMN XSD, when hrefs refer to DRG elements in another file the hrefs are defined as below:

DMN elements of type DMNElementReference support referencing by ID, across files, by utilizing an href attribute whose value must be a valid URI reference [RFC 3986] where the path components may be absolute or relative, the reference has no query component, and the fragment consists of the value of the id of the referenced DMN element.

The semantics of the part of the URI before the fragment that contains the ID (e.g. #prebureauriskDec01) is not very clear. Is the location of the DMN file or the namespace of the model in the DMN file?

The implicit conversions are defined in the FEEL chapter, in section 10.3.2.9.4 Type conversions.

The constraints for the DMN types are defined in section 7.3.3 ItemDefinition metamodel.

It is not very clear when these conversions or constraints are applied / checked:

• Are they applied only when the values are bound to a variable (e.g. expression is a direct child of a DMN element that contains also an Information Item) or every time an expression is evaluated?
• Are they applied only when FEEL expressions / textual are evaluated, or for boxed expressions as well? The boxed expressions are defined outside of the FEEL chapter.

I am leaning towards checking the above only when a binding takes place (a value is bound to a variable of a known type). For example, after the evaluation of the body of Decisions, Invocable, Context Entry, and Binding.

The main reason is to keep things simple and be consistent with common patterns in other PLs / DSLs.

DMN does not support semantic domains for enumerations (a data type consisting of a set of named values). Currently, modeling such data types can be done in an imprecise manner using existing features (e.g. string type with allowed values).

Having support for such types will increase the precision of the model validation.

DMN 1.6 supports the semantic domain for ranges (see 10.3.2.7 Ranges and Figure 10-26: FEEL lattice type).

However, the XML schema does nu support the definition of such types.

I suggest adding an extra attribute, called isRange, similar to the one used for lists: https://github.com/omg-dmn-taskforce/omg-dmn-spec/blob/master/xsd/DMN16.xsd#L245

Currently, the DMN standard defines some parts of its semantics by using XPath 2.0 https://www.w3.org/TR/xpath20/
The latest version of the standard is XPath 3.1.
I suggest upgrading to XPath 3.1. It is backwards compatible and provides more features.

Currently, the standard supports two semantic domains for durations: years and months duration and days and time duration. However, there is one single conversion function from string that covers both semantic domains (see Table 73: Semantics of conversion functions).
For consistency with the other semantic domains and make model validation more accurate I suggest adding two new conversion functions and deprecate the duration function. This will make the models more precise.