1. OMG Specification

# Decision Model and Notation — Open Issues

• Acronym: DMN
• Issues Count: 14
• Description: Issues not resolved
Issues not resolved

# Issues Descriptions

## ambiguity for collections

• Key: DMN16-125
• Status: open
• Source: University of Koblent, SAP Signavio ( Carl Corea)
• Summary:

I do not understand the following aspect about collections: Assume the input data node is a collection, but the decision is NOT a collection. From my understanding, the individual values of the input collection are passed iteratively to the decision. As the latter is NOT a collection in the example, it is my understanding there should be some form of aggregation(?).

I can understand how this should work for numerical values (e.g. "aggregate" by sum) however I am not clear of the aggregation method (is it always sum?). Furthermore, how should aggregation work if the output column of the decision contains strings?

Example: Two rules: "a"->"b", "c"->"d". Then an input collection {"a","c"} is passed. So the two outputs are "b", "d". As the decision is NOT a collection, we should not yield something like {"b","d"}, but should aggregate(?), yet, as stated, how to aggregate b,d?

• Reported: DMN 1.4b1 — Wed, 10 Apr 2024 07:57 GMT
• Updated: Fri, 21 Jun 2024 17:56 GMT

## ambiguity for collections

• Key: DMN17-64
• Status: open
• Source: University of Koblent, SAP Signavio ( Carl Corea)
• Summary:

I do not understand the following aspect about collections: Assume the input data node is a collection, but the decision is NOT a collection. From my understanding, the individual values of the input collection are passed iteratively to the decision. As the latter is NOT a collection in the example, it is my understanding there should be some form of aggregation(?).

I can understand how this should work for numerical values (e.g. "aggregate" by sum) however I am not clear of the aggregation method (is it always sum?). Furthermore, how should aggregation work if the output column of the decision contains strings?

Example: Two rules: "a"->"b", "c"->"d". Then an input collection {"a","c"} is passed. So the two outputs are "b", "d". As the decision is NOT a collection, we should not yield something like {"b","d"}, but should aggregate(?), yet, as stated, how to aggregate b,d?

• Reported: DMN 1.4b1 — Wed, 10 Apr 2024 07:57 GMT
• Updated: Fri, 21 Jun 2024 17:56 GMT

## It is not possible to assign a default value to a data type

• Key: DMN17-57
• Status: open
• Source: Trisotech ( Mr. Denis Gagne)
• Summary:

When creating a data type I cannot assign a default value (for when the user input is provided as null)

• Reported: DMN 1.4 — Thu, 15 Jun 2023 19:56 GMT
• Updated: Fri, 21 Jun 2024 17:56 GMT

## It is not possible to assign a default value to a data type

• Key: DMN16-78
• Status: open
• Source: Trisotech ( Mr. Denis Gagne)
• Summary:

When creating a data type I cannot assign a default value (for when the user input is provided as null)

• Reported: DMN 1.4 — Thu, 15 Jun 2023 19:56 GMT
• Updated: Fri, 21 Jun 2024 17:56 GMT

## Importing libraries of functions is not business friendly

• Key: DMN16-69
• Status: open
• Source: Trisotech ( Mr. Denis Gagne)
• Summary:

There are many different Functions that are needed to make FEEL expressive enough for tackle the logic of various contexts/industries:
e.g Financial Functions, Healthcare Functions, etc. even advanced Mathematical functions or Matrix manipulation functions.

Currently these functions need to be imported in, and then all functions need to be prefixed with a namespace.
This not ideal as the business friendly name with space such as "annual interest rate" now becomes cryptic as "financial.annual interest rate"
or "discount as percentage" becomes "financial.discount as percentage"

• Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:27 GMT
• Updated: Fri, 21 Jun 2024 17:56 GMT

## Importing libraries of functions is not business friendly

• Key: DMN17-54
• Status: open
• Source: Trisotech ( Mr. Denis Gagne)
• Summary:

There are many different Functions that are needed to make FEEL expressive enough for tackle the logic of various contexts/industries:
e.g Financial Functions, Healthcare Functions, etc. even advanced Mathematical functions or Matrix manipulation functions.

Currently these functions need to be imported in, and then all functions need to be prefixed with a namespace.
This not ideal as the business friendly name with space such as "annual interest rate" now becomes cryptic as "financial.annual interest rate"
or "discount as percentage" becomes "financial.discount as percentage"

• Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:27 GMT
• Updated: Fri, 21 Jun 2024 17:56 GMT

## Interchanging models that use external libraries of functions is complicated

• Key: DMN16-70
• Status: open
• Source: Trisotech ( Mr. Denis Gagne)
• Summary:

Currently if a DMN model makes use of an external library of functions, the receiving tool may be challenged in also importing this library and execute on these new functions.

We should explore a way to make the interchanged model not only exchangeable but also executable.

• Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:35 GMT
• Updated: Fri, 21 Jun 2024 17:56 GMT

## Functions cannot invoke external services

• Key: DMN16-67
• Status: open
• Source: Decision Management Solutions ( James Taylor [X] (Inactive))
• Summary:

The current definition of externally-defined functions only allows Java and PMML external functions. There are clear use cases for allow an external (stateless and side-effect free) service to be used in this way.

• Reported: DMN 1.4 — Wed, 16 Mar 2022 19:34 GMT
• Updated: Fri, 21 Jun 2024 17:56 GMT

## Interchanging models that use external libraries of functions is complicated

• Key: DMN17-55
• Status: open
• Source: Trisotech ( Mr. Denis Gagne)
• Summary:

Currently if a DMN model makes use of an external library of functions, the receiving tool may be challenged in also importing this library and execute on these new functions.

We should explore a way to make the interchanged model not only exchangeable but also executable.

• Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:35 GMT
• Updated: Fri, 21 Jun 2024 17:56 GMT

## Functions cannot invoke external services

• Key: DMN17-53
• Status: open
• Source: Decision Management Solutions ( James Taylor [X] (Inactive))
• Summary:

The current definition of externally-defined functions only allows Java and PMML external functions. There are clear use cases for allow an external (stateless and side-effect free) service to be used in this way.

• Reported: DMN 1.4 — Wed, 16 Mar 2022 19:34 GMT
• Updated: Fri, 21 Jun 2024 17:56 GMT

## FEEL descendants operator

• Key: DMN16-72
• Status: open
• Source: Bruce Silver Associates ( Mr. Bruce Silver)
• Summary:

In some decision models, the input data must conform to an industry-standard xml schema in which elements of interest are many levels deep. Converting such a schema directly to a FEEL item definition requires very long path references. The xpath language has a descendants operator that significantly shortens the path expression. I propose a similar operator (or, less ideally, a function) for FEEL.

An example is MISMO from the Mortgage Bankers Association. In home appraisals, one item of interest is the Appraiser. To reference the Appraiser from the FEEL item definition generated from the xsd requires this:
MESSAGE.DOCUMENT_SETS.DOCUMENT_SET.DOCUMENTS.DOCUMENT.DEAL_SETS.DEAL_SET.DEALS.DEAL.SERVICES.SERVICE.VALUATION.VALUATION_RESPONSE.VALUATION_ANALYSES.VALUATION_ANALYSIS.PARTIES.PARTY[ROLES.ROLE.ROLE_DETAIL.PartyRoleType="Appraiser"][1]

In xpath, omitting namespace prefixes, the descendants operator // simplifies this considerably:
MESSAGE//PARTY[.//PartyRoleType='Appraiser']

If // were used as a FEEL descendants operator, you would need only
MESSAGE//PARTY//PartyRoleType="Appraiser"[1]

To get the Appraiser's name, instead of
MESSAGE.DOCUMENT_SETS.DOCUMENT_SET.DOCUMENTS.DOCUMENT.DEAL_SETS.DEAL_SET.DEALS.DEAL.SERVICES.SERVICE.VALUATION.VALUATION_RESPONSE.VALUATION_ANALYSES.VALUATION_ANALYSIS.PARTIES.PARTY[ROLES.ROLE.ROLE_DETAIL.PartyRoleType="Appraiser"].INDIVIDUAL.NAME[1]

you would need only

MESSAGE//PARTY//PartyRoleType="Appraiser"//NAME[1]

• Reported: DMN 1.4b1 — Tue, 14 Mar 2023 19:38 GMT
• Updated: Fri, 21 Jun 2024 17:55 GMT

## Incorrect names for parameters

• Key: DMN16-73
• Status: open
• Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
• Summary:

The names of the number() function in note 1 at the end of Table 72

• Reported: DMN 1.4b1 — Tue, 31 Jan 2023 18:50 GMT
• Updated: Fri, 21 Jun 2024 17:55 GMT

## No Mapping of FEEL to JSON

• Key: DMN16-68
• Status: open
• Source: Red Hat ( Matteo Mortari)
• Summary:

Current DMN Specification v1.4 does not define a mapping of FEEL to JSON, while it already provides mapping for Java, XML, PMML in chapter "10.3.2.12 Mapping between FEEL and other domains"

This capability can be useful in other use-cases beyond mapping itself. For example, but not limiting to: the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services.

• Reported: DMN 1.4 — Wed, 13 Apr 2022 13:22 GMT
• Updated: Fri, 21 Jun 2024 17:55 GMT
• Attachments:

## Friendly enough cohersion to string

• Key: DMN16-71
• Status: open
• Source: camunda.com ( Mr. Nico Rehwaldt [X] (Inactive))
• Summary:

Currently concatenating strings is not intuitive to users, as I always have to convert non string values to strings using the built-in `string` function.

So

```
"Today is " + now() = null
```

In order to yield the actual string you explicitly convert `now()` to its string representation:

```
"Today is " + string(now()) = "Today is 2021-12-12"
```

A more user friendly behavior would be to coherse the second argument to string if the first argument is already a string. This always yields a string representation of the thing. If it is not what I desire I can use custom stringification mechanisms explicitly.

We'd need to amend the Table 57 (page 128, https://www.omg.org/spec/DMN/1.4/Beta1/PDF) to support such cohersion.

Additional details on this case can be found in https://github.com/dmn-tck/tck/issues/538 (DMN TCK issue on this topic).

• Reported: DMN 1.4b1 — Thu, 19 Jan 2023 12:50 GMT
• Updated: Fri, 21 Jun 2024 17:55 GMT