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.

Possible solution:

• deprecate the attributes (e.g. DMNElement.label)
• add a constraint (e.g. DRGElement.name == DRGElement.variable.name)

In section 10.3.4.9 of the DMN 1.5 specification (page 153, PDF 161) the sort function is defined with the possibility to use a precedes boolean function to compare list elements.

Text should be added after table 80 to clarify how the precedes function deal with equal parameters.

I would propose that precedes return false when both parameters are equals.

This new paragraph should also establish the stability expectation of the sort FEEL function (equal elements keep the order of the original list).

I would propose that the FEEL sort function does not guarantee stability. Guaranteeing stability could impact certain sort performances.

Especially when used in projects that use ML or AI models, the current approach to Knowledge Sources is not fit for purpose. A more structured, template-based approach is needed to specify what information should be captured about a policy document, a regulation, a MVAR/imputation approach, an ML model training regime, data distributions etc. Either a defined set of knowledge source types should be defined with more specific properties or it should be possible to define, exchange and use templates.

DMN models are serialized in the XML format. XML notation is not user-friendly.

I suggest adopting an equivalent textual notation that is user-friendly similar to the HUTN notation for UML https://www.omg.org/spec/HUTN/1.0/PDF

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.

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.

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.

Currently, the version of DMN used in an DMN XML file is identified by the XML namespace URI, which is therefore changed with every revision. However, frequently changing namespace URIs cause market fragmentation across supported specification versions, as it cannot be assumed that all vendors update to the latest version of the spec at the same time, if at all.

This forces users to do unnecessary version migrations, or their models would be rejected by a tool as invalid or outdated even though language features used in the model may be perfectly supported by the tool. This issue has also been recognized by Specification Common Elements (SCE) in SCE-117.

With DMN shipping bugfixes on a yearly pace, the fragmentation of the tool market increases, while the actual number of changes to the XML schema decreases. In fact, DMN 1.6 has zero changes to the XML schema at all but if it would follow the "tradition", it would again declare itself totally incompatible with DMN 1.5 and all prior versions.

DMN 1.x revisions have been following the backwards compatibility guidelines for machine-readable files and XML schemas as defined in the OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces (smsc/2018-08-01). Therefore, DMN 1.x revisions should not change the namespace URL until a version 2.0 introduces breaking changes, which is not planned at the moment.

The "tradition" to always change the namespace has somewhat accidentally grown:

• DMN 1.1 had to legitimately change the namespace because the XML serialization from DMN 1.0 was unimplementable and required breaking changes
• DMN 1.2 had to change the namespace because the one from DMN 1.1 did not conform to OMG's policy (due to last-minute bad advice from the technical director at the time)
• DMN 1.3 jumped on that to abuse it as a version indicator
• DMN 1.4 and DMN 1.5 followed to be "consistent with the scheme"

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.

For tools to clearly identify the version of a DMN file or FEEL expression, the XML namespaces of DMN, and FEEL should be updated.

Namespace URIs must be backwards compatible with the scheme applied in previous versions for tools that support multiple versions in parallel. See:

• https://issues.omg.org/browse/DMN12-62?focusedCommentId=18500&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-18500
• DMN13-191
• DMN14-166
• DMN15-160

DMN DI, DI, and DC namespaces can stay the same as DMN 1.6 DI is unchanged since 1.5 and still based on the same DD 1.1 specification and "OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces in OMG Specifications", states explicitly:

Note: if a spec has many machine readable files, and only some of them change at a given specification version, then only the changed files should get new URIs. That could mean a mixture of URI date segment values for a given specification version.

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.

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.

The specification lists for 1.6 will list three external function types - Java, PMML and ONNX. It is not reasonable to insist on support for these to be conformant.
2.1 Conformance Levels should be amended such that Conformance Level 3 excludes the need to support any function Kind other than FEEL - support for Java, PMML and ONNX is not required..

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 ] ;

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

The Copyright section needs an update to reflect the DMN 1.6 RTF membership

Section 4.1 Acknowledgement needs to be updated with DMN 1.6 RTF contributors.

Abusing null as an error indicator is not enough for reporting/handling errors.
In particular, it does not solve the need for users to:

• know exactly what the root cause of an error was
• control the reaction to errors

The specification already mentions error reporting but is neither a strict requirement nor consequently used:

When a built-in function encounters input that is outside its defined domain, the function SHOULD report or log diagnostic information if appropriate and SHALL return null.

Section "12.2 Machine Readable Files" refers to dtc/15-11-12 as a source for XMI and XSDs. This is wrong in several ways:

• The file is from DMN 1.1
• It is the ancillary .zip file of the RTF report, which contains a mix of normative files but also internal files of various RTF discussions
• Therefore, it is restricted to OMG members only

There are a few other DMN example files with the same error as in DMN15-74. Also the typeRef, has to move into the body of the BKM not the encapsulatedLogic as this one is the same with BKM.typeRef.

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

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.

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?