Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — Open Issues

  • Acronym: DMN
  • Issues Count: 6
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Friendly enough cohersion to string

  • Key: DMN16-71
  • Status: open  
  • Source: ( 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.


    "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, to support such cohersion.

    Additional details on this case can be found in (DMN TCK issue on this topic).

  • Reported: DMN 1.4b1 — Thu, 19 Jan 2023 12:50 GMT
  • Updated: Mon, 13 May 2024 00:40 GMT

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, 10 May 2024 00:19 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, 10 May 2024 00:19 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 " as percentage"

  • Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:27 GMT
  • Updated: Fri, 10 May 2024 00:19 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, 3 May 2024 23:59 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:

    In xpath, omitting namespace prefixes, the descendants operator // simplifies this considerably:

    If // were used as a FEEL descendants operator, you would need only

    To get the Appraiser's name, instead of

    you would need only


  • Reported: DMN 1.4b1 — Tue, 14 Mar 2023 19:38 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT