Currently, the grammar allows to use iteration context only in case of the for loop. However, quantified expressions (some, every) are very similar in their nature, so there is no good reason for inconcistency there. This leads to overly verbose expressions, e.g.

some i in (for j in 1..10 return j) satisfies i > 5

. One cannot simply write

some i in 1..10 satisfies i > 5

.

Currently, the variables associated with InputDatas have both a name and a type reference. Adding an initializer/default value would have the following benefits:

• simplify the logic required when checking the values provided by users
• consistent with existing default values for Output Clauses in Decision Tables
• align with current FEEL functions with default values
• align with current approach in modern PLs & DSLs (e.g. Python)

FEEL already has a union function and an intersection function would be very useful.

The union function does not specify the order of the resulting list.

To completement the existing insert before() list function, an insert after equivalent FEEL function should be added

Missing a function that trims whitespaces from the begining and end of strings.

The DMN specification mentions the following types / semantic domains:

• duration, the output type of the duration() function (Table 73: Semantics of conversion functions)
• comparable, the input for the range functions (10.3.4.7 Range Functions)
• context, the input for context functions (10.3.4.10 Context function)

These types are missing in Figure 10-26: FEEL lattice type.

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?

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 and users requested its 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). This makes static analysis of model difficult or impossible (in case of dynamic parameters). In B-FEEL, duration() might return the wrong type because it has to pick one of the two.

Parsing JSON strings in FEEL is very cumbersome and limited but real-world data sometimes contain JSON strings

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.

The DMN specification contains several built-in functions with abstract return types. For example, the semantics for

duration(input) + time("12:00:00")

cannot be checked before the execution, as only days and time durations are allowed in this context.

The same is true for expressions such as

context(input).name
context put({x:1}, key, value).y

as the context() and context put() functions return an unknown context.

Adding support for explicit conversions will address these issues. For example,

(duration(input) as days and time duration) + time("12:00:00")
(context(input) as context<name: string, age: number>).name

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

However, the Meta Model & XML schema do not support the definition of such types in an Item Definition.

When describing the logic of decisions we have to deal with possible null values. For decision tables there is the solution to mention an default value for the output column. But in literal expressions i have to use other solutions. I think it would be great to have an built-in function for that, like a shorthand notation of "if ExpressionToBeChecked = null then defaultValue else ExpressionToBeChecked".
e.g. default(ExpressionToBeChecked, defaultValue). That would shorten a lot of logic, that is used to work around null values.
With that approach it is possible not just to work around Input Data with null values but every other null value that can occure when dealing with explicit logic.

In the description of FEEL there is the definition of the three built-in functions sum(), mean(), min() and max() in Table 76 (chapter 10.3.4.4.). All table entries (for min()/max() and sum(), mean()) say "N>0" in the end to clarify, that the numbers must be positive. Therefore an array (or list of parameters) containing at least one null value is resulting in null.

With B-FEEL that behaviour is adressed but only for sum() and mean(). The second sentence and table in Chapter 11.3 say, that these functions ignore non-numeric parameters:
FEEL: sum([1, null, 3]) = null
B-FEEL: sum([1, null, 3]) = 4
B-FEEL: mean([1, “a”, 3]) = 2

The two functions min()/max() are not mentioned in the 2nd sentence of 11.3. So the first sentence is used for min()/max() which leads to this results:
FEEL: min([1, null, 3]) = null
B-FEEL: min([1, null, 3]) = 0
In that case we have a different result with the same array (e.g. [1, null, 3] ), although the original definition in table 56 followed the same principels.

In conclusion i think that would lead to confusion when using these functions.
A possible soution would be adding min() and max() to the ignore table in chapter 11.3 in the same way like sum() and mean().

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

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.