In the DMN spec the only supported number type is decimal.

However, there are a few places (e.g. scale in round functions and list access) when an integer is needed.

What is the expected behavior when an integer is expected but a decimal number is provided? For example 'decimal(123, 5.6)' or ''remove([1, 2], 1.5).

Is this an error or the engine recovers from the error and uses only the integer part of the number?

According to the DMN spec (10.3.2.3.1 number) a number is equivalent to "Java BigDecimal with MathContext DECIMAL 128.".

The Java doc states, " A BigDecimal consists of an arbitrary precision integer unscaled value and a 32-bit integer scale.".

However, the DMN spec de scale is in range range [−6111..6176].

The question is what is the correct range for scale?

In section 10.3.1.3 Literals, data types, built-in functions, there is an enumeration of FEEL datatypes.

The first 3 starts with uppercase letters (Number, String, Boolean) while the other starts with lowercase letters.

Number, String and Boolean should be number, string, boolean like presented in the Figure 10-26: FEEL lattice type on page 112.

Currently the in parameter is defined as: This attribute holds the expression that is evaluated as the collection to be processed.

The intention was to align with the FEEL version of filter and iterators and therefore apply the the 10.3.2.9.4 Type conversions rule: to singleton list: When the type of the expression is T and the target type is List<T> the expression is converted to a singleton list.

The definition of the in parameter needs to be updated to properly reflect this.

The below text was a separate paragraph in DMN 1.4. In DMN 1.5 is a part of the previous paragraph. Also, the new typeConstraint property is missing.

An alternative way to define an instance of ItemDefinition is as a composition of ItemDefinition elements. An instance of ItemDefinition may contain zero or more itemComponent, which are themselves ItemDefinitions. Each itemComponent in turn may be defined by either a typeRef and allowedValues or a nested itemComponent. In this way, complex types may be defined within DMN. The name of an itemComponent (nested ItemDefinition) must be unique within its containing ItemDefinition or itemComponent.

Currently, `string(string_variable) = string_variable`, but `number(number_variable) = null`.
This leads to surprising results like `number(5) = null` but `number("5") = 5`.
Let's add a function `number(from)` which would accept `number` as the parameter.

According to 6.3.1 DMN Element metamodel and 6.3.5 DRG Element metamodel, DRGElements have name and label attributes.

They also have a variable property that has a name. The DMNDI model also has a label property.

To avoid confusion I suggest deprecating the attributes from the DRG Element metamodel.

Here, I am considering the following operators: =, <, >, not(), and, or, in, between

When considering FEEL for low-codes applications, we should expect these binary operators to always return true or false. Currently, when there is typing error, it returns null.

ex:
"a" = 1 => null
false and "a" => null
"a" in [0..100] => null
...

There is clear value to ML projects of using DMN to document their projects (requirements, project design, MLOps). ML programmers though use Python not Java for their functions. If DMN can support Java libraries for rules developers, it should support Python for ML developers.

ONNX https://onnx.ai/ is an open format for ML models that supports some model types, especially neural networks, better than PMML. DMN should consider allow ONNX functions as it does PMML functions.
PFA removed as doesn't have the traction that ONNX has
Open issue on mappings

Currently the 4 rounding methods: round up, round down, round half up, round half down only have signatures with 2 numeric arguments (n and scale).

However, pre-existing rounding functions: floor and ceiling have both a single numeric argument version and a 2 numeric argument function (n and scale).

The single numeric argument is backward compatible with DMN 1.3 (and before). It assumes a scale of 0.

Grammar rule does not match to the one in proposal https://issues.omg.org/browse/DMN15-107

35. numeric literal = [ "" ] , ( digits , [ ".", digits ] | "." , digits, [ ( "e" | "E" ) , [ "+" | "" ] , digits ] ) ;

should be

35. numeric literal = [ "" ] , ( digits , [ ".", digits ] | "." , digits) , [ ( "e" | "E" ) , [ "+" | "" ] , digits ] ;

Sections 10.3.2.9.1 Type Equivalence and 10.3.2.9.2 Type Conformance define relations between types.

The definitions do not contain specification for existing builtin functions with variable arguments (e.g. sum).

The issue was discovered in TCK when testing function invocations.

When a decision service is fully defined, its dependencies are shown as the information requirements of its encapsulated decisions on external decisions or input data. If the encapsulated decisions of a decision service are not fully defined (e.g. temporarily during analysis, or because it is modelling a 3rd-party service with partial obfuscation), this may not be possible. It would be convenient in such cases to be able to draw information dependencies attaching to the boundary of the decision service. Such a service would not be executable.

This issue is a continuation of https://issues.omg.org/browse/DMN15-36 which was deferred to 1.6.