Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — Open Issues

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

Issues Descriptions

Frequently changing Namespace URIs cause market fragmentation

  • Key: DMN16-130
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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:

  • Reported: DMN 1.5b1 — Mon, 22 Apr 2024 19:36 GMT
  • Updated: Tue, 23 Apr 2024 03:51 GMT

Outdated reference to machine readable files

  • Key: DMN16-132
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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
  • Reported: DMN 1.5b1 — Mon, 22 Apr 2024 21:48 GMT
  • Updated: Mon, 22 Apr 2024 21:48 GMT

Examples use typeRef for BKMs incorrectly

  • Key: DMN16-128
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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.

  • Reported: DMN 1.5b1 — Mon, 22 Apr 2024 16:15 GMT
  • Updated: Mon, 22 Apr 2024 16:43 GMT

Returning null is not enough for reporting/handling errors

  • Key: DMN16-117
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    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.

  • Reported: DMN 1.5b1 — Tue, 30 Jan 2024 17:00 GMT
  • Updated: Thu, 11 Apr 2024 03:00 GMT

Clarification on the FEEL sort function with the precedes function

  • Key: DMN16-123
  • Status: open  
  • Source: Trisotech ( Mr. Simon Ringuette)
  • Summary:

    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.

  • Reported: DMN 1.5b1 — Thu, 21 Mar 2024 19:28 GMT
  • Updated: Thu, 4 Apr 2024 15:10 GMT

Missing paragraph break and new constraintType

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

    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.

  • Reported: DMN 1.5b1 — Thu, 2 Nov 2023 11:42 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

Filter and Iterator in attribute should not require a collection

  • Key: DMN16-94
  • Status: open  
  • Source: Trisotech ( Mr. Simon Ringuette)
  • Summary:

    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.

  • Reported: DMN 1.5b1 — Thu, 19 Oct 2023 21:59 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

Inconsistent capitalization of datatypes names

  • Key: DMN16-92
  • Status: open  
  • Source: Trisotech ( Mr. Simon Ringuette)
  • Summary:

    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.

  • Reported: DMN 1.5b1 — Tue, 17 Oct 2023 15:16 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

Behaviour when decimal is provided but integer expected

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

    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?

  • Reported: DMN 1.5b1 — Thu, 20 Jul 2023 15:34 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

Range of scale for number is open to interpretation

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

    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?

  • Reported: DMN 1.5b1 — Thu, 20 Jul 2023 15:23 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

XML serialization is not human friendly

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

    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

  • Reported: DMN 1.5b1 — Tue, 5 Dec 2023 11:28 GMT
  • Updated: Thu, 28 Dec 2023 02:48 GMT

Duplicated names and labels

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

    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)
  • Reported: DMN 1.5b1 — Mon, 27 Nov 2023 10:49 GMT
  • Updated: Tue, 19 Dec 2023 09:58 GMT

Add `number(from: number)` function

  • Key: DMN16-105
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Maciej Barelkowski)
  • Summary:

    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.

  • Reported: DMN 1.5b1 — Tue, 7 Nov 2023 14:46 GMT
  • Updated: Tue, 5 Dec 2023 18:58 GMT

Rounding functions introduced in DMN 1.4 should have single parameter version

  • Key: DMN16-93
  • Status: open  
  • Source: Trisotech ( Mr. Simon Ringuette)
  • Summary:

    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.

  • Reported: DMN 1.5b1 — Thu, 19 Oct 2023 21:52 GMT
  • Updated: Tue, 24 Oct 2023 16:18 GMT

Grammar rule does not match with the one proposal - typo

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

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

  • Reported: DMN 1.5b1 — Tue, 15 Aug 2023 13:43 GMT
  • Updated: Tue, 26 Sep 2023 16:09 GMT

Relation conforms to and equivalent do not cover functions with variable arguments

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

    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.

  • Reported: DMN 1.5b1 — Tue, 4 Jul 2023 07:57 GMT
  • Updated: Tue, 11 Jul 2023 20:11 GMT