Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — Open Issues

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

Issues Descriptions

No way to represent a black-box or incompletely defined Decision Service


"instance of" not possible with some built-in functions

  • Key: DMN15-53
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    some built in functions are overloaded in that they can have multiple signatures. So, say, performing an "instance of" to compare against the function "min" is meaningless as the signature is not known unless it is invoked.

    Unless the type system is to take into account overloaded functions?

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:15 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

Inconsistency DMNv1.2 dropping [a]=a and get entries example

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

    Since DMNv1.2 the spec dropped the equivalence of:

    [a] = a
    

    because it does not apply to the statement that

    a singleton list L, when used in an expression where a list is not expected, behaves as if L[1] is written.

    So the expression

    [a] = a
    

    on DMNv1.2 is expected to return false.

    However, in section 10.3.2.6 Context of the spec, it provides the following statement for the get entries function:

    To retrieve a list of key,value pairs from a context m, the following built-in function may be used: get entries(m).
    For example, the following is true:

    get entries({key 1 : "value 1 "})[key="key 1 "].value = "value 1 "
    

    BUT

    get entries({key1 : "value1"})[key="key1"].value = "value1"
    
      by substitution:
    
    [ { key : "key1", value : "value1" } ][key="key1"].value = "value1"
    [ { key : "key1", value : "value1" } ].value = "value1"
    [ "value1" ] = "value1"
    

    according to DMNv1.2 should be false

    By the same principle that the DMNv1.2 for the following literal expression:

    [123] = 123
    

    on DMNv1.2 is expected to be false

  • Reported: DMN 1.2b1 — Wed, 30 Jan 2019 14:43 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

properly define type(e)

  • Key: DMN15-51
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In some places the spec uses type(e) and other places type(e). These are different. The former provides a type-checking function that can validate a FEEL expression e without input data values (although some kind of scope is needed for disambiguation). The latter simply returns the datatype of the semantic domain element e. The former is more useful to implementors, but more work to specify. Essentially, all the semantic mapping tables need a new column to specify the result type given the input types, for each FEEL operator and builtin. The latter is a matter of generalizing Table 39. It must cover cases such as type([0,false]). It should be clear that type(e) as a function must return the most specific type (and there must be only 1), but informally the types also include those that are conformed to, so for example, [1,2,3] has types list<number>, list<Any>, Any.

  • Reported: DMN 1.2 — Tue, 27 Nov 2018 22:31 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

Typos in the XMI files

  • Key: DMN15-56
  • Status: open  
  • Source: Camunda GmbH ( Maciej Barelkowski)
  • Summary:

    I found two typos in the XMI files:
    1. In the DMNDI12.xmi, lines 510-512:

    ```
    <packagedElement xmi:type="uml:Class" xmi:id="_18_1_f7a0369_1441612964861_428140_5975"
    name="DC::Style"
    isAbstract="true"/>
    ```

    The class cannot refer to dc:Style as such class does not exist. The XSD refers to di:Style.

    2. In the DMN12.xmi, lines 956-958:

    ```
    <ownedAttribute xmi:type="uml:Property" xmi:id="_17_0_3_1_42401a5_1375643571589_681805_3414"
    name="input
    "
    visibility="public"
    ```

    Attribute name includes an encoded newline character (`\n`) which is not present in the XSD.

  • Reported: DMN 1.2 — Thu, 19 Dec 2019 13:19 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

Clarification on DMN case sensitivity of timezones

  • Key: DMN15-50
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    DMN spec refers to usage of iana timezones. iana does not specify that timezones are case-sensitive - that is up to the implementation. https://data.iana.org/time-zones/theory.html: re zone naming:

    "Do not use names that differ only in case. Although the reference implementation is case-sensitive, some other implementations are not, and they would mishandle names differing only in case."

    This issue is seeking clarification via the spec as to whether DMN's usage of time zones permits case insensitivity such that "etc/utc" is the same zone as "Etc/UTC" ... or not.

  • Reported: DMN 1.2 — Sat, 16 Mar 2019 01:12 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

Support for recursive calls by Business Knowledge Models

  • Key: DMN15-49
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The definition of "well formed" for a BusinessKnowledgeModel excludes the notion of the encapulatedLogic of a BusinessKnowledgeModel being able to invoke itself to permit recursion. There is no means to define a 'self' relationship via knowledgeRequirements - the spec forbids it.

    However, vendors are currently supporting BusinessKnowledgeModel recursion simply by permitting a BusinessKnowledgeModel's encapulatedLogic to invoke the contained BusinessKnowledgeModel as a function using the contained BusinessKnowledgeModel's name. I propose we formalise this in the spec.

    I propose that after the definition of well-formed on page 56/57 (repeated below):

    "An instance of BusinessKnowledgeModel is said to be well-formed if and only if, either it does not have any knowledgeRequirement, or all of its knowledgeRequirement elements are well-formed. That condition
    entails, in particular, that the requirement subgraph of a BusinessKnowledgeModel element SHALL be acyclic, that is, that a BusinessKnowledgeModel element SHALL not require itself, directly or indirectly. "

    The following paragraph is added:

    "However, the encapsulatedLogic within a BusinessKnowledgeModel may invoke itself in a recursive manner by using the name of the containing BusinessKnowledgeModel as an invokable name."

  • Reported: DMN 1.2 — Sat, 6 Apr 2019 02:38 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

Lack of visual notation for processing of / iteration over lists in FEEL

  • Key: DMN15-48
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    split off from DMN13-12

  • Reported: DMN 1.2 — Tue, 20 Nov 2018 17:55 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

Temporal precision inconsistencies

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

    The spec sometimes refers to the temporal precision as milliseconds and sometimes to seconds. Sections 10.3.2.3.3, 10.3.2.3.5 and 10.3.2.3.6 refer to Seconds whereas table 48 offers a semantic of Milliseconds

  • Reported: DMN 1.2b1 — Tue, 16 Jul 2019 14:02 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

Clarification regarding equivalence of date vs date and time

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

    Section 10.3.2.3.5 date contains the following:

    Where necessary, including the valuedt function (see 10.3.2.3.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00).

    Is not obvious when the equaivalence should be applied.

    One option is to add an implicit conversion, similar to the ones for singleton lists.

  • Reported: DMN 1.2 — Sun, 2 Jun 2019 13:01 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT
  • Attachments:

Friendlier handling of null values

  • Key: DMN15-47
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    E.g. in aggregation, default for item definition, see examples in DMN-2, where filters like [item!=null] are used repeatedly

  • Reported: DMN 1.2b1 — Tue, 21 May 2019 16:53 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

Provide better spec and examples for Equality, Identity, and Equivalence

  • Key: DMN15-46
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    the builtin function is() refers to this section. It should cover some pos/neg examples of equality vs. identity, and explain aggregate elements in D, e.g. list of structures.

  • Reported: DMN 1.2b1 — Tue, 28 May 2019 16:40 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

Clean up example xml files

  • Key: DMN15-45
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Sample xml files have Trisotech extension elements. These should be removed prior to publication.

  • Reported: DMN 1.2b1 — Tue, 28 May 2019 16:52 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

Situational Data Model and Notation (SDMN)

  • Key: DMN15-40
  • Status: open  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    Situational Data is the set of Data Items and their structures that are needed for the performance and understanding of a Knowledge Package Model.
    The details of the Data Items will usually be a subset of the “official” complexity of those items in the environment of the Knowledge Package Model.
    For example, the official definition of the Data Item for Blood Pressure (in healthcare) includes more than 50 properties. A Data Item in a Situational Data Model may need only 2 of those properties for execution of the Processes, Cases, and or Decision Services.
    Semantic References can be added to link the Data Item to the “official” details.
    Uses of the Data Items in BPM+ models that determine the scope of Situational Data include:
    Data required for DMN Decisions
    Data required for BPMN Gateways transitions
    Data required to be passed to/from services invoked by BPMN and CMMN
    Data required to trigger Sentries in CMMN
    Etc.

  • Reported: DMN 1.2b1 — Tue, 10 Sep 2019 18:04 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT
  • Attachments:

inconsistent date comparisons make unavoidavle paradoxes

  • Key: DMN15-39
  • Status: open  
  • Source: fujitsu america ( keith swenson)
  • Summary:

    Date "=" is defined to include the time zone, and "<" and ">" does not. This causes a bunch of problems.

    see: https://social-biz.org/2017/08/03/a-strange-feeling-about-dates/

    Suggestion is simple: define date equality to be (date1 - date2 == 0) Eliminate the need to compare the "timezone" of the dates.

    My experience with the group is that most suggestions are ignored, so I don't really want to waste any time making a more detailed proposal, but if you have questions about this problem you can contact me.

  • Reported: DMN 1.2 — Wed, 18 Sep 2019 10:01 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

data equivalence with date and time

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

    Section 10.3.2.3.5 contains the following:

    Where necessary, including the valuedt function (see 10.3.2.3.6), a date value is considered to be equivalent to a date time
    value in which the time of day is UTC midnight (00:00:00).

    It is not very clear where this equivalence is going to be applied.

    The proposal is to specify the above in a more precise manner, possibly as an implicit conversion.

  • Reported: DMN 1.2 — Mon, 27 May 2019 08:30 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

DMN Models need a default timezone

  • Key: DMN15-38
  • Status: open  
  • Source: fujitsu america ( keith swenson)
  • Summary:

    All date expressions, if the timezone is not explicitly mentioned, are interpreted as being in the timezone of the computer running the code. This means you can design a model that runs correctly in one timezone,a nd incorrectly in a different one.

    Imagine you have a development team in Bangalore which makes a DMN model that runs correctly and passes all the tests. Then it is installed into the company server in London, and it fails.
    Does anyone think this is a good idea?

    The solution is simple: the model should have a default timezone. All date expressions that don't mention the timezone are interpreted according to this default time zone, and NOT according the timezone of the machine you are running on. Then, models will run exactly the same way no matter where it is run. That is a good idea, right?

    See this: https://social-biz.org/2017/08/03/a-strange-feeling-about-dates/

  • Reported: DMN 1.2 — Wed, 18 Sep 2019 09:55 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT

Knowledge Package Model and Notation (KPMN)

  • Key: DMN15-41
  • Status: open  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    A Knowledge Package is mechanism for packaging and distributing a set of BPM+ models (the knowledge)
    A Knowledge Package references separate, but connected BPM+ models (BPMN Processes, CMMN Cases, and DMN Decision Services)
    KPMN is focused solely on the BMI behavioral standards
    A Knowledge Package also contains a Data Item library for the data that will be used by the BPM+ models
    A Situational Data Model and Notation (SDMN) is also being proposed as a potential BMI standard to be added to the BPM+ stack (see separate presentation on this topic)
    A Knowledge Package also contains metadata about the topic of the package to aid in understanding the content and to find appropriate Knowledge Packages
    We are still exploring the relationships between KPMN and Provenance and Pedigree
    KPMN includes a diagram to illustrate the scope of the Knowledge Package’s content (a Knowledge Model Diagram)

  • Reported: DMN 1.2b1 — Tue, 10 Sep 2019 17:59 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT
  • Attachments:

Fix interchange of links to objects in BPMN/BMM

  • Key: DMN15-37
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor)
  • Summary:

    The current spec uses objects from BMM and BPMN. However it is not at all clear how links to these objects, and the objects at the end of the links, should be interchanged. Does the DMN file contain a snippet of BPMN? Should a separate BPMN file be generated and then referenced? If we are going to have these links then we need to show/explain how to interchange them both with tools that only support DMN (and so only have a few BPMN or BMM objects) and with those that support DMN/BPMN/BMM.

  • Reported: DMN 1.2 — Thu, 27 Sep 2018 01:07 GMT
  • Updated: Wed, 15 Dec 2021 21:12 GMT