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

Positive unary tests lack equality operators

  • Key: DMN15-108
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    Currently the positive unary tests support all relational operators but not the equality operators (= !=). We should support them for consistency. For example, all the above operators are supported in comparison expressions (rule 49).

    Business analysts have reported that they would like to have a consistent and more readable way to write rules and test cases with many comparison operators.

  • Reported: DMN 1.4b1 — Tue, 31 May 2022 08:40 GMT
  • Updated: Tue, 2 Aug 2022 16:59 GMT

No Mapping of FEEL to JSON

  • Key: DMN15-101
  • 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 proposal adds mapping of FEEL to JSON.

    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: Tue, 2 Aug 2022 16:32 GMT
  • Attachments:

No support for numbers in scientific notation

  • Key: DMN15-107
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    Currently the syntax of numeric literals does not support usage of exponents. This is quite useful when dealing with large numbers.

  • Reported: DMN 1.4b1 — Tue, 31 May 2022 07:59 GMT
  • Updated: Tue, 2 Aug 2022 16:20 GMT

Typo in "10.3.1.2 Grammar rules" 3rd bulletpoint in the bottom

  • Key: DMN15-94
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    With reference to DMNv1.4 dtc-21-12-01,
    section "10.3.1.2 Grammar rules",
    page 104 (PDF 120)
    the 3rd bulletpoint in the bottom is referring to the wrong grammar rule number.

    This is likely a typo originating from the need of additional grammar rules being added in previous version of the Spec.

    This can be trivially fixed editorially, with the associated proposal.

  • Reported: DMN 1.4 — Thu, 17 Mar 2022 17:22 GMT
  • Updated: Tue, 2 Aug 2022 16:16 GMT

There are questions regarding precedence of operator between negation and exponation

  • Key: DMN15-109
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    in FEEL -4**2 = 16
    Some may expect = -16

  • Reported: DMN 1.4 — Tue, 5 Jul 2022 17:03 GMT
  • Updated: Tue, 26 Jul 2022 14:57 GMT

Incorrect reference to FEEL rule

  • Key: DMN15-106
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    In the following bullet point:

    In rule 62, the only permitted functions are the builtins date, time, date and time, and duration.

    the correct reference is rule 60 where the date time literals are defined.

  • Reported: DMN 1.4b1 — Tue, 31 May 2022 07:56 GMT
  • Updated: Tue, 7 Jun 2022 17:32 GMT

Acknowledgements for DMN 1.4 and 1.5 contributors needed

  • Key: DMN15-104
  • Status: open  
  • Source: Camunda Services GmbH ( Falko Menge)
  • Summary:

    Section "4.1 Acknowledgements" is missing paragraphs to acknowledge the DMN 1.4 and 1.5 contributors, especially since some people left the task force.

  • Reported: DMN 1.4b1 — Tue, 24 May 2022 17:46 GMT
  • Updated: Tue, 24 May 2022 17:46 GMT

No built-in function to support Range conversion

  • Key: DMN15-99
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Current DMN Specification v1.4 does not define a Built-in function to support Range conversion.

    This capability can be useful in other use-cases beyond conversion itself. For example, but not limiting to: the need to have FEEL:range as an input of the model, the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services, etc.

  • Reported: DMN 1.4 — Wed, 13 Apr 2022 13:07 GMT
  • Updated: Tue, 24 May 2022 16:47 GMT
  • Attachments:

Gaps: Range as input, mapping to JSON, evaluation of non-FEEL expression languages

  • Key: DMN15-96
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Current DMN Specification v1.4 has a few gaps in the following areas:

    1. Built-in function to support Range conversion
    2. Mapping of FEEL to JSON
    3. Evaluation of other expression language beyond FEEL

    In addition to the above gaps, during conversations in the OMG DMN RTF group, and in other communities with DMN interests, SMEs and Vendors have reported on the missing capabilities for a complete, semantically well-defined and interoperable solution, connected to the mentioned cases. For example, but not limiting to: the need to have FEEL:range as an input of the model, the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services, etc.

    The pragmatic aspects introduced in this proposal to cover the mentioned gaps above, could also be a meaningful foundational and propaedeutic work if the OMG DMN RTF group will want to pursue to eventually propose the DMN Specification to ISO, and/or the group will want to pursue to eventually refactor FEEL into its own stand-alone Specification.

    Finally, the DMN Specification already provides recommendations in the Annex(es) for integrations, in the scope of BPMN, etc., for harmonised semantic and potential improved interoperability; the DMN Spec could also offer similar recommendations in the scope of gap 3 identified above.

    This document advances pragmatic proposals that would both cover the existing gaps and provide the capabilities required to a well-defined and more interoperable solution.

  • Reported: DMN 1.4 — Fri, 25 Mar 2022 08:29 GMT
  • Updated: Tue, 12 Apr 2022 16:14 GMT

DMN 1.4 updated XMI references external file DMN14.mdxml

  • Key: DMN15-98
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    The dtc/21-12-03 "DMN14.xmi updated" contains some references to a file DMN14.mdxml,

    252:        <type href="DMN14.mdxml#_17_0_5_1_a250249_1518651646564_243499_3956"/>
    655:        <type href="DMN14.mdxml#_17_0_2_3_ea50349_1435268843602_88699_2217"/>
    656:        <association href="DMN14.mdxml#_17_0_2_3_ea50349_1435269041753_841899_2676"/>
    666:        <type href="DMN14.mdxml#_17_0_2_3_ea50349_1435268832194_670602_2213"/>
    667:        <association href="DMN14.mdxml#_17_0_2_3_ea50349_1435269293045_464837_2775"/>
    677:        <type href="DMN14.mdxml#_17_0_2_3_ea50349_1435268824892_950814_2209"/>
    678:        <association href="DMN14.mdxml#_17_0_2_3_ea50349_1435269539220_831013_2875"/>
    2298:      <memberEnd href="DMN14.mdxml#_17_0_5_1_a250249_1518651855436_638563_4054"/>
    

    Please check whether those references are intended and if so, please clarify where to obtain that file.

  • Reported: DMN 1.4 — Mon, 4 Apr 2022 21:56 GMT
  • Updated: Wed, 6 Apr 2022 15:55 GMT

Functions cannot invoke external services

  • Key: DMN15-91
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor)
  • 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: Wed, 16 Mar 2022 19:40 GMT

UNused Requirements are considered invalid

  • Key: DMN15-88
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Executive summary: by the way the DMN specification stands, the description that Requirements SHALL (== "MUST") be referenced in the expression will nullify any CL1 DMN model and any DMN model not using FEEL, as not-conformant.

    In section 7.3.4 InformationItem metamodel we read:

    A variable representing an instance of Decision or InputData referenced by an InformationRequirement SHALL be referenced by the value expression of the decision logic in the Decision element that contains the InformationRequirement element. A parameter in an instance of BusinessKnowledgeModel SHALL be a variable in the value expression of that BusinessKnowledgeModel element.

    By side effect of this strict mandate in the specification, it is like saying an UNused requirement will fail conformance.

    Example: a decision enlist A, B, C as Requirements, but in the formula we use only A and B. According to the current spec, this makes the model failing conformance and invalid.

    Granted, it is always a best practice not only for BA but also for developers to avoid "unused requirements/variable"!
    But here is giving a strict mandate.

    Further, any DMN model which does not use FEEL "only DRG" automatically fail this constraint which is in Chapter 7.

    The DMN specification should follow best-practices of Modeling AND programming languages, where is NOT a blocking issue to have "unused requirements/variables", but of course warn when those are detected; this can be easily achieved by switching SHALL to SHOULD in the identified paragraphs in chapter 7.1 and 7.3.4 per proposal.

    This issue was detected in the TCK group (ref https://github.com/dmn-tck/tck/issues/487 )

  • Reported: DMN 1.4 — Sun, 27 Feb 2022 20:45 GMT
  • Updated: Tue, 15 Mar 2022 17:22 GMT

Typo in 6.3.7 Decision metamodel

  • Key: DMN15-83
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    In the chapter "6.3.7 Decision metamodel",
    a reference is made to the fact a Decision's Name MUST be unique in the model, but there is likely a wrong copy-paste of a sentence from other section of the spec.

    It currently reads as:

    The name of an Invocable must be different from the name of any other invocable, input data, decision, or import in the decision model.

    But a Decision is NOT an Invocable.

    In the chapter "6.3.9 Business Knowledge Model metamodel" the same pharse is used and there is valid since a BKM is indeed an Invocable.

    In the chapter "6.3.11 Input Data metamodel" the analogous phrase is correctly adapted, since it reads as:

    The name of an InputData must be different from the name of any other decision, input data, business knowledge model, decision service, or import in the decision model.

    Conclusion

    Only in chapter chapter "6.3.7 Decision metamodel" the phrase is wrong as referring to "Invocable" when in fact it should have just used the term "Decision". The proposal will address this accordingly.

  • Reported: DMN 1.4 — Wed, 19 Jan 2022 12:58 GMT
  • Updated: Wed, 2 Mar 2022 00:53 GMT

Typo in 8.3.1 Decision Table metamodel "DecsionTable"

  • Key: DMN15-81
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    In the paragraph of 8.3.1 Decision Table metamodel

    DecisionTable inherits all the attributes and model associations from Expression. Table 32 presents the additional attributes and model associations of the DecsionTable element.

  • Reported: DMN 1.4 — Wed, 5 Jan 2022 08:48 GMT
  • Updated: Wed, 2 Mar 2022 00:53 GMT

Typo in the DMN 1.4 XSD schema (complexType tFilter)

  • Key: DMN15-79
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Typo of spurious trailing whitespace in the name of the complexType "tFilter " (notice the extra space at the end) make XSD validators to fail to validate the XML Schema itself.

  • Reported: DMN 1.4 — Mon, 3 Jan 2022 16:30 GMT
  • Updated: Wed, 2 Mar 2022 00:53 GMT

Table 62 limited to "negative numbers"

  • Key: DMN15-86
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    In 10.3.2.15 Semantic mappings,
    Table 62: Semantics of negative numbers

    per its description is limiting to negative numbers, but by Table 59 it's possible to multiply a duration (years and months duration, days and time duration) by a number.

    Hence, it's already possible to do

    duration("PT1H")*-1
    

    but formally is not allowed to do

    -duration("PT1H")
    

    It should be easier to widen the semantic of Table 62 to negate numbers AND duration to allow the second case.

    This was identified in the TCK group, ref https://github.com/dmn-tck/tck/issues/482

  • Reported: DMN 1.4 — Sun, 27 Feb 2022 20:23 GMT
  • Updated: Sun, 27 Feb 2022 20:23 GMT