Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — Open Issues

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

Issues Descriptions

Friendly enough cohersion to string

  • Key: DMN16-71
  • Status: open  
  • Source: ( Nico Rehwaldt)
  • 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: Thu, 14 Sep 2023 14:38 GMT

FEEL descendants operator

  • Key: DMN16-72
  • Status: open  
  • Source: Bruce Silver Associates ( 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: Tue, 18 Jul 2023 15:44 GMT

Importing libraries of functions is not business friendly

  • Key: DMN16-69
  • Status: open  
  • Source: Trisotech ( 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: Wed, 12 Apr 2023 13:06 GMT

Incorrect names for parameters

  • Key: DMN16-73
  • Status: open  
  • Source: Goldman Sachs ( 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: Thu, 6 Apr 2023 14:59 GMT

Interchanging models that use external libraries of functions is complicated

  • Key: DMN16-70
  • Status: open  
  • Source: Trisotech ( 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: Thu, 6 Apr 2023 14:59 GMT