Example diagrams are in PNG format with poor resolution.

Errors found on review:

1. Section 8.3.1 (clean PDF p79)
Defect: Two paras before Table 32, "aggregration" should read "aggregation"

2. Table 76: Semantics of list functions (clean PDF p150)
Defect: The example for the new `intersection` function has unbalanced quotation marks; The string `"a` lacks a closing quotation mark in both lists, making this syntactically invalid FEEL.

3. Table 77: Semantics of numeric functions (clean PDF p152)
Defect: In Modulo() row, "dividen d" should read "dividend"

Spec, Metamodel and XSD are inconsistent for OutputClause.defaultOutputEntry:

• Table 34 says it can be an optional Expression[0..1]
• the MM, XSD and text above Table 34 schema restrict it to LiteralExpression

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

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.

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().

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.

The FEEL functions random() and uuid() are needed in practice and have already been implemented as extension by many vendors. They should therefore be standardized.

Their non-deterministic nature should be commented on in the same way as with time() and now()

There are three associations in the metamodel for which the properties defined by one end do not appear in the specification. It results in 3 properties for AuthorityRequirement that are not included in Table 22.

For the association BKM2authorityRequirement, the role B end defines bkm: BusinessKnowledgeModel [0..1]
For the association Decision2authorityRequirement, the role B end defines decision: Decision [0..1]
For the association KnowledgeSource2authorityRequirement, the role B end defines knowledgeSource: Knowledge Source [0..1]

If these properties are intentionally excluded from the specification, then I suggest the following changes to the associations:
Name (Role B): remove name
Multiplicity (Role B): set to unspecified
Navigable (Role B): set to false (make it a directional association)

If these properties should be in the spec, I recommend adding them to the table and also making sure the name of the ends are visible in the diagrams for Decision (source for Figure 6-13), BusinessKnowledgeModel (source for Figure 6-15), and KnowledgeSource (source for Figure 6-18).

In fact, as a general comment on all the metamodel diagrams, the role end for the source of a directed relationship (navigable in one direction) should not be named or have any multiplicity, since the target end doesn't "know about" the source end in this kind of relationship. On the other hand, if the association is bidirectional, both ends know about each other, so both ends should be named and the names should be visible on all diagrams in which the association appears. Performing this update will make the alignment between the figures and the text in the spec much better.

The Decision class diagram should show the property informationRequirement on the end of the association between Decision and Information requirement.

The association InformationRequirement2requiredDecision defines two properties based on its role ends:
Name (Role B): requiredDecision: Decision [0..1]
Name (Role A): requiresInformation: InformationRequirement [0..*]

The requiresInformation end of the association does not appear in the DMN specification, although the requiredDecision end does. If this is intentional, recommend updating the following aspects of the association (was -> is):
Name (Role A): requiresInformation -> ""
Multiplicity (Role A): 0..* -> Unspecified
Navigable (Role A): TRUE -> FALSE
If the property should be included, then recommend adding its description to the specification and updating the symbol properties for the association to show the name for the role end on the Decision diagram (source for Figure 6-13) and anywhere else it is used.

The association, BKM2EC, exists in the metamodel but is not shown on the BusinessKnowledgeModel diagram (source for Figure 6-15) and neither property defined by the role ends is discussed in the spec:
Name (Role B): encapsulation: BusinessKnowledgeModel [0..1]
Name (Role A): encapsulatedDecisions: ElementCollection [0..1]

The UML metamodel has a property, “parameter : InformationItem [0..*]”, which is not discussed or shown in the specification. It is also not shown in the metamodel BKM diagram and does not exist in the XML schema.

The meta model class DI::DiagramElement is missing properties localStyle and sharedStyle:
https://github.com/omg-dmn-taskforce/omg-dmn-spec/blob/399fd3bff201cfd075435b7019c3be25dfd8306a/xmi/DMNDI15.xmi#L212-L214
which are currently in DMNDiagramElement:
https://github.com/omg-dmn-taskforce/omg-dmn-spec/blob/399fd3bff201cfd075435b7019c3be25dfd8306a/xmi/DMNDI15.xmi#L176-L211

while the XML Schema has them at the right place and also has additional id and extension properties that are not in the MM:
https://github.com/omg-dmn-taskforce/omg-dmn-spec/blob/master/xsd/DI.xsd#L21-L46

The standard does not specify how the "external data source" (see second bullet point) should behave when the value for an InputData is not specified.

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)

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

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.

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

The FEEL functions format-number(value, formatString), format-date(value, formatString), and format-dateTime(value, formatString) are needed in practice and have already been implemented as extension by many vendors. They should therefore be standardized.

The following approaches for formatting should be considered:
https://www.baeldung.com/java-number-formatting
https://developer.mozilla.org/en-US/docs/Web/XML/XPath/Reference/Functions/format-number
https://docs.oracle.com/javase/8/docs/api/java/text/DecimalFormat.html
https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Reference/Element/decimal-format
https://queirozf.com/entries/python-number-formatting-examples
https://doc.rust-lang.org/std/fmt/

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

B-FEEL does not define the behavior when encountering null in a "for expression", a "quantified expression" (some, every) and a "comparison" using the "in" keyword.

The following are not covered by B-FEEL and should:

for x in null return x
some x in null satisfies x>0
every x in null satisfies x>0
1 in null

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

.

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

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

The section 7.3.4 InformationItem metamodel does not specify how the "external data source that is attached at runtime" binds requires inputs when they are missing.

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.

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.

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