Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — All Issues

  • Acronym: DMN
  • Issues Count: 93
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN15-56 Typos in meta model DMN 1.2 DMN 1.5 Resolved closed
DMN15-44 Clarification regarding equivalence of date vs date and time DMN 1.2 DMN 1.5 Resolved closed
DMN15-42 data equivalence with date and time DMN 1.2 DMN 1.5 Duplicate or Merged closed
DMN15-36 No way to represent a black-box or incompletely defined Decision Service DMN 1.2 DMN 1.5 Deferred closed
DMN15-45 Clean up example xml files DMN 1.2b1 DMN 1.5 Closed; No Change closed
DMN15-39 inconsistent date comparisons make unavoidavle paradoxes DMN 1.2 DMN 1.5 Deferred closed
DMN15-52 Inconsistency DMNv1.2 dropping [a]=a and get entries example DMN 1.2b1 DMN 1.5 Deferred closed
DMN15-38 DMN Models need a default timezone DMN 1.2 DMN 1.5 Deferred closed
DMN15-40 Situational Data Model and Notation (SDMN) DMN 1.2b1 DMN 1.5 Deferred closed
DMN15-37 Fix interchange of links to objects in BPMN/BMM DMN 1.2 DMN 1.5 Deferred closed
DMN15-48 Lack of visual notation for processing of / iteration over lists in FEEL DMN 1.2 DMN 1.5 Deferred closed
DMN15-49 Support for recursive calls by Business Knowledge Models DMN 1.2 DMN 1.5 Deferred closed
DMN15-51 properly define type(e) DMN 1.2 DMN 1.5 Deferred closed
DMN15-41 Knowledge Package Model and Notation (KPMN) DMN 1.2b1 DMN 1.5 Deferred closed
DMN15-50 Clarification on DMN case sensitivity of timezones DMN 1.2 DMN 1.5 Deferred closed
DMN15-53 "instance of" not possible with some built-in functions DMN 1.2b1 DMN 1.5 Deferred closed
DMN15-43 Temporal precision inconsistencies DMN 1.2b1 DMN 1.5 Deferred closed
DMN15-46 Provide better spec and examples for Equality, Identity, and Equivalence DMN 1.2b1 DMN 1.5 Deferred closed
DMN15-47 Friendlier handling of null values DMN 1.2b1 DMN 1.5 Deferred closed
DMN16-45 Inconsistency DMNv1.2 dropping [a]=a and get entries example DMN 1.2b1 open
DMN16-44 properly define type(e) DMN 1.2 open
DMN16-43 Clarification on DMN case sensitivity of timezones DMN 1.2 open
DMN16-46 "instance of" not possible with some built-in functions DMN 1.2b1 open
DMN16-42 Support for recursive calls by Business Knowledge Models DMN 1.2 open
DMN16-39 Provide better spec and examples for Equality, Identity, and Equivalence DMN 1.2b1 open
DMN16-40 Friendlier handling of null values DMN 1.2b1 open
DMN16-41 Lack of visual notation for processing of / iteration over lists in FEEL DMN 1.2 open
DMN16-37 Knowledge Package Model and Notation (KPMN) DMN 1.2b1 open
DMN16-38 Temporal precision inconsistencies DMN 1.2b1 open
DMN16-34 DMN Models need a default timezone DMN 1.2 open
DMN16-33 Fix interchange of links to objects in BPMN/BMM DMN 1.2 open
DMN16-36 Situational Data Model and Notation (SDMN) DMN 1.2b1 open
DMN16-35 inconsistent date comparisons make unavoidavle paradoxes DMN 1.2 open
DMN14-55 Incorrect example in Table 40: Examples of equivalence and conformance relations DMN 1.2 DMN 1.4 Resolved closed
DMN14-74 DMNv1.3 fix DMN example files issues DMN 1.2 DMN 1.4 Resolved closed
DMN14-61 Support for function types in metamodel and XSD DMN 1.2b1 DMN 1.4 Closed; No Change closed
DMN14-56 Spec does not clarify meaning of hex value DMN 1.2b1 DMN 1.4 Closed; No Change closed
DMN14-45 Convenience documents DMN 1.2b1 DMN 1.4 Closed; No Change closed
DMN14-52 Clarify method signature syntax for Java Function Definition DMN 1.2 DMN 1.4 Closed; No Change closed
DMN14-46 DMN 1.3 Metamodel DMN 1.2b1 DMN 1.4 Closed; No Change closed
DMN14-73 Wrong example for 10.6.1 Context Figure 10.18: Example context DMN 1.2 DMN 1.4 Resolved closed
DMN14-72 Wrong example for substring() builtin funciton DMN 1.2 DMN 1.4 Resolved closed
DMN14-75 Wrong example snippet in 10.3.2.9.4.1 Examples DMN 1.2 DMN 1.4 Resolved closed
DMN14-48 inconsistent date comparisons make unavoidavle paradoxes DMN 1.2 DMN 1.4 Deferred closed
DMN14-44 Fix interchange of links to objects in BPMN/BMM DMN 1.2 DMN 1.4 Deferred closed
DMN14-43 Now way to represent a black-box or incompletely defined Decision Service DMN 1.2 DMN 1.4 Deferred closed
DMN14-53 Temporal precision inconsistencies DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-54 Clarification regarding equivalence of date vs date and time DMN 1.2 DMN 1.4 Deferred closed
DMN14-62 Support for recursive calls by Business Knowledge Models DMN 1.2 DMN 1.4 Deferred closed
DMN14-63 Clarification on DMN case sensitivity of timezones DMN 1.2 DMN 1.4 Deferred closed
DMN14-60 Lack of visual notation for processing of / iteration over lists in FEEL DMN 1.2 DMN 1.4 Deferred closed
DMN14-66 "instance of" not possible with some built-in functions DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-57 Clean up example xml files DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-58 Provide better spec and examples for Equality, Identity, and Equivalence DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-51 data equivalence with date and time DMN 1.2 DMN 1.4 Deferred closed
DMN14-59 Friendlier handling of null values DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-71 Typos in the XMI files DMN 1.2 DMN 1.4 Deferred closed
DMN14-47 DMN Models need a default timezone DMN 1.2 DMN 1.4 Deferred closed
DMN14-49 Situational Data Model and Notation (SDMN) DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-50 Knowledge Package Model and Notation (KPMN) DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-65 Inconsistency DMNv1.2 dropping [a]=a and get entries example DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-64 properly define type(e) DMN 1.2 DMN 1.4 Deferred closed
DMN13-127 Incorrect claim about the Unicode character range and EBNF character expressions DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-143 Should add a new unicode escape syntax DMN 1.2b1 DMN 1.3 Duplicate or Merged closed
DMN13-109 Ambiguty for the source/target of DMNEdge when there is multiple depictions of its source and target DMN 1.2 DMN 1.3 Resolved closed
DMN13-244 Incorrect figure 6.10 DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-181 PMML invocation output value in the case of single prediction DMN 1.2 DMN 1.3 Resolved closed
DMN13-175 A signature for the time() built in function is missing from table 66 DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-125 Disambiguation for Modulo / Remainder function DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-139 Add built-in functions to support Allen's interval algebra DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-140 Incorrect grammar rule references and missing UnaryTests section in MM DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-141 Allegedly bug in Table Table 40 Examples of equivalence and conformance relations DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-132 type conversions are too spread out in Ch 10 DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-111 Remove the limitation that the second operand of exponentiation be an integer DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-156 Decision Requirement Metadata Examples DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-163 Decision Service output value in the case of single output Decision DMN 1.2 DMN 1.3 Resolved closed
DMN13-188 New FEEL URI needed DMN 1.2 DMN 1.3 Resolved closed
DMN13-178 Functions resolution DMN 1.2 DMN 1.3 Resolved closed
DMN13-242 Update the copyright section DMN 1.2 DMN 1.3 Resolved closed
DMN13-195 New acknowledgments needed DMN 1.2 DMN 1.3 Resolved closed
DMN13-191 New XML Namespace needed DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-124 Disambiguation for Modulo / Remainder function DMN 1.2b1 DMN 1.3 Duplicate or Merged closed
DMN13-144 instance of clarification DMN 1.2 DMN 1.3 Resolved closed
DMN13-131 Make explicit reference to sample standard deviation DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-133 Wrong example in chapter "10.3.1.5" DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-106 Remove reference to SQL and PMML three value logic to eliminate misinterpretation DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-126 Built-in functions only described in chapter "10.3.2.6 Context", and not described in the "10.3.4 Built-in functions" DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-122 "get value" and "get entries" function not in built-in functions list DMN 1.2b1 DMN 1.3 Duplicate or Merged closed
DMN13-121 example shows literal inline function definition whereas grammar says function definitions only in boxed expressions. DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-120 Minor typos in the FEEL grammar DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-98 Example: Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses values inverted DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-91 Fix interchange of links to objects in BPMN/BMM DMN 1.2 DMN 1.3 Deferred closed
DMN13-90 Allow representation of black-box Decision Service DMN 1.2 DMN 1.3 Deferred closed

Issues Descriptions

Typos in meta model


Clarification regarding equivalence of date vs date and time

  • Key: DMN15-44
  • Status: closed  
  • Source: Goldman Sachs ( Dr. 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
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Clarify equivalence between date and date and time instances

    Clarify equivalence between date and date and time instances

  • Updated: Fri, 30 Jun 2023 20:31 GMT

data equivalence with date and time

  • Key: DMN15-42
  • Status: closed  
  • Source: Goldman Sachs ( Dr. 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
  • Disposition: Duplicate or Merged — DMN 1.5
  • Disposition Summary:

    Duplicate of DMN15-44

    Duplicate of DMN15-44

  • Updated: Fri, 30 Jun 2023 20:31 GMT

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


Clean up example xml files

  • Key: DMN15-45
  • Status: closed  
  • 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
  • Disposition: Closed; No Change — DMN 1.5
  • Disposition Summary:

    The examples don't contain extensions

    The issue seems to be fixed

  • Updated: Fri, 30 Jun 2023 20:31 GMT

inconsistent date comparisons make unavoidavle paradoxes

  • Key: DMN15-39
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT

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

  • Key: DMN15-52
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT

DMN Models need a default timezone

  • Key: DMN15-38
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT

Situational Data Model and Notation (SDMN)

  • Key: DMN15-40
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. 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
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT
  • Attachments:

Fix interchange of links to objects in BPMN/BMM

  • Key: DMN15-37
  • Status: closed  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • 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
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT

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

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

    split off from DMN13-12

  • Reported: DMN 1.2 — Tue, 20 Nov 2018 17:55 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT

Support for recursive calls by Business Knowledge Models

  • Key: DMN15-49
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT

properly define type(e)

  • Key: DMN15-51
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT

Knowledge Package Model and Notation (KPMN)

  • Key: DMN15-41
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. 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
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT
  • Attachments:

Clarification on DMN case sensitivity of timezones

  • Key: DMN15-50
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT

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

  • Key: DMN15-53
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT

Temporal precision inconsistencies

  • Key: DMN15-43
  • Status: closed  
  • Source: Trisotech ( Mr. 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
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT

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

  • Key: DMN15-46
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT

Friendlier handling of null values

  • Key: DMN15-47
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

  • Updated: Fri, 30 Jun 2023 20:31 GMT

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

  • Key: DMN16-45
  • 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: Thu, 6 Apr 2023 14:59 GMT

properly define type(e)

  • Key: DMN16-44
  • 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: Thu, 6 Apr 2023 14:59 GMT

Clarification on DMN case sensitivity of timezones

  • Key: DMN16-43
  • 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: Thu, 6 Apr 2023 14:59 GMT

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

  • Key: DMN16-46
  • 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: Thu, 6 Apr 2023 14:59 GMT

Support for recursive calls by Business Knowledge Models

  • Key: DMN16-42
  • 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: Thu, 6 Apr 2023 14:59 GMT

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

  • Key: DMN16-39
  • 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: Thu, 6 Apr 2023 14:59 GMT

Friendlier handling of null values

  • Key: DMN16-40
  • 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: Thu, 6 Apr 2023 14:59 GMT

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

  • Key: DMN16-41
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    split off from DMN13-12

  • Reported: DMN 1.2 — Tue, 20 Nov 2018 17:55 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Knowledge Package Model and Notation (KPMN)

  • Key: DMN16-37
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. 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: Thu, 6 Apr 2023 14:59 GMT
  • Attachments:

Temporal precision inconsistencies

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

DMN Models need a default timezone

  • Key: DMN16-34
  • 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: Thu, 6 Apr 2023 14:59 GMT

Fix interchange of links to objects in BPMN/BMM

  • Key: DMN16-33
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • 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: Thu, 6 Apr 2023 14:59 GMT

Situational Data Model and Notation (SDMN)

  • Key: DMN16-36
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. 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: Thu, 6 Apr 2023 14:59 GMT
  • Attachments:

inconsistent date comparisons make unavoidavle paradoxes

  • Key: DMN16-35
  • 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: Thu, 6 Apr 2023 14:59 GMT

Incorrect example in Table 40: Examples of equivalence and conformance relations

  • Key: DMN14-55
  • Status: closed  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    Table 40 contains the folowing row:

    date date and time False True

    Based on the definition given in a previous section it should be

    date date and time False False
  • Reported: DMN 1.2 — Sun, 2 Jun 2019 12:33 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Fix example about conformance of date and date and time

    Fix example and remove empty row

  • Updated: Thu, 31 Mar 2022 19:30 GMT

DMNv1.3 fix DMN example files issues

  • Key: DMN14-74
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The DMN example files provided with DMNv1.3 have a few problems which need to be corrected, one issue specifically is preventing from being a correct DMN format, possibly inadvertently a result of the tinkering which happened before final release:

    • Chapter11 second example files are missing default xlmns
    • Loan Info.dmn: typo in Monthly HOA/Condo Fee
    • Loan Info.dmn: typo in Quallifying Monthly Payment
    • Recommended Loan Products.dmn: itemDefinition of "tLoanProduct" component Product Name allowedValues is not consistent with itemDefinition "tProductName"
    • Chapter11 first example typo in "MartitalStatus"

    Proposal

    The fix will require an update in the Figure 11.16 in the DMN specification document, but mostly a code change in the DMN model files.

    • Figure 11.16: Application risk score decision logic will need to be updated. An updated file will be attached at proposal creation time
    • A code change GitHub pull request will be raised to correct for the above, as below patch. Myself (Matteo Mortari) will raise it directly against the required GitHub repo.
    diff --git a/examples/Chapter 11 Example 1 Originations/Chapter 11 Example.dmn b/examples/Chapter 11 Example 1 Originations/Chapter 11 Example.dmn
    index deaf94a..f5a2b76 100644
    --- a/examples/Chapter 11 Example 1 Originations/Chapter 11 Example.dmn	
    +++ b/examples/Chapter 11 Example 1 Originations/Chapter 11 Example.dmn	
    @@ -36,7 +36,7 @@
             <semantic:itemComponent isCollection="false" name="Age" id="_df3aab6f-1610-41fa-a407-09678a89d6da">
                 <semantic:typeRef>number</semantic:typeRef>
             </semantic:itemComponent>
    -        <semantic:itemComponent isCollection="false" name="MartitalStatus" id="_d39ad810-7781-4ffb-9644-de51d1ca7f7a">
    +        <semantic:itemComponent isCollection="false" name="MaritalStatus" id="_d39ad810-7781-4ffb-9644-de51d1ca7f7a">
                 <semantic:typeRef>string</semantic:typeRef>
                 <semantic:allowedValues triso:constraintsType="enumeration">
                     <semantic:text>"S","M"</semantic:text>
    @@ -1454,7 +1454,7 @@ else false</semantic:text>
                 <semantic:binding>
                     <semantic:parameter id="_259966f2-bf40-4139-b587-6c9b989f1aa0" name="Marital Status"/>
                     <semantic:literalExpression id="_610941db-8c4e-483c-9d75-789b3d5c2333">
    -                    <semantic:text>Applicant data.MartitalStatus</semantic:text>
    +                    <semantic:text>Applicant data.MaritalStatus</semantic:text>
                     </semantic:literalExpression>
                 </semantic:binding>
                 <semantic:binding>
    diff --git a/examples/Chapter 11 Example 2 Ranked Loan Products/Loan info.dmn b/examples/Chapter 11 Example 2 Ranked Loan Products/Loan info.dmn
    index 64ae127..e9bd0c4 100644
    --- a/examples/Chapter 11 Example 2 Ranked Loan Products/Loan info.dmn	
    +++ b/examples/Chapter 11 Example 2 Ranked Loan Products/Loan info.dmn	
    @@ -1,5 +1,5 @@
     <?xml version="1.0" encoding="UTF-8"?>
    -<semantic:definitions xmlns:semantic="https://www.omg.org/spec/DMN/20191111/MODEL/" id="_5c8b9296-96cf-4898-bba5-3a2d21d34eed" name="Loan info" namespace="http://www.trisotech.com/definitions/_5c8b9296-96cf-4898-bba5-3a2d21d34eed" exporter="DMN Modeler" exporterVersion="6.2.2.3">
    +<semantic:definitions id="_5c8b9296-96cf-4898-bba5-3a2d21d34eed" name="Loan info" namespace="http://www.trisotech.com/definitions/_5c8b9296-96cf-4898-bba5-3a2d21d34eed" exporter="DMN Modeler" exporterVersion="6.2.2.3" xmlns:semantic="https://www.omg.org/spec/DMN/20191111/MODEL/" xmlns="http://www.trisotech.com/definitions/_5c8b9296-96cf-4898-bba5-3a2d21d34eed">
     	<semantic:itemDefinition name="tBorrower" label="tBorrower">
     		<semantic:itemComponent id="_b7dcc14d-510d-4628-a510-ca774208e501" name="Full Name">
     			<semantic:typeRef>string</semantic:typeRef>
    @@ -125,7 +125,7 @@
     		<semantic:itemComponent id="_aa55fa1a-3e82-4439-b422-21921c6a64b0" name="Monthly Insurance Payment">
     			<semantic:typeRef>number</semantic:typeRef>
     		</semantic:itemComponent>
    -		<semantic:itemComponent id="_77f3b202-47ba-432b-9ada-e81700db445f" name="Monthly HOA/Condo Fee">
    +		<semantic:itemComponent id="_77f3b202-47ba-432b-9ada-e81700db445f" name="Monthly HOA Condo Fee">
     			<semantic:typeRef>number</semantic:typeRef>
     		</semantic:itemComponent>
     	</semantic:itemDefinition>
    @@ -204,7 +204,7 @@
     		<semantic:itemComponent id="_cd96db58-d312-41dc-a3e4-6fa93766b49d" name="Initial Monthly Payment" isCollection="false">
     			<semantic:typeRef>number</semantic:typeRef>
     		</semantic:itemComponent>
    -		<semantic:itemComponent id="_c05792fd-417f-4662-b6b8-7cf708c26976" name="Quallifying Monthly Payment" isCollection="false">
    +		<semantic:itemComponent id="_c05792fd-417f-4662-b6b8-7cf708c26976" name="Qualifying Monthly Payment" isCollection="false">
     			<semantic:typeRef>number</semantic:typeRef>
     		</semantic:itemComponent>
     		<semantic:itemComponent id="_30babadc-60b5-4879-b233-410b43349ef4" name="Points Amount">
    diff --git a/examples/Chapter 11 Example 2 Ranked Loan Products/Recommended Loan Products.dmn b/examples/Chapter 11 Example 2 Ranked Loan Products/Recommended Loan Products.dmn
    index 3c1983e..8a6e355 100644
    --- a/examples/Chapter 11 Example 2 Ranked Loan Products/Recommended Loan Products.dmn	
    +++ b/examples/Chapter 11 Example 2 Ranked Loan Products/Recommended Loan Products.dmn	
    @@ -1,5 +1,5 @@
     <?xml version="1.0" encoding="UTF-8"?>
    -<semantic:definitions xmlns:semantic="https://www.omg.org/spec/DMN/20191111/MODEL/" xmlns:tc="http://www.omg.org/spec/DMN/20160719/testcase" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   id="_736fa164-03d8-429f-8318-4913a548c3a6" name="Recommended Loan Products" namespace="http://www.trisotech.com/definitions/_736fa164-03d8-429f-8318-4913a548c3a6" exporter="DMN Modeler" exporterVersion="6.2.3" xmlns:include1="http://www.trisotech.com/definitions/_5c8b9296-96cf-4898-bba5-3a2d21d34eed">
    +<semantic:definitions id="_736fa164-03d8-429f-8318-4913a548c3a6" name="Recommended Loan Products" namespace="http://www.trisotech.com/definitions/_736fa164-03d8-429f-8318-4913a548c3a6" exporter="DMN Modeler" exporterVersion="6.2.3" xmlns:semantic="https://www.omg.org/spec/DMN/20191111/MODEL/" xmlns:tc="http://www.omg.org/spec/DMN/20160719/testcase" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:include1="http://www.trisotech.com/definitions/_5c8b9296-96cf-4898-bba5-3a2d21d34eed" xmlns="http://www.trisotech.com/definitions/_736fa164-03d8-429f-8318-4913a548c3a6">
     	<semantic:import namespace="http://www.trisotech.com/definitions/_5c8b9296-96cf-4898-bba5-3a2d21d34eed" name="Services" importType="https://www.omg.org/spec/DMN/20191111/MODEL/"/>
     	<semantic:itemDefinition name="tBorrower" label="tBorrower">
     		<semantic:itemComponent id="_b7dcc14d-510d-4628-a510-ca774208e501" name="Full Name">
    @@ -152,7 +152,7 @@
     		<semantic:itemComponent id="_68f6a641-5e2d-4b1b-9f2b-41f933976dee" name="Product Name" isCollection="false">
     			<semantic:typeRef>tProductName</semantic:typeRef>
     			<semantic:allowedValues>
    -				<semantic:text>"Fixed30-NoPointsOrFees","Fixed30-Standard","Fixed30-LowestRate","Fixed15-NoPointsOrFees","Fixed15-Standard"</semantic:text>
    +				<semantic:text>"Fixed30-NoPoints","Fixed30-Standard","Fixed30-LowestRate","Fixed15-NoPoints","Fixed15-Standard","ARM5/1-NoPoints","ARM5/1-Standard"</semantic:text>
     			</semantic:allowedValues>
     		</semantic:itemComponent>
     		<semantic:itemComponent id="_39c5300a-339c-4bde-8dfc-17e5d3f6f535" name="Type" isCollection="false">
    
  • Reported: DMN 1.2 — Tue, 7 Jan 2020 10:30 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Fix typos in example figure and XML files

    The fix will require an update in the Figure 11.16 in the DMN specification document, but mostly a code change in the DMN model files.

  • Updated: Thu, 31 Mar 2022 19:30 GMT
  • Attachments:

Support for function types in metamodel and XSD

  • Key: DMN14-61
  • Status: closed  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    The DMN metamodel & the XSD schema do not support definition of function type. For example, a construction as the one below is not supported:

    <functionDefinition name='add_type' returnType='number'>
             <parameters>
                    <param name='a' typeRef='number'>
                    <param name='b' typeRef='number'>
            </parameters>
    </functionDefinition>
    
  • Reported: DMN 1.2b1 — Fri, 22 Feb 2019 11:57 GMT
  • Disposition: Closed; No Change — DMN 1.4
  • Disposition Summary:

    Duplicates 13-7

    Close - already fixed

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Spec does not clarify meaning of hex value

  • Key: DMN14-56
  • Status: closed  
  • Source: fujitsu america ( keith swenson)
  • Summary:

    Rule #66 on page 111 says that a character in a string can be expressed as:

    "\u", hex digit, hex digit, hex digit, hex digit

    For example "\uD83D"

    That is, exactly four hex digits. I believe the intent is that FEEL only allows exactly four digits, and does not allow the kinds of expressions that we see in the EBNF.

    What is never specified is the exact meaning of that hex value. There are two possibilities:

    (a) Is that value a Unicode code point? In this case it is easy, the hex value is the code point value, however because you are limited to 64K characters, and not the 1.1M character range normally considered, and not even the values that are mentioned in the spec as having significance.

    (b) Or is it a UTF-16 code value? UTF-16 has encoding rules about values in the surrogate character range. In UTF-16 a high-surrogate-code value must be followed by a low-surrogate-code value or else the sequence of values is invalid and undefined. Using surrogate characters you can address the entire 1.1million characters but the user is required to understand about surrogate pairs.

    The spec never mentions that UTF-16 encoding is required! It always uses "Unicode" and talks about "characters" and "code points". It does not mention anything about surrogate pairs. It never says that these values a "just like Java" or any other UTF-16 implementation.

    Page 124 says that the FEEL string value is the same as java.lang.String. Should we infer from that that internal representations must be in UTF-16? however it also says that it is equivalent to an XML string (which is NOT constrained to UTF-16) and PMML string which I looked up and seems to be based on XML. XML allows characters to be expressed as &#nnnn ; That is an ampersand, a hash, a decimal number, terminated by a semicolon. In this case, the decimal value is the actual code point, and not the UTF-16 value. So page 124 does not say unambiguously that Java defines the string values that can be used.

    Unicode is mentioned only in three places: on page 108 (about EBNF character ranges), page 111 that tokens are a sequence of unicode characters, page 114 in an example.

    While it might be nice to be a "code point", the syntax clearly limits you to four digits leaving you no way to express larger code point values. If it was a code point you would be limited to only specifying 64,000 character (minus several thousand code points that not allowed for various reasons).

    The easiest repair is to state clearly that the \u notation assumes that UTF-16 is being used to encode the strings, and that UTF-16 rules must be used when specifying hex values for characters.

    I believe most implementations to date have assumed that these are UTF-16 code unit values. That is what Java does. That is what JavaScript does. I don't know of any environments that do anything different for this kind of expression.

  • Reported: DMN 1.2b1 — Fri, 8 Feb 2019 18:33 GMT
  • Disposition: Closed; No Change — DMN 1.4
  • Disposition Summary:

    Hex values are already properly defined in DMN 1.3

    The issue has been discussed and fixed in DMN 1.3 - ballot #10
    https://issues.omg.org/browse/DMN13/fixforversion/14682?selectedTab=org.omg.jira.task-forces%3Ataskforce-ballot-panel

    https://issues.omg.org/browse/DMN13-127
    https://issues.omg.org/browse/DMN13-143

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Convenience documents


Clarify method signature syntax for Java Function Definition

  • Key: DMN14-52
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    For example, java.lang.Object[]
    Instead of
    [Ljava.lang.Object;
    Also, what if some of the argument or result types have no defined FEEL mapping. Need some kind of recursive definition.

  • Reported: DMN 1.2 — Mon, 20 May 2019 15:12 GMT
  • Disposition: Closed; No Change — DMN 1.4
  • Disposition Summary:

    Out of date. Issue already addressed in DMN 1.3.

    This ticket is out of date. Problem was already addressed in DMN 1.3.

  • Updated: Thu, 31 Mar 2022 19:30 GMT

DMN 1.3 Metamodel


Wrong example for 10.6.1 Context Figure 10.18: Example context

  • Key: DMN14-73
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    This is taken from the DMN spec :

    (amount *rate/12) / (1 – (1 + rate/12)**-term)
    

    however this would fail to parse correctly as the first subtraction sign is an "en-dash" (0x2013) and not a minus/hyphen sign (0x2D)

    (amount *rate/12) / (1 – (1 + rate/12)**-term)
                           ^ 
    (amount *rate/12) / (1 - (1 + rate/12)**-term)
    

    this "en-dash" can be confused easily, especially depending on the font used, but as an end result cannot be copy-pasted from the PDF/Word of the DMN specification into an editor, and in essence is a wrong FEEL expression.

    Proposal

    with reference to DMNv1.3 dtc/19-12-06 in chapter Wrong example for 10.6.1 Context Figure 10.18: Example context page 177 replace:

    (amount rate/12) / (1 – (1 + rate/12)*-term)

    with

    (amount rate/12) / (1 - (1 + rate/12)*-term)

    (for the editor, please be aware MS Word might be tempted to replace the minus sign in "1 - ( 1 +" with an en-dash character, but this being FEEL code expression must be a minus sign)

  • Reported: DMN 1.2 — Tue, 7 Jan 2020 09:47 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Correct Context Figure 10.6.1

    with reference to DMNv1.3 dtc/19-12-06 in chapter Wrong example for 10.6.1 Context Figure 10.18: Example context page 177 replace:

    (amount * rate/12) / (1 – (1 + rate/12)**-term)

    with

    (amount * rate/12) / (1 - (1 + rate/12)**-term)

    (for the editor, please be aware MS Word might be tempted to replace the minus sign in "1 - ( 1 +" with an en-dash character, but this being FEEL code expression must be a minus sign)

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Wrong example for substring() builtin funciton

  • Key: DMN14-72
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    the example is wrong and needs a fix as it compares to "ab", besides the incorrect representation of the emoji for the horse in the PDF/Word document; proposed below

    Proposal

    with reference to DMNv1.3 dtc/19-12-06 in chapter 10.3.4.3 String functions
    Table 74: Semantics of string functions page 158 replace:

    substring("\U01F40Eab ", 2) = "ab" where "\U01F40Eab "

    with

    substring("\U01F40Eab", 2) = "ab" where "\U01F40Eab"

    (the characters inside double-quote of the example should not end with a trailing space)

    Also the "ὀ" character in the PDF/Word document is actually meant to be the emoji for the horse. JIRA does not allow to place the horse emoji in this text fields, so the emoji can be copy-pasted from here: https://emojipedia.org/horse/ inside the DMN specification new document.

  • Reported: DMN 1.2 — Tue, 7 Jan 2020 09:18 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Remove space from substring() example

    with reference to DMNv1.3 dtc/19-12-06 in chapter 10.3.4.3 String functions
    Table 74: Semantics of string functions page 158 replace:

    substring("\U01F40Eab ", 2) = "ab" where "\U01F40Eab "

    with

    substring("\U01F40Eab", 2) = "ab" where "\U01F40Eab"

    (the characters inside double-quote of the example should not end with a trailing space)

    Also the "ὀ" character in the PDF/Word document is actually meant to be the emoji for the horse. JIRA does not allow to place the horse emoji in this text fields, so the emoji can be copy-pasted from here: https://emojipedia.org/horse/ inside the DMN specification new document.

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Wrong example snippet in 10.3.2.9.4.1 Examples

  • Key: DMN14-75
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    this is a typo fix.
    "typeRef" from XSD is meant with capital R.

    Proposal

    with reference to DMNv1.3 dtc/19-12-06 in chapter 10.3.2.9.4.1 Examples page 135 replace:

    <variable name="decision_003" typeref="number"/>
    

    with

    <variable name="decision_003" typeRef="number"/>
    
  • Reported: DMN 1.2 — Tue, 7 Jan 2020 08:39 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Fix typo in XML snippet

    Replace typeref with typeRef

  • Updated: Thu, 31 Mar 2022 19:30 GMT

inconsistent date comparisons make unavoidavle paradoxes

  • Key: DMN14-48
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Fix interchange of links to objects in BPMN/BMM

  • Key: DMN14-44
  • Status: closed  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

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

  • Key: DMN14-43
  • Status: closed  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • Summary:

    As DMN gets used to produce publicly available decision services we will need some way to represent a decision service that the modeler cannot see into. They know its a side-effect free, stateless decision service and know its signature so they can add a decision to their own model that is implemented by it but they don't know what decisions, BKMs, knowledge sources etc were used to produce it. There is currently no way to do this - a decision service can be shown collapsed but only if the model "knows" what the expanded version looks like. It feels like it would be useful to do so.

  • Reported: DMN 1.2 — Thu, 27 Sep 2018 01:04 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Temporal precision inconsistencies

  • Key: DMN14-53
  • Status: closed  
  • Source: Trisotech ( Mr. 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Clarification regarding equivalence of date vs date and time

  • Key: DMN14-54
  • Status: closed  
  • Source: Goldman Sachs ( Dr. 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT
  • Attachments:

Support for recursive calls by Business Knowledge Models

  • Key: DMN14-62
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Clarification on DMN case sensitivity of timezones

  • Key: DMN14-63
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

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

  • Key: DMN14-60
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    split off from DMN13-12

  • Reported: DMN 1.2 — Tue, 20 Nov 2018 17:55 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

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

  • Key: DMN14-66
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Clean up example xml files

  • Key: DMN14-57
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

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

  • Key: DMN14-58
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

data equivalence with date and time

  • Key: DMN14-51
  • Status: closed  
  • Source: Goldman Sachs ( Dr. 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Friendlier handling of null values

  • Key: DMN14-59
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Typos in the XMI files

  • Key: DMN14-71
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

DMN Models need a default timezone

  • Key: DMN14-47
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Situational Data Model and Notation (SDMN)

  • Key: DMN14-49
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT
  • Attachments:

Knowledge Package Model and Notation (KPMN)

  • Key: DMN14-50
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT
  • Attachments:

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

  • Key: DMN14-65
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

properly define type(e)

  • Key: DMN14-64
  • Status: closed  
  • 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
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Incorrect claim about the Unicode character range and EBNF character expressions

  • Key: DMN13-127
  • Status: closed  
  • Source: Fujitsu ( Keith Swenson)
  • Summary:

    This is a trivial typo, and the fix is easy.

    Lower on page 108 it says: "the character range that includes all Unicode characters is [\u0-\u10FFF]." This range specified has less than 70,000 characters.

    I don't think your intent is to limit implementations to 70K characters and in fact in places (e.g. grammar rule #30) character values larger than this are mentioned.

    "all Unicode characters" is actually the entire range of 32-bit values (minus some control codes: hundreds of millions of characters, most of which are undefined). Instead you are defining a SUBSET of this that will be allowed.

    Second, the most common implementation of Unicode uses UTF-16, and as a consequences OF THIS ENCODING, the range of representable characters is 0 through 10FFFF. Note that is six hex digits, there are four F digits. There are over a million characters in this range.

    (1) Nowhere in the spec does is say you are limiting characters to the UTF-16 range. This should be explicitly stated if that is your intent.

    (2) The phrase on page 108 should be changed to; "DMN allows the use of unicode characters in the range of [\u0-\u10FFFF]."

    (3) The specification of EBNF character expression should be changed to allow 6 hex digits, currently it says you can only use five digits max.

  • Reported: DMN 1.2b1 — Mon, 31 Dec 2018 17:00 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Allow 4 or 6 hexadecimal digits for unicode code point

    See attached word doc

  • Updated: Tue, 26 Jan 2021 20:17 GMT
  • Attachments:
    • DMN13-127-v7.docx 19 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Should add a new unicode escape syntax

  • Key: DMN13-143
  • Status: closed  
  • Source: fujitsu america ( keith swenson)
  • Summary:

    On page 110, rule #66 gives these escape sequences:

    string escape sequence = "\'" | "\"" | "
    " | "\n" | "\r" | "\t" | "\u", hex digit, hex digit, hex digit, hex digit;

    Using the hex character value notation "\uD41A" you can only four hex digits which is not enough to specify the entire Unicode character range. The spec specifically mentions that much higher values are allowed, and there should be a standard way to specify them without having to use the cryptic surrogate character pairs.

    This suggestion is to add braces to allow variable length hex values in exactly the way that JavaScript allows:

    "\u

    {1F40E}

    "

    This is character 128,014 in the unicode set. To specify this character using surrogate pairs you would have to use: "\uD83D\uDC0E" which is complicated and confusing and is currently subject to discussion on whether this is valid or not within the current spec.

    "A" = "\u

    {41}

    "

    "è" = "\u

    {E8}

    "

    "査" = "\u

    {67FB}

    "

    "" = "\u

    {1F407}

    " (Jira seems to crash if I inlcude this character)

    It is nice because you actually use the Unicode code point value, and because of the braces you can specify a variable number of hex digits so the entire Unicode set can be easily addressed. The precidence for this syntax is set by JavaScript (

    https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

    See page 218 where it defines this (slightly translated):

    UnicodeEscapeSequence ::
    \u Hex4Digits
    \u

    { CodePoint }

    This will not conflict with any existing implementation since the opening brace was not allowed in earlier implementations. The new allowed syntax could be used in DMN 1.3 and higher.

  • Reported: DMN 1.2b1 — Fri, 8 Feb 2019 19:06 GMT
  • Disposition: Duplicate or Merged — DMN 1.3
  • Disposition Summary:

    Addressed by resolution of DMN-127

    DMN-127 adds \U, 6*hex digit to address this issue as well

  • Updated: Tue, 26 Jan 2021 20:17 GMT

Ambiguty for the source/target of DMNEdge when there is multiple depictions of its source and target

  • Key: DMN13-109
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    DMN DI allows to depict element more than once. When drawing a diagram, tools need to check graphically the way points to know to which DMNShape a DMNEdge is actually connected to.

  • Reported: DMN 1.2 — Mon, 26 Nov 2018 22:50 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add sourceElement and targetElement to DMNEdge

    Add a sourceElement and targetElement to the DMNEdge class so the actual DMNShape used as source and target can be resolved without graphical deduction.

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Incorrect figure 6.10

  • Key: DMN13-244
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    Figure 6.10 has not been updated in line with issue DMN13-140.

  • Reported: DMN 1.2b1 — Tue, 3 Dec 2019 17:14 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Correct fig 6.10 and associated text

    Replace figure 6.10 & modify para 2 of section 6.3.1 so that UnaryTests is a subclass of Expression, rather than DMNElement.

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

PMML invocation output value in the case of single prediction

  • Key: DMN13-181
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The proposal targets the case of a PMML invocation having a single output prediction(s), for the result to be simply the value result of such single prediction, instead of a context with 1 only entry, name of the single output prediction, and value of that prediction.

  • Reported: DMN 1.2 — Mon, 23 Sep 2019 14:34 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Do not wrap single values returned from PMML in context

    Executive summary

    The proposal targets the case of a PMML invocation having a single output prediction(s), for the result to be simply the value result of such single prediction, instead of a context with 1 only entry, name of the single output prediction, and value of that prediction.
    This would also align expected invocation behaviour similarly to what RTF agreed on when dealing with Decision Service, ref: https://issues.omg.org/browse/DMN13-163

    Rationale and details

    By the PMML specification, a ML predictive model can produce multiple outputs, so in general a (FEEL) Context is assumed to be returned by its invocation, containing a key-value pair of prediction name and value.

    However,
    Most PMML models have a single prediction as output.
    To get an idea, can reference examples presented on PMML website: http://dmg.org/pmml/pmml_examples/index.html

    Specifically to a well-known example, Iris dataset, Tree model: http://dmg.org/pmml/pmml_examples/KNIME_PMML_4.1_Examples/single_iris_dectree.xml
    This would imply every time a Decision invokes a BKM for the PMML prediction, something like:

    { class : "Iris-versicolor" }
    

    is returned, instead of simply getting back something like a FEEL string:

    "Iris-versicolor" 
    

    So it would make very annoying for dependent decision the need to always access the single prediction output in the key-value pair:

    result.class
    

    instead of more simply:

    result
    

    and other analogous implications.

    This proposal would align the expected behaviour to what what RTF agreed on when dealing with Decision Service, ref: https://issues.omg.org/browse/DMN13-163 for coercion of the singleton value, in the case of a single PMML output prediction.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

A signature for the time() built in function is missing from table 66

  • Key: DMN13-175
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Section 10.3.2.3.4 time of the spec already says:
    [..] If no time offset is specified, the time is interpreted as a local time of day at some location, whose relationship to UTC time is dependent on time zone rules for that location, and may vary from day to day. [..]

    But table 66 show the signature time(hour, minute, second, offset) but does not show the signature time(hour, minute, second) which forces users to write time(08, 04, 32, null) when what they would want to write is simply time(08, 04, 32)

  • Reported: DMN 1.2b1 — Thu, 29 Aug 2019 12:54 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Make offset parameter optional in built-in function time()

    In Table 66 page 145 change time(hour, minute, second, offset) for time(hour, minute, second, offset?)

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Disambiguation for Modulo / Remainder function

  • Key: DMN13-125
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The spec defines "modulo" FEEL built-in function as: "the remainder of the division of dividend by divisor"
    However, this might be subject to ambiguity in the case the Divisor or Dividend are negative, as also mentioned by Wikipedia page which list examples out of several programming languages and systems: https://en.wikipedia.org/wiki/Modulo_operation by saying that "When either a or n is negative, the naive definition breaks down and programming languages differ in how these values are defined".

    FEEL aims to be a Friendly Enough expression language, and especially thinking about DMN practitioners who might be used to Spreadsheet based systems might find misleading if the definition of the FEEL "modulo" gets bind to the Java (default) definition, the following table illustrate the difference:

    Dividend Divisor MOD() from Microsoft Excel, Google Sheets, LibreOffice Calc, Wolfram Alpha, etc. Java % or BigDecimal#remainder or other languages default
    10 4 2 2
    10 -4 -2 2
    -10 4 2 -2
    -10 -4 -2 -2

    or to other implementation languages where the definition of Modulo/Remainder is not explicit, or the default one is not consistent with Spreadsheet default one.

    It is proposed therefore to change the specification in 10.3.4.5 Numeric functions Table 70 for the FEEL "modulo" built-in function
    FROM: "Returns the remainder of the division of dividend by divisor."
    TO: "Returns the remainder of the division of dividend by divisor. In case either dividend or divisor is negative, the result has the same sign of the DIVISOR."

    This would avoid ambiguity by making a clear definition of what should be the sign in case either of the operands are negative.
    This should make this consistent with Spreadsheet based system result of "MOD()" expression, which should address being Friendly Enough for DMN practitioners and DM analyst.
    This would not make the result the same as the default of Java % operator or BigDecimal#remainder, but Java based implementation/Vendor can trivially address the result to be compliant with the spec.

  • Reported: DMN 1.2b1 — Fri, 4 Jan 2019 18:38 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Improve the specification of the modulo builtin function

    The existing specification does not restrict the arguments to integers, and does not clearly define the sign of the result.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Add built-in functions to support Allen's interval algebra

  • Key: DMN13-139
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Allen's interval algebra defines possible relations between two intervals.
    Namely:
    before
    meets
    overlaps
    finishes
    includes
    starts
    coincides
    after
    metBy
    overlappedBy
    finishedBy
    during
    finishes

    Some more info available here: https://en.wikipedia.org/wiki/Allen%27s_interval_algebra

  • Reported: DMN 1.2b1 — Wed, 6 Feb 2019 21:26 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add interval builtins, range objects in semantic domain, and compact date literals

    See attached word doc

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Incorrect grammar rule references and missing UnaryTests section in MM

  • Key: DMN13-140
  • Status: closed  
  • Source: Red Hat ( Edson Tirelli)
  • Summary:

    As discussed in the RTF call on Feb 5th, we need to fix:

    1.Refs to grammar rules at end of ch9 are incorrect (change 14 to 12 and check others)
    2. grammar rule 14 in ch10 is unused and should be removed
    3. UnaryTests UML class is missing from the spec (it is shown on one diagram not the defining occurrence
    Need to specify this MM class and point to the correct unary tests grammar rule that defines its syntax (this will be different for FEEL and SFEEL)

  • Reported: DMN 1.2b1 — Tue, 5 Feb 2019 17:53 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Fix grammar rule references and add UnaryTests MM

    Specification Text
    See revised text.

    Metamodel

    • In Figure 7.6, Change UnaryTests class to inherit from Expression rather than directly from DMNElement
    • See attached Fig7_6

    XML Schema

    • Correct tExpression to make the typeRef attribute optional (as shown in the metamodel of Fig 7.6)
    • make tUnaryTests extend tExpression instead of tDMNElement

    Backward Compatibility Argument

    • Expressions that do specify a typeRef will still be valid when the typeRef in the XSD is corrected to be optional
    • UnaryTests that do not specify a typeRef will still be valid because the typeRef is optional
  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Allegedly bug in Table Table 40 Examples of equivalence and conformance relations

  • Key: DMN13-141
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The DMNv1.2 spec reports these two lines examples:

    type1 type2 equivalent to conforms to
    type([{"id": 1,"name":"Peter", "age": 45}])
    
    type(Decision3)
    
    True True
    type(Decision4)
    
    type(Decision3)
    
    True True

    However concerning the first referenced line, type1

    type([{"id": 1,"name":"Peter", "age": 45}])
         ^
      by following the syntax used in table 39 takes the form of the type:
    
    list<context<"id": number,"name": string, "age": number>>
    

    and type2:

    type(Decision3)
    
      by following the syntax used in table 39 takes the form of the type:
    
    context<"id": number,"name": string, "age": number>
    

    So in the first referenced line it is asserted type1 is Equivalent to type2, but a list and a context are not Equivalent by the rule described in section 10.3.2.9.1 Type Equivalence

    Similarly for the second referenced line, type 1:

    type(Decision4)
    
      by following the syntax used in table 39 takes the form of the type:
    
    list<context<"id": number,"name": string, "age": number>>
    

    As for the ItemDefinition with the isCollection="true" which therefore obliges the definition that:

    IsCollection: Boolean Setting this flag to true indicates that the actual values defined by this ItemDefinition are collections of allowed values.

    So again by the section 10.3.2.9.1 Type Equivalence there are no "iff" rules explicited which would make a LIST Equivalent to a CONTEXT.

    Analogous issue for the reported values of Conformance.

    Can you kindly verify and clarify if needed, please?

  • Reported: DMN 1.2b1 — Fri, 1 Feb 2019 14:07 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Replace 2 rows in table 40

    See attached word doc

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

type conversions are too spread out in Ch 10

  • Key: DMN13-132
  • Status: closed  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    The spec does not contain a section where the type conversions are described, hence they end-up spread across the spec. For example, a particular case of invocation conversion is described in 10.3.2.5:

    Similarly, on a function f( p ) where the domain of the formal parameter p does not include lists, but on an invocation f( pa ) the
    actual parameter pa is a singleton list where the type of pa[1] belongs to the domain of p, then pa[1] should be used instead.

    Consolidating all of them in one paragraph will make the spec more readable and easier to change in the future (e.g. we want to apply conversions in other context). It will also help us to identify gaps in the spec.

    It's a natural step after adding the type relationships in DMN 1.2.

  • Reported: DMN 1.2b1 — Wed, 30 Jan 2019 16:34 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add extra paragraph to clarify type conversions

    see attached word doc

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Remove the limitation that the second operand of exponentiation be an integer

  • Key: DMN13-111
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Table 55: Semantics of exponentiation limits the second operand to be an integer. It allow any number.

  • Reported: DMN 1.2b1 — Tue, 27 Nov 2018 14:10 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Allow second operand of exponentiation to be a number

    The second operand of exponentiation should be allowed to be a number rather than limited to an integer

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Decision Requirement Metadata Examples

  • Key: DMN13-156
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Enhance the example in chapter 11 with more realistic metadata attached to the decisions, input data, knowledge sources, etc.

  • Reported: DMN 1.2b1 — Tue, 21 May 2019 00:52 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Enhance Chapter 11 example with additional standard metadata

    Enhance Chapter 11 example with additional standard metadata, as attached.

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Decision Service output value in the case of single output Decision

  • Key: DMN13-163
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Executive summary

    The proposal targets the case of a Decision Service having a single output decision(s), for the result to be simply the value result of such single decision, instead of a context with 1 only entry, name of the single output decision, and value of that decision

    Rationale and details

    with reference to figure from the spec Figure 11.7: Routing Decision Service, the use of the decision service in a literal expression would currently require to write something like:

    if Routing Decision Service( ..., ... ).Routing = "ACCEPT" then true else false
    

    please notice specify the .Routing would sound redundant and arguably some may say user-unfriendly in the scenario of a Decision Service with a single output decision.

    In the case of a Decision Service with a single output decision, we could more friendly have:

    if Routing Decision Service( ..., ... ) = "ACCEPT" then true else false
    

    In other words, the result of invoking the "Routing Decision Service" accordingly to this proposal would be:

    Routing Decision Service :  "ACCEPT"
    

    and not:

    Routing Decision Service :  { Routing : "ACCEPT" }
    

    as of today.

    Naturally when a Decision Service contains multiple output DecisionS, then is always the context, for instance taking example from DMN Spec Figure 11.6: Bureau Strategy Decision Service the result will continue to be:

    Bureau Strategy Decision Service :  { Strategy : ..., Bureau call type: ... }
    

    Proposal specification change

    With reference to document formal/19-01-05, chapter "10.4 Execution Semantics of Decision Services", page 151
    Replace the following:

    The execution semantics of S is FEEL(F): a function that when invoked with values from the FEEL semantic domain
    bound to the parameters representing input data and input decisions, returns a context consisting of all the output
    decisions' output values.

    with:

    The execution semantics of S is FEEL(F): a function that when invoked with values from the FEEL semantic domain
    bound to the parameters representing input data and input decisions, returns:

    • in the case of a single output decision(s), the single decision's output value.
    • in the case of multiple output decisions, a context consisting of all the output decisions' output values.
  • Reported: DMN 1.2 — Mon, 20 May 2019 15:30 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    clarify that single output decision service does not result in context but rather the single output value

    Executive summary

    The proposal targets the case of a Decision Service having a single output decision(s), for the result to be simply the value result of such single decision, instead of a context with 1 only entry, name of the single output decision, and value of that decision

    Rationale and details

    with reference to figure from the spec Figure 11.7: Routing Decision Service, the use of the decision service in a literal expression would currently require to write something like:

    if Routing Decision Service( ..., ... ).Routing = "ACCEPT" then true else false
    

    please notice specify the .Routing would sound redundant and arguably some may say user-unfriendly in the scenario of a Decision Service with a single output decision.

    In the case of a Decision Service with a single output decision, we could more friendly have:

    if Routing Decision Service( ..., ... ) = "ACCEPT" then true else false
    

    In other words, the result of invoking the "Routing Decision Service" accordingly to this proposal would be:

    Routing Decision Service :  "ACCEPT"
    

    and not:

    Routing Decision Service :  { Routing : "ACCEPT" }
    

    as of today.

    Naturally when a Decision Service contains multiple output DecisionS, then is always the context, for instance taking example from DMN Spec Figure 11.6: Bureau Strategy Decision Service the result will continue to be:

    Bureau Strategy Decision Service :  { Strategy : ..., Bureau call type: ... }
    
  • Updated: Mon, 30 Mar 2020 19:50 GMT

New FEEL URI needed

  • Key: DMN13-188
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    FEEL has changed in DMN 1.3. We need a way to know which version is used in a model, e.g. by using a new URI for expressionLanguage and typeLanguage.

    This is also important, in case FEEL is used outside DMN, because in that case the surrounding model doesn't have any reference to a DMN version.

  • Reported: DMN 1.2 — Tue, 8 Oct 2019 16:18 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Update FEEL URI

    Update the URI for FEEL to https://www.omg.org/spec/DMN/20191111/FEEL/ as defined in DMN13-187.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Functions resolution

  • Key: DMN13-178
  • Status: closed   Implementation work Blocked
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    FEEL supports function invocation described in rule 40, for example f(a, b, c)

    The specification doesn't describe in details how the function is resolved (name of function is bound to the function definition). For example:

    • what are the DMN / FEEL artifacts that the call can be bound to (e.g. DMN invocables visible in context)
    • how are the name clashes resolved (e.g. both a BKM and a buil-in function have the same signature)
    • how are the binding candidates built (e.g. apply all combinations of implicit conversions) and selected (e.g. exact match takes precedence)
  • Reported: DMN 1.2 — Wed, 18 Sep 2019 08:08 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Specify how functions are found in scope and argument types are checked

    See attached word doc

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Update the copyright section


New acknowledgments needed

  • Key: DMN13-195
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    The spec should keep track and acknowledge the work of all the people and companies involved.

  • Reported: DMN 1.2 — Tue, 15 Oct 2019 16:20 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Update acknowledgments section

    Update copyright list with all participating companies

  • Updated: Mon, 30 Mar 2020 19:50 GMT

New XML Namespace needed


Disambiguation for Modulo / Remainder function

  • Key: DMN13-124
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The spec defines "modulo" FEEL built-in function as: "the remainder of the division of dividend by divisor"
    However, this might be subject to ambiguity in the case the Divisor or Dividend are negative, as also mentioned by Wikipedia page which list examples out of several programming languages and systems: https://en.wikipedia.org/wiki/Modulo_operation by saying that "When either a or n is negative, the naive definition breaks down and programming languages differ in how these values are defined".

    FEEL aims to be a Friendly Enough expression language, and especially thinking about DMN practitioners who might be used to Spreadsheet based systems might find misleading if the definition of the FEEL "modulo" gets bind to the Java (default) definition, the following table illustrate the difference:

    Dividend Divisor MOD() from Microsoft Excel, Google Sheets, LibreOffice Calc, Wolfram Alpha, etc. Java % or BigDecimal#remainder or other languages default
    10 4 2 2
    10 -4 -2 2
    -10 4 2 -2
    -10 -4 -2 -2

    or to other implementation languages where the definition of Modulo/Remainder is not explicit, or the default one is not consistent with Spreadsheet default one.

    It is proposed therefore to change the specification in 10.3.4.5 Numeric functions Table 70 for the FEEL "modulo" built-in function
    FROM: "Returns the remainder of the division of dividend by divisor."
    TO: "Returns the remainder of the division of dividend by divisor. In case either dividend or divisor is negative, the result has the same sign of the dividend."

    This would avoid ambiguity by making a clear definition of what should be the sign in case either of the operands are negative.
    This should make this consistent with Spreadsheet based system result of "MOD()" expression, which should address being Friendly Enough for DMN practitioners and DM analyst.
    This would not make the result the same as the default of Java % operator or BigDecimal#remainder, but Java based implementation/Vendor can trivially address the result to be compliant with the spec.

  • Reported: DMN 1.2b1 — Fri, 4 Jan 2019 18:34 GMT
  • Disposition: Duplicate or Merged — DMN 1.3
  • Disposition Summary:

    corrected in dmn13-125

    corrected in dmn13-125

  • Updated: Mon, 30 Mar 2020 19:50 GMT

instance of clarification

  • Key: DMN13-144
  • Status: closed  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    Table 56 describes the semantics of the instance of operator.

    It does not specify the expected result if the instance of expression is incorrect. For example, there is syntactic error, the type name cannot be found (e.g. typo or missing import) or if the type expression is incorrect (e.g. list<> or context<>).

  • Reported: DMN 1.2 — Tue, 12 Feb 2019 10:40 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Clarify type lattice L and tie 'instance of' semantics to L

    see attached word doc

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Make explicit reference to sample standard deviation

  • Key: DMN13-131
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The specification in chapter "10.3.4.4 List functions" for built-in function stddev does not explicit if it's meant to be population or sample standard deviation.
    However based on the example provided "stddev( 2, 4, 7, 5 ) = 2.0816659994661" would indicate it is meant to be the sample standard deviation --which is undefined for a single 1 sample value

    In order to be explicit, it is suggested to change the table entry as:

    Name(parameters) Parameter Domain Description Example
    stddev( list )
    stddev( n 1 , ..., n n )
    list is a list of number. n 1 ... n n are numbers. Returns the
    (sample) standard deviation of the list of numbers. If the list is empty,
    returns null. If the list contains only one number item, if n is a single number returns null.
    stddev( 2, 4, 7, 5 ) =
    2.0816659994661
    stddev( [ 47 ] ) = null
    stddev( 47 ) = null
    stddev( [ ] ) = null
  • Reported: DMN 1.2b1 — Fri, 18 Jan 2019 15:30 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Clarify the semantics of the stddev() function

    See revised text.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Wrong example in chapter "10.3.1.5"

  • Key: DMN13-133
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The specification in chapter "10.3.1.5 Contexts, Lists, Qualified Names, and Context Lists"

    presents the following example:

    [{a: [{b: 1}, {b: [2.1, 2.2]}]}, {a: [{b: 3}, {b: 4}, {b: 5}]}].a.b =
    [[{b: 1}, {b: [2.1, 2.2]}], [{b: 3}, {b: 4}, {b: 5}]].b =
    [[1, [2.1, 2.1]],[ 3, 4, 5]]
    

    However line 2 is wrong since DMNv1.2 dropped the equivalence that

    a=[a]
    

    therefore line 2 is problematic:

    [[{b: 1}, {b: [2.1, 2.2]}], [{b: 3}, {b: 4}, {b: 5}]].b =
     ^ b property is not available here
    

    as at the cursor position is not a context but two items of the root list.

    It is proposed to replace the example as follows:

    [{a: {b: 1}}, {a: {b: [2.1, 2.2]}}, {a: {b: 3}}, {a: {b: 4}}, {a: {b: 5}}].a.b =
    [{b: 1}, {b: [2.1, 2.2]}, {b: 3}, {b: 4}, {b: 5}].b =
    [1, [2.1, 2.1], 3, 4, 5]
    
  • Reported: DMN 1.2b1 — Sat, 26 Jan 2019 09:34 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Fix typo in the example on chapter 10.3.1.5

    See revised text.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Remove reference to SQL and PMML three value logic to eliminate misinterpretation

  • Key: DMN13-106
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The spec says: Three-valued logic (true, false, null) based on SQL and PMML
    This statement can lead to misinterpretation (given their understanding of the SQL and/or PMML three value logic) for nothing given that we define the semantic of the FEEL three Value logic clearly below.

  • Reported: DMN 1.2b1 — Tue, 20 Nov 2018 17:12 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Remove reference to SQL and PMML three value logic

    This reference to SQL and PMML is not needed and may lead to misinterpretation. Simply remove that reference.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Built-in functions only described in chapter "10.3.2.6 Context", and not described in the "10.3.4 Built-in functions"

  • Key: DMN13-126
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    In section "10.3.2.6 Context" two built-in functions are described: get value(), get entries().
    However these functions are not summarized later in section "10.3.4 Built-in functions"

    Describing all built-in functions in latter section "10.3.4 Built-in functions" is important to agree on the function parameters name.

    Agree on the function parameters name is important for invoking function and binding parameters by name, rather than positional.

    I propose to add a new section inside "10.3.4 Built-in functions", with the following:

    10.3.4.x Context function

    Table xx defines Context functions.

    Table xx: Semantics of Context functions

    Name(parameters) Parameter Domain Description Example
    get value(m, key) context, string select the value of the entry named key from context m
    get value({key1 : "value1"}, "key1") = "value1"
    get value({key1 : "value1"}, "unexistent-key") = null
    
    get entries(m) context produces a list of key,value pairs from a context m
    get entries({key1 : "value1"}) = [ { key : "key1", value : "value1" } ]
    get entries({key1 : "value1"})[key="key1"].value = "value1"
    
  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 15:42 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add get entries() and get value() functions to the function tables in chapter 10

    See revised text.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

"get value" and "get entries" function not in built-in functions list

  • Key: DMN13-122
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The above section mentions to two context-related functions "get value" and "get entries" that are not in the built in functions list. Are they meant to be there?

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:18 GMT
  • Disposition: Duplicate or Merged — DMN 1.3
  • Disposition Summary:

    duplicate of dmn13-126

    closed as duplicate

  • Updated: Mon, 30 Mar 2020 19:50 GMT

example shows literal inline function definition whereas grammar says function definitions only in boxed expressions.

  • Key: DMN13-121
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The spec example shows a function definition inline in a literal expression using sort(). My take on the FEEL grammar spec is that a function definition can only exist inside a boxed expression, not inside a literal expression. A function definition inside a literal expression whose body has names with spaces or additional characters makes the parsing of the entire expression before execution darn hard - we'll I haven't figured it out anyways.

    In the specific case of the sort function, the type of the 'list' parameter may only be known at execution time, and thus the types of the arguments to the 'precedes' function can only be known at execution time - that is, when actually executing the sort. And to execute a sort, you need to pass it its arguments - which means a parsed function definition. If that function definition has names with spaces, then parsing can't be done until the types are known - during the sort execution. A little bit chicken an egg.

    But, if I read the spec correctly, you should not be able to have a function definition inside a literal expression. In which case, it is parsed separately to its invoking function and the above is not an issue.

    As a note, the given example and some tests in the TCK (which I am not sure should be there) involve simple params or simple names and can be parsed. But the scenario above is not covered by the TCK.

    Happy to be guided otherwise. An all advice appreciated.

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:00 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    change grammar rule 2.h. in ch 10 to use expression instead of textual expression

    see revised text

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Minor typos in the FEEL grammar

  • Key: DMN13-120
  • Status: closed  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    Typo in rule

    51. comparison =
    a.expression , ( "=" | "!=" | "<" | "<=" | ">" | ">=" ) , expression |
    b.expression , "between" , expression , "and" , expression |
    c.expression , "in" , positive unary test ;
    d.expression , "in" , " (", positive unary tests, ")" ;

    c. should have | at the end not ;

    We should replace non-terminal Boolean literal with boolean literal for consistency.

  • Reported: DMN 1.2b1 — Sat, 8 Dec 2018 19:36 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    fix minor typos in FEEL grammar rules

    see attachment

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Example: Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses values inverted

  • Key: DMN13-98
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Fig 11.28 on page 179 of formal-19-01-05 shows a screenshot of Applicant Data.
    The values of Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses are inverted, if the end result of executing the model is for decision Routing = "ACCEPT".

    In other words; currently the PDF document display as:
    Applicant Data.Monthly.Income = 10000 (ten-thousands)
    Applicant Data.Monthly.Expenses = 100000 (a-hundred-thousands)
    but actually it should be:
    Applicant Data.Monthly.Income = 100000 (a-hundred-thousands)
    Applicant Data.Monthly.Expenses = 10000 (ten-thousands)
    if the decision Routing should evaluate to "ACCEPT".

    Also, check spelling of "Stragegy" in Fig 11.30

  • Reported: DMN 1.2b1 — Wed, 10 Oct 2018 13:13 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    *Replace erroneous figures *

    Monthly.Income and Monthly.Expenses corrected in figure 11.28
    Typo corrected in figure 11.30

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Fix interchange of links to objects in BPMN/BMM

  • Key: DMN13-91
  • Status: closed  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • 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
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

    Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Allow representation of black-box Decision Service

  • Key: DMN13-90
  • Status: closed  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • Summary:

    As DMN gets used to produce publicly available decision services we will need some way to represent a decision service that the modeler cannot see into. They know its a side-effect free, stateless decision service and know its signature so they can add a decision to their own model that is implemented by it but they don't know what decisions, BKMs, knowledge sources etc were used to produce it. There is currently no way to do this - a decision service can be shown collapsed but only if the model "knows" what the expanded version looks like. It feels like it would be useful to do so.

  • Reported: DMN 1.2 — Thu, 27 Sep 2018 01:04 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

    Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

  • Updated: Mon, 30 Mar 2020 19:50 GMT