Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN14-74 DMNv1.3 fix DMN example files issues DMN 1.2 open
DMN14-73 Wrong example for 10.6.1 Context Figure 10.18: Example context DMN 1.2 open
DMN14-72 Wrong example for substring() builtin funciton DMN 1.2 open
DMN14-75 Wrong example snippet in 10.3.2.9.4.1 Examples DMN 1.2 open
DMN14-71 Typos in the XMI files DMN 1.2 open
DMN14-61 Support for function types in metamodel and XSD DMN 1.2b1 open
DMN14-46 DMN 1.3 Metamodel DMN 1.2b1 open
DMN14-45 Convenience documents DMN 1.2b1 open
DMN14-50 Knowledge Package Model and Notation (KPMN) DMN 1.2b1 open
DMN14-49 Situational Data Model and Notation (SDMN) DMN 1.2b1 open
DMN14-65 Inconsistency DMNv1.2 dropping [a]=a and get entries example DMN 1.2b1 open
DMN14-64 properly define type(e) DMN 1.2 open
DMN14-66 "instance of" not possible with some built-in functions DMN 1.2b1 open
DMN14-56 Spec does not clarify meaning of hex value DMN 1.2b1 open
DMN14-60 Lack of visual notation for processing of / iteration over lists in FEEL DMN 1.2 open
DMN14-51 data equivalence with date and time DMN 1.2 open
DMN14-59 Friendlier handling of null values DMN 1.2b1 open
DMN14-52 Clarify method signature syntax for Java Function Definition DMN 1.2 open
DMN14-53 Temporal precision inconsistencies DMN 1.2b1 open
DMN14-54 Clarification regarding equivalence of date vs date and time DMN 1.2 open
DMN14-55 Incorrect example in Table 40: Examples of equivalence and conformance relations DMN 1.2 open
DMN14-57 Clean up example xml files DMN 1.2b1 open
DMN14-58 Provide better spec and examples for Equality, Identity, and Equivalence DMN 1.2b1 open
DMN14-63 Clarification on DMN case sensitivity of timezones DMN 1.2 open
DMN14-62 Support for recursive calls by Business Knowledge Models DMN 1.2 open
DMN14-47 DMN Models need a default timezone DMN 1.2 open
DMN14-48 inconsistent date comparisons make unavoidavle paradoxes DMN 1.2 open
DMN14-43 Allow representation of black-box Decision Service DMN 1.2 open
DMN14-44 Fix interchange of links to objects in BPMN/BMM DMN 1.2 open

Issues Descriptions

DMNv1.3 fix DMN example files issues

  • Key: DMN14-74
  • Status: open  
  • 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
  • Updated: Mon, 6 Apr 2020 17:09 GMT

Wrong example for 10.6.1 Context Figure 10.18: Example context

  • Key: DMN14-73
  • Status: open  
  • 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
  • Updated: Mon, 6 Apr 2020 16:56 GMT

Wrong example for substring() builtin funciton

  • Key: DMN14-72
  • Status: open  
  • 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
  • Updated: Mon, 6 Apr 2020 16:56 GMT

Wrong example snippet in 10.3.2.9.4.1 Examples

  • Key: DMN14-75
  • Status: open  
  • 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
  • Updated: Mon, 6 Apr 2020 16:50 GMT

Typos in the XMI files

  • Key: DMN14-71
  • Status: open  
  • Source: Camunda GmbH ( Maciej Barelkowski)
  • Summary:

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

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

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

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

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

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

  • Reported: DMN 1.2 — Thu, 19 Dec 2019 13:19 GMT
  • Updated: Mon, 6 Jan 2020 20:52 GMT

Support for function types in metamodel and XSD

  • Key: DMN14-61
  • Status: open  
  • Source: Goldman Sachs ( 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
  • Updated: Mon, 6 Jan 2020 15:00 GMT

DMN 1.3 Metamodel


Convenience documents


Knowledge Package Model and Notation (KPMN)

  • Key: DMN14-50
  • Status: open  
  • Source: Department of Veterans Affairs ( 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: Mon, 6 Jan 2020 12:59 GMT
  • Attachments:

Situational Data Model and Notation (SDMN)

  • Key: DMN14-49
  • Status: open  
  • Source: Department of Veterans Affairs ( 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: Mon, 6 Jan 2020 12:58 GMT
  • Attachments:

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

  • Key: DMN14-65
  • 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: Fri, 3 Jan 2020 20:51 GMT

properly define type(e)

  • Key: DMN14-64
  • 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: Fri, 3 Jan 2020 20:51 GMT

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

  • Key: DMN14-66
  • 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: Fri, 3 Jan 2020 20:51 GMT

Spec does not clarify meaning of hex value

  • Key: DMN14-56
  • Status: open  
  • 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
  • Updated: Fri, 3 Jan 2020 20:51 GMT

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

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

    split off from DMN13-12

  • Reported: DMN 1.2 — Tue, 20 Nov 2018 17:55 GMT
  • Updated: Fri, 3 Jan 2020 20:51 GMT

data equivalence with date and time

  • Key: DMN14-51
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    Section 10.3.2.3.5 contains the following:

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

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

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

  • Reported: DMN 1.2 — Mon, 27 May 2019 08:30 GMT
  • Updated: Fri, 3 Jan 2020 20:51 GMT

Friendlier handling of null values

  • Key: DMN14-59
  • 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: Fri, 3 Jan 2020 20:51 GMT

Clarify method signature syntax for Java Function Definition

  • Key: DMN14-52
  • Status: open  
  • 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
  • Updated: Fri, 3 Jan 2020 20:51 GMT

Temporal precision inconsistencies

  • Key: DMN14-53
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

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

  • Reported: DMN 1.2b1 — Tue, 16 Jul 2019 14:02 GMT
  • Updated: Fri, 3 Jan 2020 20:51 GMT

Clarification regarding equivalence of date vs date and time

  • Key: DMN14-54
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    Section 10.3.2.3.5 date contains the following:

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

    Is not obvious when the equaivalence should be applied.

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

  • Reported: DMN 1.2 — Sun, 2 Jun 2019 13:01 GMT
  • Updated: Fri, 3 Jan 2020 20:51 GMT

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

  • Key: DMN14-55
  • Status: open  
  • Source: Goldman Sachs ( 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
  • Updated: Fri, 3 Jan 2020 20:51 GMT

Clean up example xml files

  • Key: DMN14-57
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

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

  • Reported: DMN 1.2b1 — Tue, 28 May 2019 16:52 GMT
  • Updated: Fri, 3 Jan 2020 20:51 GMT

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

  • Key: DMN14-58
  • 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: Fri, 3 Jan 2020 20:51 GMT

Clarification on DMN case sensitivity of timezones

  • Key: DMN14-63
  • 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: Fri, 3 Jan 2020 20:51 GMT

Support for recursive calls by Business Knowledge Models

  • Key: DMN14-62
  • 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: Fri, 3 Jan 2020 20:51 GMT

DMN Models need a default timezone

  • Key: DMN14-47
  • 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: Fri, 3 Jan 2020 20:51 GMT

inconsistent date comparisons make unavoidavle paradoxes

  • Key: DMN14-48
  • 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: Fri, 3 Jan 2020 20:51 GMT

Allow representation of black-box Decision Service

  • Key: DMN14-43
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor)
  • 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
  • Updated: Fri, 3 Jan 2020 20:51 GMT

Fix interchange of links to objects in BPMN/BMM

  • Key: DMN14-44
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor)
  • Summary:

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

  • Reported: DMN 1.2 — Thu, 27 Sep 2018 01:07 GMT
  • Updated: Fri, 3 Jan 2020 20:51 GMT