Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — Closed Issues

  • Acronym: DMN
  • Issues Count: 103
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN14-197 Underspecified when ranges may include a qualified name for the endpoint, which resolves to null DMN 1.3 DMN 1.4 Deferred closed
DMN14-182 New built-in function to merge/concatenate two or more contexts DMN 1.3 DMN 1.4 Duplicate or Merged closed
DMN14-183 New built-in function to create a new context DMN 1.3 DMN 1.4 Duplicate or Merged closed
DMN14-181 No function to add an entry to a context DMN 1.3 DMN 1.4 Resolved closed
DMN14-166 New XML Namespace needed DMN 1.3 DMN 1.4 Resolved closed
DMN14-194 Missing boxed expression for iterator expression DMN 1.3 DMN 1.4 Resolved closed
DMN14-192 Missing boxed expression for filter expression DMN 1.3 DMN 1.4 Resolved closed
DMN14-190 Missing boxed expression for conditional statement DMN 1.3 DMN 1.4 Resolved closed
DMN14-196 Typo Table55 row 7 DMN 1.3 DMN 1.4 Resolved closed
DMN14-178 Are the names of boxed context entries unique in a given context ? DMN 1.3 DMN 1.4 Resolved closed
DMN14-55 Incorrect example in Table 40: Examples of equivalence and conformance relations DMN 1.2 DMN 1.4 Resolved closed
DMN14-164 More examples of replace() function needed DMN 1.3 DMN 1.4 Resolved closed
DMN14-117 typo - incorrect indexing DMN 1.3 DMN 1.4 Resolved closed
DMN14-185 Incorrect figure reference DMN 1.3 DMN 1.4 Resolved closed
DMN14-87 Wrong and Incomplete FEEL grammar rule 52 DMN 1.3 DMN 1.4 Resolved closed
DMN14-156 the word 'decision' is misspelt. DMN 1.3 DMN 1.4 Resolved closed
DMN14-126 Missing functions for rounding DMN 1.3 DMN 1.4 Resolved closed
DMN14-167 Sub-decisions are referenced but not defined DMN 1.3 DMN 1.4 Resolved closed
DMN14-150 Collections are not shown on diagrams DMN 1.3 DMN 1.4 Resolved closed
DMN14-143 instance of grammar does not support range , or context, or function DMN 1.3 DMN 1.4 Resolved closed
DMN14-142 DMNDiagram 'Size' attribute has capital 'S' in schema definition DMN 1.3 DMN 1.4 Closed; No Change closed
DMN14-141 The result of product([]) is not defined DMN 1.3 DMN 1.4 Resolved closed
DMN14-74 DMNv1.3 fix DMN example files issues DMN 1.2 DMN 1.4 Resolved closed
DMN14-42 There is no way to identify current date and time, e.g. now() & today() DMN 1.1 DMN 1.4 Resolved closed
DMN14-11 Expressions cannot be used as "end points" DMN 1.1 DMN 1.4 Resolved closed
DMN14-8 Lack of visual notation for processing of / iteration over lists in DRD DMN 1.1 DMN 1.4 Deferred closed
DMN14-6 LiteralExpression and textual expression seem to mean the same thing, need to use the same term DMN 1.0 DMN 1.4 Closed; No Change 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-125 Definitions of overlaps functions DMN 1.3 DMN 1.4 Resolved closed
DMN14-45 Convenience documents DMN 1.2b1 DMN 1.4 Closed; No Change closed
DMN14-137 Typo in horizontal alignment label DMN 1.3 DMN 1.4 Resolved closed
DMN14-86 Wrong example for is() built-in function DMN 1.3 DMN 1.4 Resolved closed
DMN14-85 Wrong example for distinct values() built-in function DMN 1.3 DMN 1.4 Resolved closed
DMN14-93 Wrong XSD for tDecisionService DMN 1.3 DMN 1.4 Closed; No Change closed
DMN14-88 First (and priority) hit policy are unpredictable with partial input DMN 1.3 DMN 1.4 Closed; No Change closed
DMN14-136 Extend endpoints to support expressions DMN 1.3 DMN 1.4 Duplicate or Merged closed
DMN14-52 Clarify method signature syntax for Java Function Definition DMN 1.2 DMN 1.4 Closed; No Change closed
DMN14-116 DMN string join built-in function proposal DMN 1.3 DMN 1.4 Resolved closed
DMN14-36 FEEL ambiguity DMN 1.1 DMN 1.4 Resolved closed
DMN14-20 Wrong character in expression for PMT function definition DMN 1.1 DMN 1.4 Closed; No Change closed
DMN14-1 BigDecimal is not the only mapping of number to Java DMN 1.0 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-23 Enumerations can only be defined as strings DMN 1.1 DMN 1.4 Deferred closed
DMN14-22 Lexical representation of time string has ambiguous definitons DMN 1.1 DMN 1.4 Deferred closed
DMN14-21 Add two new concrete numeric types, make number abstract DMN 1.1 DMN 1.4 Deferred closed
DMN14-19 Can the same Definitions/namespace be used by more than one model? DMN 1.1 DMN 1.4 Deferred closed
DMN14-18 Improve description of built-in function string() DMN 1.1 DMN 1.4 Deferred closed
DMN14-17 Clarification needed if null is passed as value for optional parameter of built in function DMN 1.1 DMN 1.4 Deferred closed
DMN14-16 Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration DMN 1.1 DMN 1.4 Deferred closed
DMN14-14 Should encapsulated decisions of a decision service include output decisions? DMN 1.0 DMN 1.4 Deferred closed
DMN14-13 Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions DMN 1.1 DMN 1.4 Deferred closed
DMN14-12 Enhancement suggestion: make unary tests first class citizens of the FEEL language DMN 1.1 DMN 1.4 Deferred closed
DMN14-10 Include Test Cases in Decision Model DMN 1.1 DMN 1.4 Deferred closed
DMN14-9 Change depiction of Input to be harmonized with BPMN and CMMN DMN 1.1 DMN 1.4 Deferred closed
DMN14-7 XSD: global context DMN 1.0 DMN 1.4 Deferred closed
DMN14-5 Business Knowledge Model can have Information Requirements DMN 1.0 DMN 1.4 Deferred closed
DMN14-4 italics and bold used for both typographic literal notation and FEEL semantic exposition DMN 1.0 DMN 1.4 Deferred closed
DMN14-3 No notation for ItemDefinition DMN 1.0 DMN 1.4 Deferred closed
DMN14-2 Business Context links go both ways DMN 1.0 DMN 1.4 Deferred 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-41 Unspecified conclusion is not supported DMN 1.1 DMN 1.4 Deferred closed
DMN14-40 notion of arbitrary order conflicts with lack of an unordered collection data type DMN 1.1 DMN 1.4 Deferred closed
DMN14-39 need set operations and equality in FEEL DMN 1.1 DMN 1.4 Deferred closed
DMN14-38 In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement DMN 1.1 DMN 1.4 Deferred closed
DMN14-37 Collect decision tables DMN 1.1 DMN 1.4 Deferred closed
DMN14-35 Metamodel constraints & validation DMN 1.1 DMN 1.4 Deferred closed
DMN14-34 Requested additional built-in functions DMN 1.1 DMN 1.4 Deferred closed
DMN14-33 Semantic domain mapping for simple expressions DMN 1.1 DMN 1.4 Deferred closed
DMN14-32 Improvement of Semantic Domains Specification DMN 1.1 DMN 1.4 Deferred closed
DMN14-31 Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122 DMN 1.1 DMN 1.4 Deferred closed
DMN14-30 Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test DMN 1.1 DMN 1.4 Deferred closed
DMN14-29 Should name declarations in same context fail or overwrite? DMN 1.1 DMN 1.4 Deferred closed
DMN14-28 Can an expression in user defined function body reference a name outside of it's scope? DMN 1.1 DMN 1.4 Deferred closed
DMN14-27 How to get FEEL type if evaluation is not an option? DMN 1.1 DMN 1.4 Deferred closed
DMN14-26 Scope of decision table input/output entries is not well defined in the specification DMN 1.1 DMN 1.4 Deferred closed
DMN14-25 More Generic Ways to Define Decision Table Properties DMN 1.1 DMN 1.4 Deferred closed
DMN14-24 FEEL grammar readbility DMN 1.1 DMN 1.4 Deferred closed
DMN14-15 No adjustment for last day in month if duration is added/subtracted to date and time value DMN 1.1 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-69 Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests. DMN 1.3 DMN 1.4 Deferred closed
DMN14-70 Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression DMN 1.3 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
DMN14-153 No way to show relative multiplicity of decisions and their information requirements DMN 1.3 DMN 1.4 Deferred closed

Issues Descriptions

Underspecified when ranges may include a qualified name for the endpoint, which resolves to null

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

    It is underspecified when the ranges may include a qualified name for the endpoint, which resolves to null.

    This was identified by Greg McCreath and Octavian Patrascoiu during TCK contributions.

    Ranges' Endpoints can be either a literal or a qualified name. If the qualified name resolves to null, and the endpoint inclusivity flag is false, it is semantically equivalent to the case of single-endpoint-range. This leads to ambiguity in Table 55: Semantics of decision table syntax

    This also requires the typo fix in https://issues.omg.org/browse/INBOX-1337

    Example

    With reference to examples in Table 42: Examples of range properties values

    Instead of (1..10]
    do consider (x..10]
    if x resolves to null
    then this is semantically equivalent to <=10.

    However, Table 55, row 9, cites:

    e1 in (e2..e3] is equivalent to e1 > e2 and e1<=e3
    
    // exercise by hand..
    e1 in (x..10] is equivalent to e1 > x and e1<=10
    // if x resolves to null..
    e1 in (null..10] is equivalent to e1 > null and e1<=10
    e1 > null and e1<=10
    

    which is NOT equivalent to e1<=10, hence the ambiguity.

  • Reported: DMN 1.3 — Sun, 5 Sep 2021 07:18 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 16 Aug 2022 08:59 GMT

New built-in function to merge/concatenate two or more contexts

  • Key: DMN14-182
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Philipp Ossler)
  • Summary:

    Currently, it is not possible to merge/concatenate two or more contexts. A context can only be declared statically.

    We need to model a decision that gets two or more contexts and returns a new context that includes all entries of the given contexts.

    Suggestions:

    • introduce a new built-in function similar to the concatenate() function of lists but for contexts
    • it is named `put all` (like Java's Map#putAll function)
    • it has one argument: contexts... (type: list<context<Any>>)
    • it returns a new context that includes all entries from the given contexts
    • it might override context entries if the keys are equal. The entries are overridden in the same order as the contexts are passed in the function
    put all({x:1}, {y:2})
    // returns: {x:1, y:2}
    
  • Reported: DMN 1.3 — Tue, 22 Jun 2021 03:56 GMT
  • Disposition: Duplicate or Merged — DMN 1.4
  • Disposition Summary:

    Close as merged

    Resolved as part of DMN14-187

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

New built-in function to create a new context

  • Key: DMN14-183
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Philipp Ossler)
  • Summary:

    Currently, it is not possible to create or modify a context dynamically. A context can only be declared statically.

    We need to model a decision that gets a context, adds or removes entries, and returns a new context. For example, by using the get entries() function of a given context and modifying the entry list with a filter expression or list functions.

    Suggestions:

    • introduce a new conversion built-in function for context as reverse function to get entries()
    • it is named `context`
    • it has one argument: entries... (type: list<context<Any>>) - each context must have two entries with the keys: "key" and "value"
    • it returns a new context that includes all given entries
    context([{"key":"a", "value":1}, {"key":"b", "value":2}])
    // returns: {a:1, b:2}
    
  • Reported: DMN 1.3 — Tue, 22 Jun 2021 04:11 GMT
  • Disposition: Duplicate or Merged — DMN 1.4
  • Disposition Summary:

    Close as merged

    Resolved as part of DMN14-187

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

No function to add an entry to a context

  • Key: DMN14-181
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Philipp Ossler)
  • Summary:

    Currently, it is not possible to add an entry to a given context. A context can only be declared statically.

    We need to model a decision that gets a context, adds an entry, and returns the new context.

    Suggestions:

    • introduce a new built-in function similar to the add() function of lists but for contexts
    • it is named `put` (like Java's Map#put function)
    • it has three arguments: context (type: context<Any>), key (type: string), value (type: Any)
    • it returns a new context that includes the new entry
    • it might overwrite the value of an existing entry
    put({x:1}, "y", 2)
    // returns {x:1, y:2}
    
  • Reported: DMN 1.3 — Tue, 22 Jun 2021 03:45 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Introduce 3 new built-in functions for context

    Introduce 3 new built-in functions for context creation, context put, context merge (of several contexts).

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

New XML Namespace needed

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

    For tools to clearly identify the version of a DMN file or FEEL expression, the XML namespaces of DMN, DMN DI, and FEEL should be updated.

    DI and DC namespaces can stay the same as DMN 1.4 DI is still based on the same DI 1.1 specification.

    Namespace URIs should be consistent with the scheme applied in DMN 1.2 and DMN 1.3

  • Reported: DMN 1.3 — Tue, 20 Apr 2021 18:49 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Update XML Namespaces for DMN 1.4

    Update namespace URIs with the following values:

    This is consistent with the scheme applied in DMN 1.2 and DMN 1.3, and in conformance with the "OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces in OMG Specifications - Version 3" (smsc/2018-08-01), which states in particular:

    Note: if a spec has many machine readable files, and only some of them change at a given specification version, then only the changed files should get new URIs. That could mean a mixture of URI date segment values for a given specification version.

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

Missing boxed expression for iterator expression


Missing boxed expression for filter expression

  • Key: DMN14-192
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The current version of the spec is missing a boxed expression visualization and serialization for filter expression

  • Reported: DMN 1.3 — Tue, 7 Sep 2021 12:54 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Add boxed filter expression

    See attached word document and figures

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

Missing boxed expression for conditional statement


Typo Table55 row 7

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

    From row 4 it is about syntax sugar for inequality, but is missing the >case (row7).

  • Reported: DMN 1.3 — Sun, 5 Sep 2021 07:10 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Fix typo

    Fix typo

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

Are the names of boxed context entries unique in a given context ?

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

    The standard does not specify if a valid boxed context can contain several context entries with the same key or not.

    However, it does specify that if a FEEL context is described via text (see FEEL grammar and 10.3.2.6 Context) the keys are distinct.

    Also, how are the names overriden / shaded ?

  • Reported: DMN 1.3 — Tue, 8 Jun 2021 11:10 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Clarify that names are unique within a context

    Proposal does not explicitly state that names are unique within a context - clarify.

  • Updated: Thu, 31 Mar 2022 19:30 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

More examples of replace() function needed

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

    for instance append a basic down-to-Earth example like:

    replace("banana","a","o") = "bonono"
    

    as already agreed on the DMN TCK.

    We found User enquiry about the behaviour of the function, and the only example listed currently is quite techy. Possibly adding a simple example first would help end-users

  • Reported: DMN 1.3 — Tue, 13 Apr 2021 10:16 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Add more examples of replace() function

    We got User enquiries about the behaviour of the function, and the only example listed currently is quite technical. Possibly adding a simple example first, in addition to the existing technical example, would help end-users.

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

typo - incorrect indexing

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

    Second paragraph from the bottom of page 173 contains

    have qualified names nbkmi and encapsulatedLogic bkmi.f.

    it should be

    have qualified names nbkmi and encapsulatedLogic fbkmi.

    where bkmi are formatted as indexes (see description of the of the syntax for FEEL function in the naext paragraph).

  • Reported: DMN 1.3 — Thu, 24 Dec 2020 10:23 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Correct typo - incorrect indexing

    correct indexing

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

Incorrect figure reference

  • Key: DMN14-185
  • Status: closed  
  • Source: Sapiens Decision NA ( Mr. Gil Segal)
  • Summary:

    On p. 155, section 10.6.1 incorrectly refers to Figure 10-2. The reference should be to Figure 10-18 which is found on p. 156.

  • Reported: DMN 1.3 — Tue, 29 Jun 2021 16:35 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Correct figure reference

    On p. 155, section 10.6.1 incorrectly refers to Figure 10-2. The reference should be to Figure 10-18 which is found on p.156.

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

Wrong and Incomplete FEEL grammar rule 52

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

    Grammar rule 52 is using single quote notation, and I believe this is just a typo when submitting the original change.

    However DMNv1.3 also missed to exclude grammar 52 from defining Literal terminal symbol.
    This is a concerning problem.
    This implies rule 52 as defined in DMNv1.3 is defining additional Literal terminal symbol(s) and therefore with DMNv1.3 it is no longer formally possible to name a DRGElement for example: "list of products" or "context of business".
    I believe this is an oversight in backward compatibility:

    • rule 52 is only used for the technical “instance of” operator which may find limited use by business analysts
    • using as a name “list …” or “context …” might be more relevant and wide-spread used, ref examples above

    The proposal below addresses this problem as well, making DMNv1.3+ backward compatible again

    Proposal

    A total of 2 changes.

    With reference to DMNv1.3 dtc-19-12-06

    Chapter 10.3.1.2 Grammar rules Page 121
    replace:

    52. type =
    qualified name |
    'list' '<' type '>' |
    'context' '<' name ':' type { ',' name ':' type } '>' | 'function' '<' [ type { ', ' type } ] '>' '->' type
    ;
    

    with:

    52. type =
    qualified name |
    "list" "<" type ">" |
    "context" "<" name ":" type { "," name ":" type } ">" | "function" "<" [ type { ", " type } ] ">" "->" type
    ;
    

    Chapter 10.3.1.4 Tokens, Names, and White space Page 122
    before bullet point:

    * A sequence conforming to grammar rule 28, 29, 35, or 37

    insert new bullet point:

    * for backward compatibility reasons, “list” and “context” from grammar rule 52 are not considered Literal terminal symbols.

  • Reported: DMN 1.3 — Wed, 8 Apr 2020 07:20 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Correct FEEL grammar rule 52

    Replace inverted commas in rule 52 and include "52" in reference

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

the word 'decision' is misspelt.

  • Key: DMN14-156
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    In the following section, the world 'decision' is misspelt as 'decsion'.

    "- Binding contexts in which the value of an expression is bound to a variable with associated type information
    (e.g. binding actual parameters to formal parameters in an invocation, or binding the result of a decision’s logic
    to the decsion’s output variable). The expression is subject to conforms to conversion."

  • Reported: DMN 1.3 — Sun, 28 Feb 2021 07:02 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Fix typo

    Fix spelling of decision

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

Missing functions for rounding

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

    Currently the existing functions support: ceiling, flooring and even rounding.

    There are uses cases where other type of rounding are needed.

  • Reported: DMN 1.3 — Wed, 20 Jan 2021 20:15 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Add extra functions for rounding

    Add extra functions for rounding

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

Sub-decisions are referenced but not defined

  • Key: DMN14-167
  • Status: closed  
  • Source: Sapiens Decision NA ( Mr. Gil Segal)
  • Summary:

    The DMN 1.3 specification refers to "sub-decisions" in two places (sections 5.3.3 and 10.6.1) but this term is not defined.

  • Reported: DMN 1.3 — Thu, 27 May 2021 15:19 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Replace sub-decision as a term

    Replace the phrases with alternative descriptions

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

Collections are not shown on diagrams

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

    When an Input Data or Decision is represented by an InformationItem that is a collection, there is no visual annotation on the DRD, reducing the clarity of the diagram.

  • Reported: DMN 1.3 — Wed, 24 Feb 2021 05:26 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Annotate collections on DRDs

    Revise the text to allow a decoration on Input Data and Decisions that are collections.

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

instance of grammar does not support range , or context, or function

  • Key: DMN14-143
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The instance of grammar does not include the range type, so it is not possible to do `[1..10] instance of range<Any>`. Nor does it support either identifying something as simply a context, or simply as a function.

    Please add range<type> to the grammar.

    The grammar does support identifying something as simply a context. The list type can be accommodated by <Any>, such as `foo instance of list<Any>`, but the grammar for context currently requires at least one name and type, so simply checking that something is a context is not supported. That is, `foo instance of context<>` is not possible.

    Please change the context grammar from `'context' '<' name ':' type

    { ',' name ':' type }

    '>' to `'context' '<[' name ':' type

    { ',' name ':' type }

    ']>'` implying that `context<>` means a context with no entries and thus, all contexts conform to it. Though, a more preferable alternative is described below.

    Also, the grammar does not support identifying something as a function, only as a function of a given type - there is no equivalent to `foo instance of function<Any> -> Any`. The statement `foo instance of function<> -> Any` is testing for a function type with no params. This is different to testing purely for a function type.

    A grammar to support the above is simply to support the name of each of the types with no `<>` stuff afterwards. Such that `foo instance of list`, `foo instance of context`, `foo instance of function`, `foo instance of range` are all valid. This would be my preference.

  • Reported: DMN 1.3 — Sun, 21 Feb 2021 01:03 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Add range to instance of

    The changes are baselined on DMN 1.3 dtc-19-12-06.pdf.

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

DMNDiagram 'Size' attribute has capital 'S' in schema definition

  • Key: DMN14-142
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The DMNDI13 XML schema has element child element 'Size' for DMNDiagram. Note the capital 'S'. This is an anomaly as all other element names have a lower case first char.

    Additionally, the spec on page 238 incorrectly has the element as 'size' - with a lower case.

    Suggestion is deprecate 'Size' in the schema, support both for a time, then drop 'Size' to support only support 'size' - to align the naming in the schema with other elements. And update the spec accordingly.

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 10:44 GMT
  • Disposition: Closed; No Change — DMN 1.4
  • Disposition Summary:

    Close without change

    It is not worth breaking backward compatibility, for a purely cosmetic issue in the XML schema. The XML serialization is meant to be written and read by software and this should be a major problem for implementers. XML schema validation should easily uncover a bug in an exporter and the fix is trivial.

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

The result of product([]) is not defined

  • Key: DMN14-141
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The product() function may take a list but it is not defined what the return value is when the list is empty.

    It could be zero, or could be null. Other list function return null like `median( [ ] ) = null`, and `stddev( [ ] ) = null`, so it seems reasonable to make `product([]) = null`, but likely more business friendly to make `product([]) = 0`. I'd go for the latte.

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 10:29 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Define result of product([]) to be null

    As discussed on the RTF meeting held 2021-03-23 for consensus (kept consistency with other functions)

  • 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:

There is no way to identify current date and time, e.g. now() & today()

  • Key: DMN14-42
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    We need to be able to compare to the current date and time
    e.g.
    Now() as a unitary test
    or
    Now() = a specified date and time

  • Reported: DMN 1.1 — Thu, 2 Jun 2016 15:54 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Add functions now() and today()

    Add functions to be able to compare with the current data or time.

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

Expressions cannot be used as "end points"

  • Key: DMN14-11
  • Status: closed  
  • Source: Red Hat Inc ( Edson Tirelli)
  • Summary:

    The grammar does not allow expressions to be used as "endpoints" on ranges and unary tests.
    Users have to create dummy variables in order to use expressions as "endpoints".

  • Reported: DMN 1.1 — Tue, 23 Aug 2016 01:32 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Extend ranges to support expressions as endpoints

    Change the grammar to allow expressions to be used as "endpoints" on ranges and unary tests. E.g.:

    { Thanksgiving holiday: [ date(“2016-11-24”) .. date(“2016-11-27”) ] }
  • Updated: Thu, 31 Mar 2022 19:30 GMT

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

  • Key: DMN14-8
  • Status: closed  
  • Source: Signavio GmbH ( Dr. Bastian Steinert)
  • Summary:

    The processing of lists of data is fundamental to business decisions. Some kind of multiplicity should be indicated at the DRD level, and iteration should be supported visually at the decision logic level. In spite of the attached figures (meant to provoke discussion), the scope of this issue is limited to "flat" DRDs, that is, no "sub-DRDs" nested inside an outer decision or BKM. DRD proposal should specify what the multiplicity marker or other DRD notation looks like, and where it may appear, e.g. attached to head or tail of a requirement arrow, or inside a decision or BKM shape left of the name, etc.

  • Reported: DMN 1.1 — Wed, 4 May 2016 08:49 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:

LiteralExpression and textual expression seem to mean the same thing, need to use the same term

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

    literal expression is used in MM, and textual expression is used in grammar. Let's use 1 consistently, but check that they are really the same concept.

  • Reported: DMN 1.0 — Thu, 16 Jul 2015 16:30 GMT
  • Disposition: Closed; No Change — DMN 1.4
  • Disposition Summary:

    `textual expression` does not mean `Literal Expression`

    There are no places where `textual expression` refers to the `literal expression` meta model element.

    `textual expression` is used only in the FEEL grammar and in the refinement of Decision Tables when using FEEL (10.3.2.10 Decision Table) and it clearly refers to the FEEL grammar in that instance.

    Each input expression SHALL be a textual expression (grammar rule 2). Each list of input values SHALL be an instance of unary tests (grammar rule 15).

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

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

Definitions of overlaps functions

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

    It looks like the logic definitions of functions overlaps and overlaps before do not produce the results expected in the Example column.

    The expected results look correct to me. I believe we need to fix the second column for overlaps and overlaps before as follows:

    For overlaps before:
    (range1.start < range2.start or (range1.start = range2.start and (range1.start included and not(range2.start included))))
    and (range1.end > range2.start or (range1.end = range2.start and range1.end included and range2.start included))
    and (range1.end < range2.end or (range1.end = range2.end and (not(range1.end included) or range2.end included )))

    For overlaps:
    overlapsBefore(range1, range2)
    or overlapsAfter(range1, range2),
    or includes(range1, range2),
    or includes(range2, range1)
    and leave the implementation to optimize the formula if needed.

  • Reported: DMN 1.3 — Mon, 4 Jan 2021 11:36 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    less intrusive change to fix the "overlaps before", "overlaps" built-in functions

    The less intrusive change to fix the "overlaps before" is to fix the typo at the 7th row of the formula to align it with being the analogous of the "overlaps after",

    Then, the less intrusive change to fix the "overlaps" is to fix rows 5,6,7 of the formula.

    This would keep the original request that each built-in is standalone if possible and not derived from other built-in.

    I believe these are the minimal modifications required to fix the problem but keep the original format.
    I believe in the previous cycle with all editorial discussions like the parameter renames, these things slipped through.
    Big kudos to Octavian Patrascoiu for pointing it out!! +1

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

Convenience documents


Typo in horizontal alignment label

  • Key: DMN14-137
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    Spec say "labelHorizontalAlignement". Should be "labelHorizontalAlignment". The corresponding vertical property is correct at "labelVerticalAlignment".

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 09:12 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Fix typo

    Fix typo "labelHorizontalAlignement"

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

Wrong example for is() built-in function

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

    Executive summary

    I believe the last example for the is() built-in function of DMNv1.3 is wrong.

    Details

    The example from DMNv1.3 which I believe is wrong is:
    is(time("23:00:50z"), time("23:00:50+00:00”)) is false

    Besides that is not FEEL and not consistent with the other examples, but likely it is meant to be humanly interpreted as is(time("23:00:50z"), time("23:00:50+00:00”)) = false which I argue is wrong semantically.

    Accordingly to 10.3.2.3.4 time:

    A time in the semantic domain is a value of the XML Schema time datatype. It can be represented by a sequence of numbers for the hour, minute, second, and an optional time offset from Universal Coordinated Time (UTC).

    Understanding from this first sentence is that in the FEEL semantic domain time is defined by time: H, M, S, OFFSET?

    it continues with:

    If a time offset is specified, including time offset = 00:00, the time value has a UTC form and is comparable to all time values that have UTC forms.
    If no time offset is specified, the time is interpreted as a local time of day at some location,

    So we can have in the FEEL semantic domain a

    • time: H, M, S, no offset specified "local time of day at some location"
      or
    • time: H, M, S, OFFSET

    This is consistent with 10.3.4.1 Conversion functions:

    time string – either
    a string value in the lexical space of the time datatype specified by XML Schema Part 2 Datatypes; or
    a string value that is the extended form of a local time representation as specified by ISO 8601, followed by the character "@", followed by a string value that is a time zone identifier in the IANA Time Zones Database (http://www.iana.org/time-zones)

    Therefore:
    if we are in the first case by XML Schema Part 2 Datatypes we will have an offset if something follow the ":ss" seconds part in the string,
    otherwise,
    if we use the second case "hh:mm:ss@location" form, we will not have an XML Schema Part 2 Datatypes offset, but we will interpret the time at some geographical location offset based on IANA.

    Follows interpretation of a few examples of time strings, and their FEEL semantic domain projection:

    time string 10.3.4.1 Conversion functions time string first or second case? H M S specified OFFSET? OFFSET because XML Schema Part 2 OFFSET because IANA Time Zones Database
    "23:00:50" first case 23 0 50 no null null
    "23:00:50@Europe/Rome" second case 23 0 50 yes null Europe/Rome
    "23:00:50@Europe/Paris" second case 23 0 50 yes null Europe/Paris
    "23:00:50+02:00" first case 23 0 50 yes +2 null
    "23:00:50+00:00" first case 23 0 50 yes +0 null
    "23:00:50Z" first case 23 0 50 yes +0 null

    Accordingly to DMNv1.3 they will be all equals as in a=b (as valuet() does return the same for all of them).

    Accordingly to DMNv1.3 they are all FEEL semantically domain different expect the last two, because once projected to the semantic domain they represent the same hour, minute, second, AND offset quantity, accordingly to a string value in the lexical space of the time datatype specified by XML Schema Part 2 Datatypes.

    Hence, resulting in

    is(time("23:00:50z"), time("23:00:50+00:00")) = true
    

    instead.

    Proposal

    change last line example from:

    is(time("23:00:50z"), time("23:00:50+00:00”)) is false
    

    to

    is(time("23:00:50z"), time("23:00:50+00:00")) = true
    
  • Reported: DMN 1.3 — Tue, 7 Apr 2020 12:58 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Correct table 77

    change last line example from:

    is(time("23:00:50z"), time("23:00:50+00:00”)) is false
    

    to

    is(time("23:00:50z"), time("23:00:50+00:00")) is true
    
  • Updated: Thu, 31 Mar 2022 19:30 GMT

Wrong example for distinct values() built-in function

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

    this is a typo fix: the example is missing a closed round paren.

    Proposal

    with reference to DMNv1.3 dtc/19-12-06 in chapter 10.3.4.4 List functions page 161 replace:

    distinct values([1,2,3,2,1] = [1,2,3]
    

    with

    distinct values([1,2,3,2,1]) = [1,2,3]
    
  • Reported: DMN 1.3 — Tue, 7 Apr 2020 08:17 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Fix typo on distinct values() function example

    See revised text.

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

Wrong XSD for tDecisionService

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

    With refererence to DMNv1.3 dtc-19-12-06
    Chapter 6.3.10 Decision service metamodel
    page 64

    the table
    Table 17: DecisionService attributes and model associations

    reports:

    outputDecisions: Decision [1..*]

    but the XSD schema:

    <xsd:element name="outputDecision" type="tDMNElementReference" minOccurs="0" maxOccurs="unbounded"/>
    

    Proposal

    change XSD from:

    <xsd:element name="outputDecision" type="tDMNElementReference" minOccurs="0" maxOccurs="unbounded"/>
    

    to

    <xsd:element name="outputDecision" type="tDMNElementReference" minOccurs="1" maxOccurs="unbounded"/>
    

    (minOccurs to 1)

  • Reported: DMN 1.3 — Fri, 5 Jun 2020 06:49 GMT
  • Disposition: Closed; No Change — DMN 1.4
  • Disposition Summary:

    Need to allow interchange of incomplete models

    No change

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

First (and priority) hit policy are unpredictable with partial input

  • Key: DMN14-88
  • Status: closed  
  • Source: Moxio ( Merijn Wijngaard)
  • Summary:

    A decision table with a hit policy of FIRST uses rule order to decide its output, but only among those rules which have an output. This works fine when the input is complete, but becomes unpredictable when input is partial. Higher priority rules (earlier in the order) may not have an output yet while lower priority rules do, even when higher priority rules may generate an output in the future when more input become available. This makes the FIRST hit policy (the same goes for PRIORITY) not usable in a context where the decision logic will be run on partial, incrementally expanded input (e.g. an interactive expert system).

    When reading the description for the FIRST hit policy in the spec, I get the feeling that the OMG is opposed to having rule order play a role in the evaluation of a decision table. I realize there are ways around using rule order by using different hit policies and separating the logic into multiple decision tables, but I do believe that that would not improve the understandability of the logic. Having the rule order play a role in the evaluation of a decision table can definitely make them more self-contained (decision tables are smaller and/or logic is less spread out), and therefore easier to write and understand in some cases. But an implementation that uses rule order needs to be predictable, even on partial input.

    Therefore I would like to propose an addition to the existing hit policies: ELIMINATE (or at least i think that term describes it well).

    The ELIMINATE hit policy evaluates a decision table's rules in order:

    • If a rule is validated (it matches), it produces an output and evaluation is stopped
    • If a rule is invalidated (it will never match, even as more input becomes available), evaluation continues with the next rule (i.e. it is eliminated)
    • If a rule cannot be invalidated (because input is partial), evaluation is stopped and the table produces no output
    • A decision table with a hit policy of ELIMINATE can only ever produce a single output

    I hope you will consider adding this to the spec in some form or another, since it would make working with dmn in a context of incrementally expanding input a lot easier.

  • Reported: DMN 1.3 — Fri, 29 May 2020 08:30 GMT
  • Disposition: Closed; No Change — DMN 1.4
  • Disposition Summary:

    Hit policies work as designed with partial data

    The decision services designed using DMN are meant to be stateless. Therefore when the partial data is submitted the first hit table behaves correctly, given the partial data. When the more complete data is submitted, it behaves differently but still correctly. The fact that the table behaves differently given different submitted data sets seems completely reasonable and we don't see the need for another hit policy.

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

Extend endpoints to support expressions

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

    Currently enpoints can be only simple values (e.g. simple literals such as 123 or qualified names).

    This proposal is about extending the endpoints to be expressions. For example ranges such as [x, x+2) would be supported.

    Proposal:

    Page 120 Section 10.3.1.2. Grammar rules

    Replace

    16. endpoint = simple value ;

    with

    16. endpoint = expression ;

  • Reported: DMN 1.3 — Tue, 9 Feb 2021 17:38 GMT
  • Disposition: Duplicate or Merged — DMN 1.4
  • Disposition Summary:

    Close as duplicate

    Duplicate of DMN14-11

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

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 string join built-in function proposal

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

    This is a proposal for a new DMN built-in function to join a list of strings, for which currently the specification does not offer any out-of-the-box support.

    This is partially connected to OMG DMN RTF https://issues.omg.org/browse/DMN14-34, but it focuses only on a specific one, between of those functions.

    Assessment

    As of DMNv1.3 the specification is not offering any built-in support for the use-case of concatenating a list of strings into a final string.

    Please notice this is not the use case of using the “+” operator as in:

    first name + " " + last name
    

    This is the use case of joining a list of strings, for example

    [ "product 1", "product 2", ... ]
    

    In the book “DMN Cookbook: 50 Decision Modeling Recipes to Accelerate Your Business Rules” by Bruce Silver and Edson Tirelli ISBN: 9780982368183, the authors are offering 3 working solutions in Chapter 4.2. This requires however the modeler to implement manually or in a “personal library” of BKMs the preferred solution.

    The Signavio platform is offering it as a custom function (https://documentation.signavio.com/suite/en-us/Content/process-manager/userguide/dmn-literal-expressions.htm#concat) which however is only available on that specific platform.

    It is likely other Vendors are offering this functionality in their own way.

    This is an opportunity for the RTF to standardize what different people are doing differently, and not currently covered in the DMN spec.

  • Reported: DMN 1.3 — Tue, 15 Dec 2020 12:35 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Add String join function

    This is a proposal for a new DMN built-in function to join a list of strings, for which currently the specification does not offer any out-of-the-box support.

    This is partially connected to OMG DMN RTF https://issues.omg.org/browse/DMN14-34, but it focuses only on a specific one, between of those functions.

    Assessment

    As of DMNv1.3 the specification is not offering any built-in support for the use-case of concatenating a list of strings into a final string.

    Please notice this is not the use case of using the “+” operator as in:

    first name + " " + last name
    

    This is the use case of joining a list of strings, for example

    [ "product 1", "product 2", ... ]
    

    In the book “DMN Cookbook: 50 Decision Modeling Recipes to Accelerate Your Business Rules” by Bruce Silver and Edson Tirelli ISBN: 9780982368183, the authors are offering 3 working solutions in Chapter 4.2. This requires however the modeler to implement manually or in a “personal library” of BKMs the preferred solution.

    The Signavio platform is offering it as a custom function (https://documentation.signavio.com/suite/en-us/Content/process-manager/userguide/dmn-literal-expressions.htm#concat) which however is only available on that specific platform.

    It is likely other Vendors are offering this functionality in their own way.

    This is an opportunity for the RTF to standardize what different people are doing differently, and not currently covered in the DMN spec.

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

FEEL ambiguity

  • Key: DMN14-36
  • Status: closed  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    FEEL grammar is ambiguous. Rule 2.i is ambiguous for identifiers like Person, as it can lead to two parse trees, one with QualifiedName the other with Name in it. See rule for simple value.

    Rule 1 is ambiguous as there is an overlap between textual expression and boxed expression. I suggest breaking the grammar in several grammars with a common part. This ambiguity will just go away as soon as we do that.

  • Reported: DMN 1.1 — Sun, 30 Oct 2016 11:41 GMT
  • Disposition: Resolved — DMN 1.4
  • Disposition Summary:

    Fix FEEL grammar ambiguity

    Fix some ambiguities in the FEEL grammar (several different parse trees for same inputs) For example, 123 can be a literal or simple positive unary test when the start symbol is expression.

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

Wrong character in expression for PMT function definition

  • Key: DMN14-20
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    The expression of the PMT function contains an invalid character and is therefore not executable. The first minus character is a dash, but shouldn't.

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

    Fixed:

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

  • Reported: DMN 1.1 — Fri, 2 Feb 2018 10:32 GMT
  • Disposition: Closed; No Change — DMN 1.4
  • Disposition Summary:

    Corrected by DMN14-97

    Duplicate issue - already corrected by DMN14-97

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

BigDecimal is not the only mapping of number to Java

  • Key: DMN14-1
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Clause 10.3.2.9 shows FEEL number values as mapped to XML decimal, integer, and double, but the only mapping to Java is to BigDecimal. The appropriate mapping to Java, like the appropriate mapping to XML, depends on the range and intent of the data element. BigDecimal is rarely used for anything but currency. Java int and double are much more likely to be appropriate for most data items. The mapping of number to Java should be just as flexible as the mapping to XML and PMML.

  • Reported: DMN 1.0 — Wed, 9 Jul 2014 21:23 GMT
  • Disposition: Closed; No Change — DMN 1.4
  • Disposition Summary:

    BigDecimal is not the only mapping of numbers in Java

    The use of other number types in Java can be done by implementing engine optimizations, as long as the overall semantics of FEEL numbers is supported.

  • 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

Enumerations can only be defined as strings

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

    Item Definitions can share constraints and these constraints are specified as unary tests. This allows definitions such as requiring a positive number ( >0) or restricting a field to a specific value ("high", "medium", "low").

    However this requires enumerations to be strings and does not allow enumerations to be managed (sorted for instance). In addition, an enumerated list might be used for a set of Information Items but it must be repeated in Decision Tables when columns are meant to be restricted to the list of values.

    DMN should allow for the creation and management of enumerations:

    • Name
    • Description (optional)
    • List of enumerated values (optionally with a sort order)

    These enumerations should be considered symbolic constants, not strings

    FEEL functions should be created to:
    Get the list of of allowed values for a specified enumeration
    Check a value against an enumeration to see if it is an allowed value for that enumeration
    Check the sort order of some specified values in the context of an enumeration

    Decision Tables should be able to reference an enumeration by name in the value list row
    Information Items should be able to be linked to an enumeration

  • Reported: DMN 1.1 — Thu, 26 Oct 2017 16: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

Lexical representation of time string has ambiguous definitons

  • Key: DMN14-22
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    A lexical time string is defined o page 131 by XML Schema Part 2 Datatypes (for local times and offset times) and by ISO 8601 with the extended form of a local time (for zoned times).

    Unfortunately XML Schema Part 2 and ISO 8601 has different definitions. Therefore it is unclear which of them to use. Or are both of them valid?

    Additionally the user should not have different lexical time string formats for a local time, an offset time or a zoned time.

    The list of ambiguities:

    • ISO 8601 allows a leading "T" character prefix. XML Schema Part 2 does not.
    • ISO 8601 allows optional seconds. In XML Schema Part 2, the seconds are mandatory.
    • ISO 8601 allows decimal fraction for seconds and minutes. XML Schema Part does not allow this.
    • ISO 8601 allows 00:00:00 and 24:00:00 for midnight. XML Schema Part 2 only allows 00:00:00.
    • ISO 8601 allows time offset of hours only. Minutes are optional. XML Schema Part 2 always requires minutes.

    Therefore clarification is needed. Which definitions are valid for FEEL? The stricter XML Schema Part 2 or the more user friendly ISO 8601 spec?

  • Reported: DMN 1.1 — Mon, 13 Nov 2017 15:24 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

Add two new concrete numeric types, make number abstract

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

    Currently S-FEEL / FEEL contains only one single numeric type called number that matches the semantics defined in IEEE 754-2008.

    This can lead to some strange constructions, such as
    substring("footbar", 3.67)
    perfect valid in FEEL.

    It also has impact on the performance of the execution (speed).

    Here is my proposal:

    • keep number as an abstract type to backwards compatibility
    • add a new concrete type real/float/decimal that matches the semantics of defined in IEEE 754-2008
    • add a new concrete type integer
    • change the signature of all built-in functions to restrict number to integer when it makes sense (e.g. index in a string and list, length of string. size of list)
    • add a separate paragraph to specify the implicit conversions performed by the FEEL processor when required (e.g. function resolution). For example,
      2 + 4.5 leads to a promotion 2 -> 2.0 that adding it 4.5.

    If we agree in principal all start working on it.

  • Reported: DMN 1.1 — Wed, 6 Dec 2017 13:44 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

Can the same Definitions/namespace be used by more than one model?

  • Key: DMN14-19
  • Status: closed   Implementation work Blocked
  • Source: Red Hat ( Edson Tirelli)
  • Summary:

    Please clarify if it is possible to have multiple models on the same namespace. For instance:

    <definitions namespace="http://my.company/financeModels" name="Model A" ...

    <definitions namespace="http://my.company/financeModels" name="Model B" ...

    The current text of the specification does not say anything explicitly one way or another, so please clarify that.

    In addition to this, if multiple models can use the same namespace, then the <import> element will require an additional attribute (for instance: modelName) in order to uniquely identify which model should be imported.

  • Reported: DMN 1.1 — Thu, 8 Mar 2018 16:20 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

Improve description of built-in function string()

  • Key: DMN14-18
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    The expected output of the built-in function string() should be defined for each type. Otherwise it is unclear what the result for a value, for example of type time, is. Is it the string literal or the full expression with built-in function time()?

    // which FEEL expression is valid?
    string(time("11:00:00")) = "11:00:00"
    string(time("11:00:00")) = "time("11:00:00")"
    

    Recommendation: Introduce a new table that lists example outputs for all types:

    • null -> null
    • boolean -> "true" or "false"
    • string -> "This is a string"
    • number -> "-1.234"
    • date -> "2017-10-11"
    • time -> "11:00:00.123" or "11:00:00.123+02:00" or "11:00:00.123@Europe/Paris"
    • date and time -> "2017-10-11T11:00:00.123" or "2017-10-11T11:00:00.123+02:00" or "2017-10-11T11:00:00.123@Europe/Paris"
    • days and time duration -> "P2DT3H4M5.123S"
    • years and months duration -> "P2Y3M"
    • list -> "[1,2,3]"
    • context -> "{a: true, b: false}"
    • range -> "[1..100]"
    • unary test -> "> 10"
    • function -> null
  • Reported: DMN 1.1 — Wed, 11 Oct 2017 09: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 needed if null is passed as value for optional parameter of built in function

  • Key: DMN14-17
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    Some built-in functions has optional parameters. Chapter 10.3.4 describes "Whenever a parameter is outside its domain, the result of the built-in is null."

    Should the following call to a built-in function result to null?

    replace("This is a string", "[a-z]", "#", null)
    

    The optional parameter "flags" of the built-in function replace() is null. Parameter domain is string as stated in table 60 on page 133. Null is not in the domain of type string.

    This topic was already discussed in the DMN TCK. We think that the behavior should be the same as the function is called without the optional parameter:

    replace("This is a string", "[a-z]", "#", null) = replace("This is a string", "[a-z]", "#")
    

    Clarification in the specification is appreciated.

    May be we can change the sentence in chapter 10.3.4 on page 130 to: "Whenever a parameter is outside its domain, the result of the built-in is null. If null is passed as value to an optional parameter, the built-in behaves like no value is passed."

  • Reported: DMN 1.1 — Tue, 10 Oct 2017 14:32 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

Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration

  • Key: DMN14-16
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    Chapter 10.3.2.3.4 time, 10.3.2.3.5 date, 10.3.2.3.6 date-time, 10.3.2.3.7 days and time duration and chapter 10.3.2.3.8 years and months duration defines each a value function. For date time arithmetic operations it would be useful to have this value available in the FEEL semantic domain. Therefore we suggest to add a new property value that is directly available for values of this type. Return type of the value if always a number.

    Table 53 should be adjusted accordingly.

  • Reported: DMN 1.1 — Tue, 10 Oct 2017 09:57 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

Should encapsulated decisions of a decision service include output decisions?

  • Key: DMN14-14
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    Figure 10 on page 25 with text "The encapsulated decisions are therefore

    {Decision 1, Decision 2}

    "

    Figure 11 on page 26 with text "The encapsulated decisions for this services are

    {Decision 1}

    ".

    Table 20 on page 56:

    • "outputDecisions: This attribute lists the instances of Decision required to be output by this DecisionService".
    • "encapsulatedDecisions: If present, this attribute lists the instances of Decision to be encapsulated in this DecisionService".

    For us it is unclear what decisions should be stored in the DMN model as encapsulated decisions. Must the output decisions also be included in the list of encapsulated decisions (as stated on page 25, 26)? Or does the list of encapsulated decisions only hold the decisions contained in the lower compartment of a decision service (as mentioned on 56 since encapsulatedDecisions seems to be optional)?

  • Reported: DMN 1.0 — Tue, 20 Mar 2018 14:49 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

Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions

  • Key: DMN14-13
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    In Figure 6.15 the multiplicity of output decisions for a decision service is shown as zero to many (0..), but the text below and Table 16 says the that multiplicity is one to many (1..). The figure should be correct to match the text and table.

  • Reported: DMN 1.1 — Fri, 3 Aug 2018 21: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

Enhancement suggestion: make unary tests first class citizens of the FEEL language

  • Key: DMN14-12
  • Status: closed  
  • Source: Red Hat Inc ( Edson Tirelli)
  • Summary:

    This is a suggestion for future versions of the spec:

    Add support for Unary Tests as first class citizens of the FEEL language, in a similar way as ranges and functions already are.

    A unary test is really a “predicate”: a single parameter function that returns a boolean. It is syntax sugar on:

    function ( x ) x in <unary_test>

    FEEL already supports functions as first class citizens, so it makes sense to support Unary Tests. The following two syntaxes would then be equivalent:

    is minor : < 18
    is minor : function( age ) age in < 18

    Invoking unary tests explicitly would be like invoking a function:

    Bob is minor : is minor( bob.age )

    More importantly, it would allow the implementation to actually support passing unary tests as parameters to functions and make the example on page 115 viable:

    decision table (
    outputs: "Applicant Risk Rating",
    input expression list: [Applicant Age, Medical History],
    rule list: [
    [ >60, "good", "Medium" ],
    [ >60, "bad", "High" ],
    [ [25..60], -, "Medium" ],
    [ <25, "good", "Low" ],
    [ <25, "bad", "Medium" ]
    ],
    hit policy: "Unique"
    )

    Unary test syntax is not ambiguous, so supporting it would mean to basically change rule 2 in the grammar to include rules 14 and 17 as possible options. The semantic mapping table on page 116 would also need to include a new FEEL value type: "unary test".

  • Reported: DMN 1.1 — Tue, 23 Aug 2016 01:41 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

Include Test Cases in Decision Model

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

    For interchange of test cases along with a decision model, it would be convenient to define metamodel and xsd elements for a suite of test cases, where a test case contains values for input data and expected values output decisions.

  • Reported: DMN 1.1 — Sat, 28 May 2016 16:25 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:

Change depiction of Input to be harmonized with BPMN and CMMN


XSD: global context

  • Key: DMN14-7
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    10.3.2.9.2 says "The global context is a context provided for convenience and 'pre-compilation'. Any number of expressions can be named and represented in a FEEL context m. The syntactic description m of this context can be evaluated once, that is, mapped to the FEEL domain as m, and then re-used to evaluate many expressions." For example, you might want to put a Relation used as a multi-dimensional constant in the global context. Or you might want to put a reusable function definition in the global context. Currently the xsd does not have globals. All expressions are bound to a specific drgElement, not global. The Import element probably needs to be modified to support this also.

  • Reported: DMN 1.0 — Sun, 31 May 2015 16:35 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

Business Knowledge Model can have Information Requirements

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

    FEEL function definitions are defined as lexical closures, which simply means that names in the function body must be in scope, and that scope includes the function parameters and, just like any other decision logic, it includes the information requirements and the knowledge requirements. This is very handy. For example, it allows the logic of a BKM to reference 100 Input Data items by name, without requiring that each invocation pass in 100 parameter bindings.

    In order for this to work, the BKM would model 100 Information Requirements on the 100 Input Data items, instead of modeling them as parameters. The boxed invocations would not have 100 rows of repetitive binding information. We must extend the MM and Table 2 to allow a BKM to have information requirements.

  • Reported: DMN 1.0 — Thu, 23 Jul 2015 23: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

italics and bold used for both typographic literal notation and FEEL semantic exposition

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

    in typographic literals, italics are strings and bold italics are date literals, but in 10.3, italics are feel syntactic elements and bold are semantic elements. Better to have different notations

  • Reported: DMN 1.0 — Thu, 3 Sep 2015 15:58 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

No notation for ItemDefinition

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

    The notion of a 'type' or ItemDefinition is in the metamodel (with some pending issues) and in the semantics and concepts, but little is in the notation. Thus, we have notation that allows you to execute an expression with actual arguments, but no notation to allow validation based on type information without actual values.

    We have most of the pieces, so it should not be difficult. E.g., individual values can be number, string, date and time, etc. We can allow numeric ranges using our unary tests, e.g. '>0', '[10..30)', etc. We can allow LOVs using "abc", "def", "ghi". These can be 'simple items', and we can also define structures using something similar to boxed contexts.

  • Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 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

Business Context links go both ways

  • Key: DMN14-2
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In XSD, business context pointers are duplicated in both directions. E.g. decisionOwner and decisionMaker point to organizationalUnit, which in turns has pointers back the other way. This duplication adds no new information, just potential for internal inconsistency. I suggest omitting one of these directions; the other one is easily extracted from the serialization by XPATH.

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 17: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

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

Unspecified conclusion is not supported

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

    I remember discussions about allowing "-" in conclusions to mark an unspecified conclusion in a decision table. This would allow some of the conclusions in a multiple output decision table to be marked as "unspecified" where there was no output relevant for that conclusion for a specific rule and to allow rules in multi-hit tables to show that a particular combination of conditions had been considered but did not result in anything being added to the result set.
    However the standard as written says that an output entry must adhere to the literal expression grammar, and '-' is not allowed. You have to return some FEEL value, e.g. 0, false, "N/A", null, etc.

  • Reported: DMN 1.1 — Mon, 13 Jun 2016 21:41 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

notion of arbitrary order conflicts with lack of an unordered collection data type

  • Key: DMN14-40
  • Status: closed  
  • Source: Signavio GmbH ( Dr. Bastian Steinert)
  • Summary:

    Section "8.2.11 Hit policy" describes that hit policy "Collect: returns all hits in arbitrary order". This implies that the order of the results does not have to be deterministic and can also vary among different implementations. However, the standard only supports the notion of 'lists', which do have an order. The comparison of lists is also specified in a way that the order of elements is significant. The issue might get more clear when thinking about testing the interface of decisions. Strictly speaking, it is currently not feasible to define a test against a decision table with hit policy 'collect'. The expected result can only be defined using a list, whose elements do have an order. The operator to compare the 'expected' and the 'actual' result will also take order into account.

    The issue could easily be resolved by replacing 'arbitrary order' with 'rule order'.

  • Reported: DMN 1.1 — Sun, 26 Jun 2016 10:11 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

need set operations and equality in FEEL

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

    some notes toward a proper description:
    FEEL has ordered lists and some set builtins, e.g. distinct values and union. Lacks intersection and equality.

    [1,2] in (1,2,[1,2], 3) is true

    intersect([1,2,3], [3,1,4]) = [1,3]

    set equals([1,1,3], [3,1]) is true
    probably - distinct values([1,1,3]) = distinct values([3,1])
    maybe change to set([1,1,3]) = set([3,1])
    (set needs to both remove dups and return elements in canonical order)
    what is canonical order [null, 0, {}, []]?
    [1,3] = [3,1] is false

    Another option is to add sets to FEEL semantic domain (along with lists, numbers, contexts, ...). And need syntax.

    simpler and more biz friendly proposal - add 'contains any' and 'contains all' as boolean infix operators taking 2 lists as LHS and RHS. And allow these to be added to unary tests w/o a '?'. E.g. 1,2,3 , in (1,2,3) , contains any (1,2,3), contains all (1,2,3). First 2 are what we have now (2nd allowed for symmetry). Last 2 assume input expr is a list (set).

    if we just add set oriented builtins, but no friendlier syntax, this may not solve the biz problem of allowing DTs to process sets in a user friendly way. Too many ()s and ?s

  • Reported: DMN 1.1 — Thu, 11 Aug 2016 15:35 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

In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement

  • Key: DMN14-38
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement

  • Reported: DMN 1.1 — Wed, 24 Aug 2016 16:45 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

Collect decision tables

  • Key: DMN14-37
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    (1) The spec says "Collect: returns all hits in arbitrary order. An operator (‘+’, ‘<’, ‘>’, ‘#’) can be added to apply a simple function to the outputs. If no operator is present, the result is the list of all the output entries.". This is confusing - as I understand it if an operator is present a collect hit policy does not return all hits, only the result of the operation.

    (2) The spec should state clearly what result is returned by Collect decision tables when no rules fire. In particular the result of a C+ decision table is not clear, because the result of sum([]) is undefined. I think a case could be made (based on a recursive definition) that the sum of an empty list is zero, which would be a much more useful result from the decision table than null. In general, section 10.3.4.4 restricts the semantics of all list functions to non-empty lists, although some functions have natural and useful results for the empty list e.g. count([])=0, sum([])=0, sublist([],x,y)=[], append([],items)=[items], concatenate([],items)=items, reverse([])=[], union([],items)=[], distinct values([])=[], flatten([])=[].

    (3) Why is the result of C+ defined as "sum of all the distinct outputs" rather than just "sum of all the outputs"? I would say that if three rules fire proposing the value 5, the C+ result should be 15, not 5.

  • Reported: DMN 1.1 — Thu, 13 Oct 2016 08:25 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

Metamodel constraints & validation

  • Key: DMN14-35
  • Status: closed  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    None of the metamodels contain logic constraints. For example, the name of a decision table is the same with the name of the variable defined inside of the decision table tag (invariant at decision table level).

    Ideally these constrains would be used to validate the diagrams before execution (e.g. generating code from Java). Bruce Silver's already covers some of the. We should add them and more in the spec.

    I think the metamodel constraints should be described with OCL – see the UML metamodels. There should be constraints for CL1, CL2 and CL3. It’s very likely the CL3 constraints will be a superset of CL2 constraints.

  • Reported: DMN 1.1 — Sun, 30 Oct 2016 11:45 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

Requested additional built-in functions

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

    (from Bruce)
    a. String-join(stringList, separatorString)

    b. Format-number(value, formatString), where formatString (to be negotiated) generally follows Excel or xpath, maybe not all the features.

    c. Format-date(value, formatString), format-dateTime(value, formatString)

  • Reported: DMN 1.1 — Mon, 2 Jan 2017 20: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

Semantic domain mapping for simple expressions

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

    The FEEL grammar contains simple expressions as starting terminal

    page 107 6. simple expressions = simple expression ,

    { "," , simple expression }

    ;

    I could not find a mapping to a semantics domain for it. What is the type / domain of "simple expressions"? A list with element type Any or a Tuple Type with several element types?

  • Reported: DMN 1.1 — Fri, 17 Mar 2017 14:42 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

Improvement of Semantic Domains Specification

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

    The definition of Semantic Domains / Types in 10.3.2 does not contain:

    • a metamodel
    • relationships between various types

    I propose adding a metamodel and the following two relationship:

    1. Conforms To
    A semantic domain T1 conforms to a semantic domain T2 when an instance of T1 can be substituted at each place where an instance of T2 is expected.

    2. Equivalent To
    A semantic domain T1 is equivalent to a domain T2 iff they have the same name and the corresponding embedded semantic domains are equivalent. (e.g. List<Number> is equivalent only to List<Number> not List <String>).

    The above relationships should be defined via tables, similar to the ones used to describe the semantics of logic operators (page 119 Table 38).

  • Reported: DMN 1.1 — Thu, 30 Mar 2017 12: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
  • Attachments:

Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122

  • Key: DMN14-31
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    on page 122 in table 43 in row 2 and 3: "e1 in [e2, e3, ...]"
    on page 109 grammar rule 51.c: expression "in" positive unary test
    on page 109 grammar rule 51.c: expression "in" "(" positive unary tests ")"

    The syntax with square brackets is not allowed by the grammar rules 51.c. Either table 43 or grammar definition should be changed.

  • Reported: DMN 1.1 — Wed, 3 May 2017 08:58 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

Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test

  • Key: DMN14-30
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    For simple positive unary test(s) there are extra entry points in the FEEL grammar. Therefore why do we need simple positive unary test in grammar rule 2.i. What is the semantic mapping?

  • Reported: DMN 1.1 — Wed, 3 May 2017 09:11 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

Should name declarations in same context fail or overwrite?

  • Key: DMN14-29
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    As I see the spec doesn't define what should happen if in a context a name should be declared that already exists in the current context. Sample FEEL expression: "for i in [1,2,3], i in [4,5,6] return i * i" Does the second definition of i overwrite the first one or should we return null for the complete "for" expression?

  • Reported: DMN 1.1 — Wed, 3 May 2017 09:25 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

Can an expression in user defined function body reference a name outside of it's scope?

  • Key: DMN14-28
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    If an expression in a user defined function body references a name outside of it's scope (for example a parent scope), this scope must be available also during invocation of the function.

    Examples:

    • {f:function() a, a:1, i:f()}

      possible, since name a is still available in local context (scope) during invocation

    • {b:1,f:function() b}

      .f() impossible, since name b is not available outside of the context.

    It would be nice if the semantic mapping and the differentiation between function definition and invocation is clearly specified in the spec. What names can be referenced? Must the scopes also be available during invocation?

  • Reported: DMN 1.1 — Wed, 3 May 2017 15:24 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

How to get FEEL type if evaluation is not an option?

  • Key: DMN14-27
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    in chapter 10.3.2.10: "Sometimes we do not want to evalutate a FEEL expression e, we just want to know the type of e."

    in table 54: column Applicability defines which row in the table to use, depending on the type of a FEEL expression.

    Table 54 only makes sense if it is not allowed to pre-evaluate the expression e2, since even for a pre-evaluation context entries (for example: "item") must be declared in scope.

    How do we know the type of a FEEL expression if it is not allowed to evaluate it?

    Examples:

    • [1,2,3][min(3,2,1)]
    • {a:function() external {java: {class: "clazz", method signature: "method()"}}, b:[1,2,3][a()]}.b
    • {a: 1, b: a instance of number, c: [1,2,3][b] }
  • Reported: DMN 1.1 — Wed, 3 May 2017 14:56 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

Scope of decision table input/output entries is not well defined in the specification

  • Key: DMN14-26
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    While the scope of context entry specifically says to include the previous context entry (section 7.3.1), there is no mention for the scope of input and output entries of decision tables.

  • Reported: DMN 1.1 — Mon, 15 May 2017 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

More Generic Ways to Define Decision Table Properties


FEEL grammar readbility

  • Key: DMN14-24
  • Status: closed  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    The grammar contains several sub-grammars each one with its own start non-terminal: expression, simple expressions, unary tests.

    The grammar should be broken in several grammars, and common part to make things more obvious. It will help the CL3 implementation.

  • Reported: DMN 1.1 — Sun, 30 Oct 2016 11:37 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

No adjustment for last day in month if duration is added/subtracted to date and time value

  • Key: DMN14-15
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    The specification says that the addition/subtraction of a date and time and a years and months duration value is defined as:

    date and time (
       date(e1.year +/– e2.years + floor((e1.month+/– e2.months)/12),
       e1.month +/– e2.months – floor((e1.month +/– e2.months)/12) * 12,
       e1.day), 
       time(e1))
    

    If you apply this expression to the following two values:

    • date and time("2017-08-30T11:00:00Z")
    • duration("P18M")
      you would expect the following results:
    date and time("2017-08-30T11:00:00Z") + duration("P18M")  --> result should be date and time("2019-02-28T11:00:00Z")
    date and time("2017-08-30T11:00:00Z") - duration("P18M")  --> result should be date and time("2016-02-29T11:00:00Z")
    

    If you apply the values to the defined formula, you get:

    date and time (
       date(2017 +/– 1 + floor((8 +/– 6)/12),
       8 +/– 6 – floor((8 +/– 6)/12) * 12,
       30), 
       time("11:00:00Z"))
    

    Addition
    which results for addition into:

    date and time (
       date(2018 + floor(1,1667),
       14 – floor(1,1667) * 12,
       30), 
       time("11:00:00Z"))
    

    which is:

    date and time (date(2019, 2, 30), time("11:00:00Z"))
    

    The adjustment to the last valid day in a month is missing. 30th February is invalid, since February has only 28/29 days.

    Subtraction
    which results for subtraction into:

    date and time (
       date(2016 + floor(0,1667),
       2 – floor(0,1667) * 12,
       30), 
       time("11:00:00Z"))
    

    which is:

    date and time (date(2016, 2, 30), time("11:00:00Z"))
    

    The adjustment to the last valid day in a month is missing. 30th February is invalid, since February has only 28/29 days.

    Recommendation:
    Adjustment to last valid day in month must be added to spec.

  • Reported: DMN 1.1 — Mon, 2 Oct 2017 12:41 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

Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.

  • Key: DMN14-69
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.
    UnaryTest should be added to the diagram.

  • Reported: DMN 1.3 — Wed, 1 Jan 2020 00:23 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

Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression

  • Key: DMN14-70
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression. The figure should be updated.
    This is similar to the issue for Figure 6-10, which has the same problem.

  • Reported: DMN 1.3 — Wed, 1 Jan 2020 00:21 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

No way to show relative multiplicity of decisions and their information requirements

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

    Item Definitions are hierarchical so the top level one in an Input Data or a Decision might not be a collection while one or more of those contained are. This means that there may be a collection to process even if the Input Data or Decision is not marked as a collection (see DMN14-123 for this separate issue). It should be possible to show both "fan in" where multiple instances of the source of the requirement are used by a single instance of a decision and "fan-out" when the source of requirement contains a collection which will be processed one at a time by the decision.

  • Reported: DMN 1.3 — Wed, 24 Feb 2021 05:36 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Wed, 15 Dec 2021 21:12 GMT
  • Attachments: