Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN15-6 Depiction of Input Data is not harmonized with BPMN and CMMN DMN 1.1 DMN 1.5 Resolved closed
DMN15-27 Improvement of Semantic Domains Specification DMN 1.1 DMN 1.5 Closed; No Change closed
DMN15-13 Clarification needed if null is passed as value for optional parameter of built in function DMN 1.1 DMN 1.5 Deferred closed
DMN15-12 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.5 Deferred closed
DMN15-7 Include Test Cases in Decision Model DMN 1.1 DMN 1.5 Deferred closed
DMN15-18 Enumerations can only be defined as strings DMN 1.1 DMN 1.5 Closed; Out Of Scope closed
DMN15-31 Collect decision tables DMN 1.1 DMN 1.5 Deferred closed
DMN15-23 Can an expression in user defined function body reference a name outside of it's scope? DMN 1.1 DMN 1.5 Deferred closed
DMN15-30 Metamodel constraints & validation DMN 1.1 DMN 1.5 Deferred closed
DMN15-15 Can the same Definitions/namespace be used by more than one model? DMN 1.1 DMN 1.5 Deferred closed
DMN15-26 Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122 DMN 1.1 DMN 1.5 Deferred closed
DMN15-24 Should name declarations in same context fail or overwrite? DMN 1.1 DMN 1.5 Deferred closed
DMN15-25 Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test DMN 1.1 DMN 1.5 Deferred closed
DMN15-28 Semantic domain mapping for simple expressions DMN 1.1 DMN 1.5 Deferred closed
DMN15-11 No adjustment for last day in month if duration is added/subtracted to date and time value DMN 1.1 DMN 1.5 Deferred closed
DMN15-8 Enhancement suggestion: make unary tests first class citizens of the FEEL language DMN 1.1 DMN 1.5 Deferred closed
DMN15-16 Add two new concrete numeric types, make number abstract DMN 1.1 DMN 1.5 Deferred closed
DMN15-17 Lexical representation of time string has ambiguous definitons DMN 1.1 DMN 1.5 Deferred closed
DMN15-22 How to get FEEL type if evaluation is not an option? DMN 1.1 DMN 1.5 Deferred closed
DMN15-20 More Generic Ways to Define Decision Table Properties DMN 1.1 DMN 1.5 Deferred closed
DMN15-19 FEEL grammar readability DMN 1.1 DMN 1.5 Deferred closed
DMN15-32 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.5 Deferred closed
DMN15-21 Scope of decision table input/output entries is not well defined in the specification DMN 1.1 DMN 1.5 Deferred closed
DMN15-14 Improve description of built-in function string() DMN 1.1 DMN 1.5 Deferred closed
DMN15-9 Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions DMN 1.1 DMN 1.5 Deferred closed
DMN15-29 Requested additional built-in functions DMN 1.1 DMN 1.5 Deferred closed
DMN15-33 need set operations and equality in FEEL DMN 1.1 DMN 1.5 Deferred closed
DMN15-34 notion of arbitrary order conflicts with lack of an unordered collection data type DMN 1.1 DMN 1.5 Deferred closed
DMN15-35 Unspecified conclusion is not supported DMN 1.1 DMN 1.5 Deferred 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-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-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-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-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
DMN12-27 Lack of visual notation for processing of / iteration over lists DMN 1.1 DMN 1.2 Deferred closed
DMN13-21 DMN v1.2 specification DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-19 ranges do not map to the semantic domain DMN 1.1 DMN 1.3 Duplicate or Merged closed
DMN13-29 mix up of list and non-list in filter expression example DMN 1.1 DMN 1.3 Resolved closed
DMN13-59 FEEL does not support named ranges DMN 1.1 DMN 1.3 Duplicate or Merged closed
DMN13-35 Equality for date, date and time, time and inequality for date doesn't use the value function, which make the <= and >= operations useless and = operation behaves differently as < and > DMN 1.1 DMN 1.3 Resolved closed
DMN13-34 Imprecise result for example calculation of function PMT and may be typo or rounding issue DMN 1.1 DMN 1.3 Resolved closed
DMN13-56 string built-in underspecified DMN 1.1 DMN 1.3 Duplicate or Merged closed
DMN13-75 Case-aware and case-insensitive DMN 1.1 DMN 1.3 Closed; Out Of Scope closed
DMN13-40 Need additional FEEL Types DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-41 Ambiguity between qualified name and path operation DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-37 Specification of type for instance of operator misses information DMN 1.1 DMN 1.3 Resolved closed
DMN13-45 Missing semantic specification for FEEL for and quantified expression DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-53 Can listed input data option be used in encapsulated decisions of decision service? DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-13 Expressions in Input Entries DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-66 Missing "date" FEEL type in some enumerations DMN 1.1 DMN 1.3 Resolved closed
DMN13-67 Broken HTTP links DMN 1.1 DMN 1.3 Resolved closed
DMN13-72 Description of Table 44 is out of place DMN 1.1 DMN 1.3 Resolved closed
DMN13-23 Remove rule#32 additional name symbols from BNF DMN 1.1 DMN 1.3 Closed; Out Of Scope closed
DMN13-62 Missing FEEL namespace in the header of the xml sample DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-61 Typo in the sample xml DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-64 Broken HTTP links DMN 1.1 DMN 1.3 Duplicate or Merged closed
DMN13-57 Additional name symbols DMN 1.1 DMN 1.3 Closed; Out Of Scope closed
DMN13-60 SFEEL grammar readbility DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-63 Naming inconsistency DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-77 Figure 70 does not correspond to example file DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-42 Is really only name allowed in a FEEL path? DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-49 FEEL grammar is ambiguous for grammar rule 2.i simple positive unary test when no operator is specified for an endpoint DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-51 Page 71 states that a DT can have 0 inputs. I believe this to be incorrect DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-54 Bug in specification of the ‘Any’ Hit Policy DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-14 FEEL operators in names DMN 1.1 DMN 1.3 Closed; Out Of Scope closed
DMN13-11 Decisions can be used for many things, do we need a taxonomy? DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-58 Spaces and additional characters in names / identifiers DMN 1.1 DMN 1.3 Closed; Out Of Scope closed
DMN13-70 null is not defined in the S-FEEL grammar DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-74 Semantics of variable in decision table input entry DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-26 Clarification needed if null is passed as value for optional parameter of built in function DMN 1.1 DMN 1.3 Deferred closed
DMN13-25 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.3 Deferred closed
DMN13-24 No adjustment for last day in month if duration is added/subtracted to date and time value DMN 1.1 DMN 1.3 Deferred closed
DMN13-27 Improve description of built-in function string() DMN 1.1 DMN 1.3 Deferred closed
DMN13-36 FEEL grammar readbility DMN 1.1 DMN 1.3 Deferred closed
DMN13-32 Lexical representation of time string has ambiguous definitons DMN 1.1 DMN 1.3 Deferred closed
DMN13-38 More Generic Ways to Define Decision Table Properties DMN 1.1 DMN 1.3 Deferred closed
DMN13-39 Scope of decision table input/output entries is not well defined in the specification DMN 1.1 DMN 1.3 Deferred closed
DMN13-43 How to get FEEL type if evaluation is not an option? DMN 1.1 DMN 1.3 Deferred closed
DMN13-18 Enhancement suggestion: make unary tests first class citizens of the FEEL language DMN 1.1 DMN 1.3 Deferred closed
DMN13-17 Enhancement suggestion: allow for expressions to be used as "end points" DMN 1.1 DMN 1.3 Deferred closed
DMN13-16 Include Test Cases in Decision Model DMN 1.1 DMN 1.3 Deferred closed
DMN13-15 Change depiction of Input to be harmonized with BPMN and CMMN DMN 1.1 DMN 1.3 Deferred closed
DMN13-12 Lack of visual notation for processing of / iteration over lists in DRD DMN 1.1 DMN 1.3 Deferred closed
DMN13-28 Can the same Definitions/namespace be used by more than one model? DMN 1.1 DMN 1.3 Deferred closed
DMN13-31 Add two new concrete numeric types, make number abstract DMN 1.1 DMN 1.3 Deferred closed
DMN13-33 Formally define enumerations and use throughout DMN 1.1 DMN 1.3 Deferred closed
DMN13-20 Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions DMN 1.1 DMN 1.3 Deferred closed
DMN13-30 Wrong character in expression for PMT function definition DMN 1.1 DMN 1.3 Deferred closed
DMN13-55 Requested additional built-in functions DMN 1.1 DMN 1.3 Deferred closed
DMN13-69 Collect decision tables DMN 1.1 DMN 1.3 Deferred closed
DMN13-68 FEEL ambiguity DMN 1.1 DMN 1.3 Deferred closed
DMN13-71 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.3 Deferred closed
DMN13-73 need set operations and equality in FEEL DMN 1.1 DMN 1.3 Deferred closed
DMN13-76 notion of arbitrary order conflicts with lack of an unordered collection data type DMN 1.1 DMN 1.3 Deferred closed
DMN13-78 Unspecified conclusion DMN 1.1 DMN 1.3 Deferred closed
DMN13-79 We need a way to identify current date and time. I propose Now() DMN 1.1 DMN 1.3 Deferred closed
DMN13-44 Can an expression in user defined function body reference a name outside of it's scope? DMN 1.1 DMN 1.3 Deferred closed
DMN13-46 Should name declarations in same context fail or overwrite? DMN 1.1 DMN 1.3 Deferred closed
DMN13-47 Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test DMN 1.1 DMN 1.3 Deferred closed
DMN13-48 Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122 DMN 1.1 DMN 1.3 Deferred closed
DMN13-50 Improvement of Semantic Domains Specification DMN 1.1 DMN 1.3 Deferred closed
DMN13-52 Semantic domain mapping for simple expressions DMN 1.1 DMN 1.3 Deferred closed
DMN13-65 Metamodel constraints & validation DMN 1.1 DMN 1.3 Deferred closed
DMN12-29 Generalized Unary Tests DMN 1.1 DMN 1.2 Resolved closed
DMN12-188 semantics of import is unspecified DMN 1.1 DMN 1.2 Resolved closed
DMN12-131 Execution Semantics of Decision Services does not explain imported elements DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-216 Confusing semantics of ItemDefinitons DMN 1.1 DMN 1.2 Resolved closed
DMN12-250 Formatting problems in Ballot 15 convenience doc DMN 1.1 DMN 1.2 Closed; No Change closed
DMN12-183 Missing type names in FEEL functions (user and external) DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-119 Support for function calls in unary tests DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-280 Missing RuleAnnotation attributes and model associations table DMN 1.1 DMN 1.2 Resolved closed
DMN12-223 Limitations of FEEL for..in..return DMN 1.1 DMN 1.2 Resolved closed
DMN12-79 Typo in sublist() function example DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-41 FEEL + operator semantics operand-dependent DMN 1.1 DMN 1.2 Closed; Out Of Scope closed
DMN12-40 Spaces in FEEL builtin functions DMN 1.1 DMN 1.2 Closed; Out Of Scope closed
DMN12-70 Chapter 11 example serialization has many errors DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-155 Supporting text about Expression lists non-existing name attribute DMN 1.1 DMN 1.2 Resolved closed
DMN12-143 Inconsistencies between metamodel and xsd schema DMN 1.1 DMN 1.2 Resolved closed
DMN12-210 Expected behavior for list/sort built-in functions in combination with singleton lists DMN 1.1 DMN 1.2 Resolved closed
DMN12-248 Missing attribute isExpanded for DecisionService DI DMN 1.1 DMN 1.2 Resolved closed
DMN12-229 Chapter 11 example in specification does not match file ch11example.xml and ch11example.xml contains errors DMN 1.1 DMN 1.2 Resolved closed
DMN12-186 Wrong length range check for built-in function sublist() and substring() DMN 1.1 DMN 1.2 Resolved closed
DMN12-46 Wrong numbering in S-FEEL syntax DMN 1.1 DMN 1.2 Resolved closed
DMN12-45 Remove tight coupling with BPMN and BMM DMN 1.1 DMN 1.2 Closed; Out Of Scope closed
DMN12-55 Attributes in tables 29a and 29b do not correspond to metamodel Fig 51 DMN 1.1 DMN 1.2 Resolved closed
DMN12-23 typeRef from tables 10 and 15 not in figures 20 and 23 DMN 1.1 DMN 1.2 Resolved closed
DMN12-176 Decision Table hit policies C and C# should not return null when there are no matches DMN 1.1 DMN 1.2 Resolved closed
DMN12-286 FEEL versions cannot be distinguished DMN 1.1 DMN 1.2 Resolved closed
DMN12-190 DMN built-in functions are missing to ensure business friendliness DMN 1.1 DMN 1.2 Resolved closed
DMN12-231 Import is lacking extension capability DMN 1.1 DMN 1.2 Resolved closed
DMN12-94 Problem with QName usage in typeRef DMN 1.1 DMN 1.2 Resolved closed
DMN12-74 Issues with Table 61 DMN 1.1 DMN 1.2 Resolved closed
DMN12-282 Missing annotation in Decision Table in DMN XSD DMN 1.1 DMN 1.2 Resolved closed
DMN12-203 Wrong chapter reference for date and time / date and time subtraction DMN 1.1 DMN 1.2 Resolved closed
DMN12-201 Type should be specified for date, time and duration properties DMN 1.1 DMN 1.2 Resolved closed
DMN12-38 Show diagram elements with hidden links DMN 1.1 DMN 1.2 Resolved closed
DMN12-272 Allow DMN DI to provide an alternative notation for Input Data (DMN 1.2) DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-126 Chapter 11 example decision tables are incomplete DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-262 Please clarify what is the result of a filter with non-boolean expressions (null) DMN 1.1 DMN 1.2 Resolved closed
DMN12-246 Lost formatting in 10.3.2.2 Equality, Identity, and Equivalence DMN 1.1 DMN 1.2 Resolved closed
DMN12-217 add weekday property to date, date and time DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-184 Semantic mapping for XML syntactical artifacts DMN 1.1 DMN 1.2 Resolved closed
DMN12-121 Releation between Definitions and DecisionService does not specified in XSD DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-59 Need attribute for human and external decisions DMN 1.1 DMN 1.2 Closed; No Change closed
DMN12-58 Space in FEEL names is not well-specified DMN 1.1 DMN 1.2 Resolved closed
DMN12-37 Dynamic invocation DMN 1.1 DMN 1.2 Closed; No Change closed
DMN12-39 Show implied Information Requirements DMN 1.1 DMN 1.2 Closed; No Change closed
DMN12-28 Graphical representation of Context - "sub-DRDs" DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-47 FEEL 'instance of' operator is underspecified DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-48 SFEEL makes too few people happy DMN 1.1 DMN 1.2 Resolved closed
DMN12-226 Missing support for escape sequences in string literals DMN 1.1 DMN 1.2 Resolved closed
DMN12-129 Would like to use duplicate shapes/names in diagram to avoid multiple requirement line crossings DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-206 Invalid example for date and time property access DMN 1.1 DMN 1.2 Resolved closed
DMN12-133 DRD elements must be labeled with their name DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-78 Impossible to invoke functions and() and or() DMN 1.1 DMN 1.2 Resolved closed
DMN12-89 Label versus name attribute DMN 1.1 DMN 1.2 Resolved closed
DMN12-88 Label of Input in decision table DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-60 FEEL path expression has same precedence as filter and invocation DMN 1.1 DMN 1.2 Resolved closed
DMN12-136 Decision Service Cannot be Shown in DRD DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-225 Transitive information requirements maybe inferred from the spec text DMN 1.1 DMN 1.2 Resolved closed
DMN12-101 Requirements don't have an ID (needed for DI) DMN 1.1 DMN 1.2 Resolved closed
DMN12-43 Drg element labels DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-21 Eliminate () from FEEL and S-FEEL DMN 1.1 DMN 1.2 Closed; No Change closed
DMN12-134 Add id to context entry DMN 1.1 DMN 1.2 Resolved closed
DMN12-68 DMN 1.1 XML schema starts with ZERO WIDTH NO-BREAK SPACE (U+FEFF) DMN 1.1 DMN 1.2 Resolved closed
DMN12-33 Scope of Variables in Context Boxed Expression DMN 1.1 DMN 1.2 Resolved closed
DMN12-87 some/every ... satisfies not defined for empty list DMN 1.1 DMN 1.2 Resolved closed
DMN12-211 Table 45 does not provide the semantic of addition and subtraction between elements of type Date and Duration DMN 1.1 DMN 1.2 Resolved closed
DMN12-162 FEEL precedence for function definition DMN 1.1 DMN 1.2 Resolved closed
DMN12-160 Metamodel is missing the "kind" attribute on function DMN 1.1 DMN 1.2 Resolved closed
DMN12-124 Return All Annotations for All Hit Policies DMN 1.1 DMN 1.2 Resolved closed
DMN12-195 Parameter names of built-in function date and time(date, time) are not allowed by name rules DMN 1.1 DMN 1.2 Resolved closed
DMN12-189 Table 45 does not provide the semantic of addition and subtraction between two elements of type date DMN 1.1 DMN 1.2 Resolved closed
DMN12-141 Unclear meaning of unique name constraint for ItemDefinitions and DRGElements DMN 1.1 DMN 1.2 Resolved closed
DMN12-187 Parameter domain for built-in function years and months duration() is wrong DMN 1.1 DMN 1.2 Resolved closed
DMN12-84 Decision table is not a good example of a builtin function DMN 1.1 DMN 1.2 Resolved closed
DMN12-83 X and TBD are undefined in Table 35 DMN 1.1 DMN 1.2 Resolved closed
DMN12-86 grammar rule 56 missing comma DMN 1.1 DMN 1.2 Resolved closed
DMN12-175 Different definition of hit policy collect aggregations in FEEL and DMN DMN 1.1 DMN 1.2 Resolved closed
DMN12-137 clarify format of time literals / resolve inconsistency DMN 1.1 DMN 1.2 Resolved closed
DMN12-148 decision table structure in 8.1 does not agree with MM DMN 1.1 DMN 1.2 Resolved closed
DMN12-149 Output Order hit policy on pg 85 is incorrect DMN 1.1 DMN 1.2 Resolved closed
DMN12-144 Add specification for DMN diagrams layout DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-138 Duplicate definition of BKM/@variable in Table 14 DMN 1.1 DMN 1.2 Resolved closed
DMN12-127 Missign Comma in Grammar Rule 48 (some/every...) DMN 1.1 DMN 1.2 Resolved closed
DMN12-103 singular helping verb used with plural subject DMN 1.1 DMN 1.2 Resolved closed
DMN12-36 Alternative DRD representation of BKM DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-32 Expressions in Input Entries DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-31 Collection Operators DMN 1.1 DMN 1.2 Duplicate or Merged closed
DMN12-24 Table 47 should specify duration/duration rather than number/duration DMN 1.1 DMN 1.2 Resolved closed
DMN12-53 Missing comma to split “in” in quantified expression in FEEL syntax DMN 1.1 DMN 1.2 Resolved closed
DMN12-42 FEEL operators in names DMN 1.1 DMN 1.2 Deferred closed
DMN12-30 Expressions in Input Entries DMN 1.1 DMN 1.2 Deferred closed
DMN12-260 ranges do not map to the semantic domain DMN 1.1 DMN 1.2 Deferred closed
DMN12-80 Enhancement suggestion: allow for expressions to be used as "end points" DMN 1.1 DMN 1.2 Deferred closed
DMN12-49 Include Test Cases in Decision Model DMN 1.1 DMN 1.2 Deferred closed
DMN12-44 Change depiction of Input to be harmonized with BPMN and CMMN DMN 1.1 DMN 1.2 Deferred closed
DMN12-25 Decisions can be used for many things, do we need a taxonomy? DMN 1.1 DMN 1.2 Deferred closed
DMN12-81 Enhancement suggestion: make unary tests first class citizens of the FEEL language DMN 1.1 DMN 1.2 Deferred closed
DMN12-77 DMN v1.2 specification DMN 1.1 DMN 1.2 Deferred closed

Issues Descriptions

Depiction of Input Data is not harmonized with BPMN and CMMN


Improvement of Semantic Domains Specification

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

    Resolved already

    Resolved in an earlier version already when we introduced the type lattice.

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

Clarification needed if null is passed as value for optional parameter of built in function

  • Key: DMN15-13
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

  • Key: DMN15-12
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Include Test Cases in Decision Model

  • Key: DMN15-7
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Enumerations can only be defined as strings

  • Key: DMN15-18
  • 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: Closed; Out Of Scope — DMN 1.5
  • Disposition Summary:

    Not an issue in practice

    It sounds like nobody is really affected by this.
    Most users define a string item definition with a list of allowed values.
    Developers sometimes expect to feed a Java enumeration into a string resulting in an error. But most users invoke decisions via JSON data, e.g. because of invocation via REST or JSON being the data model of a BPMN engine.

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

Collect decision tables

  • Key: DMN15-31
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

  • Key: DMN15-23
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Metamodel constraints & validation

  • Key: DMN15-30
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

  • Key: DMN15-15
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

  • Key: DMN15-26
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Should name declarations in same context fail or overwrite?

  • Key: DMN15-24
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

  • Key: DMN15-25
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Semantic domain mapping for simple expressions

  • Key: DMN15-28
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

  • Key: DMN15-11
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

  • Key: DMN15-8
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Add two new concrete numeric types, make number abstract

  • Key: DMN15-16
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Lexical representation of time string has ambiguous definitons

  • Key: DMN15-17
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

  • Key: DMN15-22
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

More Generic Ways to Define Decision Table Properties


FEEL grammar readability

  • Key: DMN15-19
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

  • Key: DMN15-32
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

  • Key: DMN15-21
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Improve description of built-in function string()

  • Key: DMN15-14
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions

  • Key: DMN15-9
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Requested additional built-in functions

  • Key: DMN15-29
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

need set operations and equality in FEEL

  • Key: DMN15-33
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

  • Key: DMN15-34
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Unspecified conclusion is not supported

  • Key: DMN15-35
  • 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.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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:

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

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

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


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

Lack of visual notation for processing of / iteration over lists

  • Key: DMN12-27
  • 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.2
  • Disposition Summary:

    No workable proposal after several discussions over 2 years

    How should iteration be visualized at the logic level and at the requirements level?

  • Updated: Tue, 23 Feb 2021 17:54 GMT
  • Attachments:

DMN v1.2 specification


ranges do not map to the semantic domain

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

    section 10.3.2.7 Ranges says that ranges map to the semantic domain. But in DMN 1.1, ranges are unary tests and as such, do not map to the semantic domain. Also, the literal context shown is wrong, as you cannot have the entry 'soon' with value of a range (such value would have to map to the semantic domain).
    Now, in DMN 1.2, perhaps we would like to map unary tests to the semantic domain, but it must be all unary tests, and not only ranges.

    Proposed remove section 10.3.2.7

  • Reported: DMN 1.1 — Fri, 6 Apr 2018 17:36 GMT
  • Disposition: Duplicate or Merged — DMN 1.3
  • Disposition Summary:

    Covered by Range builtins

    See DMN13-139

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

mix up of list and non-list in filter expression example

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

    Section 10.3.2.5 includes a few examples for the filter expression. In particular it shows the following example:
    [ {x:1, y:2}, {x:2, y:3} ][x=1] = {x:1, y:2}

    The result of this expression is a context (an object). I first thought this must be a mistake, as the filter expression should always return a list.

    I then found the following sentence: 'Singleton lists are equal to their single item.', showing that the above expression returns a non-list value by intention.

    I wonder how the need for mixing up lists and non-list (with the so called singleton list) has arisen. I have never seem something like it before and I have difficulties to see its value. In addition, I could not find a second sentence in the entire standard that also uses or describes the concept of singleton lists.

    Therefore, I would like to propose removing this single sentence about singleton-lists and would like to change the example to look like this:
    [ {x:1, y:2}, {x:2, y:3} ][x=1] = [{x:1, y:2}]

  • Reported: DMN 1.1 — Tue, 1 Nov 2016 13:03 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Correct the example in 10.3.2.5

    The example on section "10.3.2.5" is missing the list operator in the result.

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

FEEL does not support named ranges

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

    in 10.3.2.7, the literal context example shows third entry where context expression is a unary tests. This is not allowed.

  • Reported: DMN 1.1 — Thu, 10 Nov 2016 16:16 GMT
  • Disposition: Duplicate or Merged — DMN 1.3
  • Disposition Summary:

    Covered by new Range builtins

    See DMN13-139

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

Equality for date, date and time, time and inequality for date doesn't use the value function, which make the <= and >= operations useless and = operation behaves differently as < and >

  • Key: DMN13-35
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    Imagine the following two date and time values (note that both values are the same instant in time on the time line):

    • date and time("2017-11-10T11:00@Europe/Paris")
    • date and time("2017-11-10T10:00Z")

    If the user uses FEEL expressions he is very surprised about the results:

    date and time("2017-11-10T11:00@Europe/Paris") - date and time("2017-11-10T10:00Z")    -> result is PT0S, which means same instant on time line
    date and time("2017-11-10T11:00@Europe/Paris") < date and time("2017-11-10T10:00Z")    -> result is false
    date and time("2017-11-10T11:00@Europe/Paris") > date and time("2017-11-10T10:00Z")    -> result is false
    date and time("2017-11-10T11:00@Europe/Paris") = date and time("2017-11-10T10:00Z")    -> result is false
    

    If the user wants to check if both date and time values are the same instant on the time line he must use the following FEEL expression:

    (date and time("2017-11-10T11:00@Europe/Paris") - date and time("2017-11-10T10:00Z")) = Duration("PT0S")
    

    If the user uses a combination of < or > with = the underlying operations are not really understandable:

    date and time("2017-11-10T11:00@Europe/Paris") >= date and time("2017-11-10T10:00Z")
    

    This expressions says in the curently defined semantics in FEEL: "Is the left instant of time greater than the right instant in time or are the properties of the left value equal to the properties of the right value".

    This is not "Friendly Enough" to the user and the source of very many misunderstandings.

    Recommendation:

    • Therefore the operators =, !=, <, >, <= and >= should ALL use the defined value functions.
    • Additionally we recommend to introduce an additional property "value" for date, time, date and time, years and months duration, days and time duration (see table 53 on page 126). The property returns the value of the value function using type number.
    • Introduce a new built-in function "same properties(value1, value2)" that compares all properties of value1 and value2 for equality. This built-in function reflects the currently specified behaviour of equality for date, date and time, time.
  • Reported: DMN 1.1 — Mon, 2 Oct 2017 10:05 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    use timeline semantics for comparison of dates

    see attached .docx file

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:
    • DMN13-35-v3.docx 17 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Imprecise result for example calculation of function PMT and may be typo or rounding issue

  • Key: DMN13-34
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    In chapter "10.6.5 Invocation of user-defined PMT function" the expected result is mentioned as: 3975.982590125562

    We think that the expected result should be: 3975.982590125552338278440100112431

    If the decimal function would be used the result would be:

    decimal(PMT(requested product.rate, requested product.term, requested product.amount),12) = 3975.982590125552
    

    May be the decimal function is missing?

    Additional issue: In both cases (with or without the usage of decimal()) the 11th position after the decimal point is a 5 and not a 6. Or is there a rounding mistake/issue?

    3975.982590125552

  • Reported: DMN 1.1 — Thu, 12 Oct 2017 09:46 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    fix result of calculation

    The result of the PMT calculation in Section 10.6.5 is incorrect.

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

string built-in underspecified

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

    (from Bruce)
    Table 58 asserts the string constructor operates on any non-null argument, but it does not define the semantics, in particular a)string(list); b)string(complexType). These should either atomize the value and concatenate the strings of the atoms, or report an error or null. Even though Table 58 says null is not in the domain, it also says that string(null)=null. It would make more sense (to me) that string(null)=””.

  • Reported: DMN 1.1 — Mon, 2 Jan 2017 20:05 GMT
  • Disposition: Duplicate or Merged — DMN 1.3
  • Disposition Summary:

    duplicate of dmn13-27

    duplicate of dmn13-27

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

Case-aware and case-insensitive

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

    A number of issues are considering changes to reserved words, built-ins etc. In general these changes should leave the standard case-aware (cases used by a user in naming something should be preserved) but case-insensitive (date is the same as Date and dAte). Any restrictions to names should reflect case insensitivity and interchange should maintain case.

  • Reported: DMN 1.1 — Mon, 18 Jul 2016 17:06 GMT
  • Disposition: Closed; Out Of Scope — DMN 1.3
  • Disposition Summary:

    changing semantics of identifiers is not backward compatible

    changing semantics of identifiers is not backward compatible

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

Need additional FEEL Types

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

    It is possible for a FEEL expression to generate a value with no possible datatype (as they are currently defined). Here are some examples:

    1. If x>0 then x else ‘value must be greater than 0’

    2. [0,’a’]

    3. [0,[1,2]]

    In the first case the result is either a string or a number. In the second case it is a list (collection) where the items are of different types. In the third case, which is more borderline, the collection items include a number and a list, again not the same type. The third case also relates, I believe, to DMN12-115.

    The rules for item definition, in combination with FEEL base types, do not support any of these cases. That means a variable with these values cannot have a typeRef. Some implementations may depend on the typeRef to compile the expression properly, and/or may prevalidate to ensure that a typeRef is provided.

    I suggest one or more of these as possible solutions:

    1. Allow item definition to include a union of existing types, e.g. number or string

    2. Allow typeRef to be a list, e.g. feel:number, feel:string

    3. Add new base type, anyAtomicType, meaning any of the FEEL base types.

  • Reported: DMN 1.1 — Thu, 3 Nov 2016 14:54 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    We support homogeneous list types. Need better justification for heterogeneous list or union types.

    DMN 1.2 adds type lattice, supports homogeneous list types like list<string>, promotes heterogeneous list types to list<Any>, which is good enough, unless more evidence to the contrary is presented.

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

Ambiguity between qualified name and path operation

  • Key: DMN13-41
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    Qualified name and path expression uses both the dot '.' character. Therefore it is very hard to distinguish between these cases.

    Example:

    • {p:{name: "jack"}, persons:[p,p].name}.persons

      results to

      ["jack", "jack"] 
    • {p:{name: "jack"}, persons:[p,p], path : persons.name }.path

      results to

      ["jack", "jack"]

      (or is dynamic path access not possible in FEEL?)

    • {p:{name: "jack"}, persons:[p,p], qn: p.name }.qn

      results to

      "jack"
  • Reported: DMN 1.1 — Wed, 3 May 2017 15:16 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    Not an issue

    All listed FEEL examples are valid FEEL expressions. Example 1 shows a path expression, example 2 a qualified name with an implicit path expression.

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

Specification of type for instance of operator misses information

  • Key: DMN13-37
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    The FEEL syntax allows qualified names as type for an instance of expression. But the semantic mapping is not specified. Therefore, is this a valid FEEL expression:

    {a: {b: 1}, c: 2 instance of a.b}.c

    and this the corresponding result: "true"?

    What types can be used for instance of? Only datatypes (like string, number, ...)? Can we use kinds (list, context, ...), too?

    Since singleton lists are equal to the single element and kinds are allowed for instance of, everything is instance of list, am I right?

  • Reported: DMN 1.1 — Wed, 3 May 2017 09:48 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    clean up specification of types, and add syntax for parametrized context, list, and function types

    see attached documents

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

Missing semantic specification for FEEL for and quantified expression

  • Key: DMN13-45
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    The semantic mapping is not accurately specified for the "in" expression. What datatypes, kinds can be used as iteration source. Only lists and single elements? Is it possible to iterate over context entries of a context? Are there any other datatypes that must be considered?

  • Reported: DMN 1.1 — Wed, 3 May 2017 09:30 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    Issue addressed by "iteration context" added in 1.2

    DMN 1.2 added the notion of "iteration context" and is described in 10.3.2.14. This seems to address the issue.

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

Can listed input data option be used in encapsulated decisions of decision service?

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

    The definition of decision service in 6.2.5 says this:
    _The border SHALL enclose all the
    encapsulated decisions, and no other decisions or input data. The border MAY enclose other DRG elements but these
    will not form part of the definition of the Decision Service._

    This is a problem because it is not possible to omit the Input data if they are input to encapsulated decisions and they use the listed input data option.

  • Reported: DMN 1.1 — Thu, 26 Jan 2017 16:27 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    spec is clear enough

    No change needed. The current spec is clear about listed input data and the use of listed input data in a decision service would be unambiguous and is clearly allowed.

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

Expressions in Input Entries

  • Key: DMN13-13
  • Status: closed  
  • Source: Sapiens Decision NA ( Mr. Gil Ronen)
  • Summary:

    Input Entries are defined as unary tests and as such do not allow even simple expressions. The need to exit the decision table into other FEEL constructs for simple expressions such as “Dividend Income * 0.30” makes the overall logic less readable. There are currently several tools that support expressions in decision table cells and this feature is also on Jan and James’ wishlist. The latter wrote about in more detail (http://blog.luxmagi.com/2016/04/our-dmn-2-0-wish-list-i-decision-logic/) so I won’t repeat it except to quote “This is something we see a lot of demand for by business users of DMN ‘in the field’.”

  • Reported: DMN 1.1 — Thu, 5 May 2016 14:34 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    Support expressions in DT input entries

    This is already supported in DMN 1.2. A positive unary test can be an Expression.

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

Missing "date" FEEL type in some enumerations

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

    FEEL date type is presented in section 10.3.2.3.5 however in some sections of the specification where all FEEL type are enumerated, the date type is omitted.

    • Section 7.3.2
      If the type language is FEEL the built-in types are the FEEL built-in data types: number, string, boolean, days and time duration, years and months duration, time, and date and time.
    • Section 10.3.1.3
      FEEL supports the following datatypes:
      • number
      • string
      • boolean
      • days and time duration
      • years and months duration
      • time
      • date and time
    • In section 10.3.2.12, it is not part of table 42
    • Date is part of S-FEEL and this paragraph from section 9.3 should probably be modified too:
      S-FEEL does not support FEEL date and time. However, it supports the date type, which is like FEEL date and time with hour, minute, and second required to be absent. The lexical and value spaces of FEEL date are the literal and value spaces of the XML Schema date datatype.
  • Reported: DMN 1.1 — Tue, 1 Nov 2016 14:30 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    add missing 'date' type in several places in spec

    see revised text

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

Broken HTTP links


Description of Table 44 is out of place

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

    Most is described after Table 46 Needs to be moved just after Table 44.

  • Reported: DMN 1.1 — Mon, 15 Aug 2016 22:53 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    move 2 paragraphs following Table 46 to before Table 45

    move indicated text

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

Remove rule#32 additional name symbols from BNF

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

    These additional symbols do not provide much more expressiveness for name and may create a lot parsing issues

  • Reported: DMN 1.1 — Thu, 9 Feb 2017 16:13 GMT
  • Disposition: Closed; Out Of Scope — DMN 1.3
  • Disposition Summary:

    non-backward compatible FEEL grammar change

    would need 2.0 RFP

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

Missing FEEL namespace in the header of the xml sample

  • Key: DMN13-62
  • Status: closed  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    The sample provided at http://www.omg.org/spec/DMN/20151101/ch11example.xml contains the following namespaces defined at the root level:

    xmlns:ex="http://www.omg.org/spec/DMN/20151101/ch11example.xml" xmlns="http://www.omg.org/spec/DMN/20151101/dmn.xsd" namespace="http://www.omg.org/spec/DMN/20151101/ch11example.xml"

    FEEL is not included, hence when used to define types it is used as

    <typeRef xmlns:ns2="http://www.omg.org/spec/FEEL/20140401">ns2:number</typeRef>

    Adding it at the root will make the xml more user-friendly.

  • Reported: DMN 1.1 — Sun, 30 Oct 2016 11:32 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    FEEL namespace is in the header of sample XML files in DMN 1.2

    please verify and let's close

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

Typo in the sample xml

  • Key: DMN13-61
  • Status: closed  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    The sample XML specified on the first of the spec contains a typo.

    Sample is http://www.omg.org/spec/DMN/20151101/ch11example.xml

    Strategy is misspelled. See below:

    <itemDefinition name="Stategy" id="strategy_t">
    <typeRef
    xmlns:ns2="http://www.omg.org/spec/FEEL/20140401">ns2:string</typeRef>
    <allowedValues>
    <text>"BUREAU","DECLINE","THROUGH"</text>
    </allowedValues>
    </itemDefinition>

  • Reported: DMN 1.1 — Sun, 30 Oct 2016 11:28 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    no "Stategy" in DMN 1.2 sample file

    This seems to fixed in 1.2. Please verify, and let's close.

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

Broken HTTP links


Additional name symbols

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

    SFEEL and FEEL grammar are ambiguous due to “additional name symbols”. For example,

    • Person.Loan is a Name or Qualified Name?
    • Loan+123 is a Name or an Expression ?

    I don’t think the “additional name symbols” add much value when it comes to having business friendly name. If we want to keep them, we should use the SQL approach and disambiguate these identifiers with quotation marks. For example, ‘Loan+123’ is an identifier while Loan+123 an expression.

  • Reported: DMN 1.1 — Sun, 30 Oct 2016 11:39 GMT
  • Disposition: Closed; Out Of Scope — DMN 1.3
  • Disposition Summary:

    non-backward compatible FEEL grammar change

    would need a 2.0 RFP

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

SFEEL grammar readbility

  • Key: DMN13-60
  • 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, simple unary tests.

    The grammar should be broken in 3 grammars, and common part to make things more obvious. It will make the grammars more readable and help the CL3 implementation. The spec should also specify for each grammar where it used (e.g. unary tests are used in the Input Entries of a Decision Table etc).

  • Reported: DMN 1.1 — Sun, 30 Oct 2016 11:37 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    SFEEL is deprecated

    No editorial changes for SFEEL

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

Naming inconsistency

  • Key: DMN13-63
  • Status: closed  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    Naming inconsistency in Figure 70.

    Use Pre-bureau instead of Pre-Bureau or change Post-bureau to Post-Bureau.

  • Reported: DMN 1.1 — Sun, 30 Oct 2016 11:35 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    Ch 11 figures are machine-generated in DMN 1.2, should be consistent

    Can someone recheck Ch 11 for consistency, and if OK, let.s close this.

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

Figure 70 does not correspond to example file

  • Key: DMN13-77
  • Status: closed  
  • Source: Mid GmbH ( Joachim Back)
  • Summary:

    The example file http://www.omg.org/spec/DMN/20151101/ch11example.xml with document number dtc/15-11-55 does not correspond to the figure 70 on page 147 in chapter 11.3 of the DMN 1.1 specification with document number formal/2016-06-01.
    The figure shows an information requirement from decision "Bureau call type" to decision "Pre-bureau risk category", while the XML has an information requirement from decision "Bureau call type" to business knowledge model "Pre-bureau risk category table" in line 972.
    The figure shows a knowledge requirement from decision "Routing" to business knowledge model "Routing rules", while the XML has an authority requirement from decision "Routing" to business knowledge model "Routing rules" in lines 1331-1333.
    I suggest to correct the XML example file.

  • Reported: DMN 1.1 — Wed, 15 Jun 2016 14:22 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    Chapter 11 example xml has been fixed

    Fixed in 1.2 (generated from same tool)

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

Is really only name allowed in a FEEL path?

  • Key: DMN13-42
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    The FEEL syntax grammar rule 45 only allows names for a path expression. Is this the real intention or should qualified names be allowed, too?
    Otherwise only top level context entries can be accessed.

    If only name is allowed, the following example is not possible: "{a:{b:1}}.a.b"

  • Reported: DMN 1.1 — Wed, 3 May 2017 14:20 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    submitter agrees there is no issue

    no issue here

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

FEEL grammar is ambiguous for grammar rule 2.i simple positive unary test when no operator is specified for an endpoint

  • Key: DMN13-49
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    FEEL grammar rule 2.i for simple positive unary test is ambiguous if no operator is specified. An endpoint is an simple value which can be a simple literal. Additionally the literal specification in grammar rule 2.i can be also a simple literal. This is ambiguous and should be changed.

  • Reported: DMN 1.1 — Wed, 3 May 2017 08:53 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    ambiguity per se is not a serious issue

    there are other ambiguities that are resolved with semantic checks or other rules.

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

Page 71 states that a DT can have 0 inputs. I believe this to be incorrect

  • Key: DMN13-51
  • Status: closed   Implementation work Blocked
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    3rd bullet enumeration on page 71 says:
    A set of inputs (zero or more). Each input is made of an input expression and a number of input entries.The
    specification of input expression and all input entries is referred to as the input clause.

    I blieve it should read:
    A set of inputs (one or more). Each input is made of an input expression and a number of input entries.The
    specification of input expression and all input entries is referred to as the input clause.

  • Reported: DMN 1.1 — Tue, 28 Mar 2017 20:34 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    0 input tables (with collect policy) behave as relations

    may be useful for level 2 implementations

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

Bug in specification of the ‘Any’ Hit Policy

  • Key: DMN13-54
  • Status: closed  
  • Source: Sapiens Decision NA ( Mr. Gil Ronen)
  • Summary:

    The purpose of the ‘Any’ Hit Policy is to allow for overlapping criteria in the rule conditions for the same conclusion. However, each rule also needs to allow for different additional information and messages that are specific to that rule. See attached example decision table. The current text in the specification does not allow for this.

    Currently, ‘Any’ is defined in section 8.2.11 as: “Any: there may be overlap, but all of the matching rules show equal output entries for each output, so any match can be used. If the output entries are non-equal, the hit policy is incorrect and the result is undefined. “

    Proposal to change the above text to: “Any: there may be overlap, but all of the matching rules show equal output entries for the left-most output column, so any match can be used. If the output entries are non-equal for the left-most output column, the hit policy is incorrect and the result is undefined.“

  • Reported: DMN 1.1 — Mon, 9 Jan 2017 15:03 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    DMN 1.2 provides annotation columns as well as result columns

    annotation columns are not considered in hit policy semantics, they can differ for the ANY policy

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

FEEL operators in names

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

    If FEEL variable names can contain spaces, they should not be allowed to contain operator names like and, or, etc. for example the name "make and model" in the Collections of Cars example should not be allowed. It might be possible to determine from the context whether this is a name or an expression of 2names, it's just too hard.

  • Reported: DMN 1.1 — Sat, 14 May 2016 23:31 GMT
  • Disposition: Closed; Out Of Scope — DMN 1.3
  • Disposition Summary:

    non-backward compatible FEEL grammar change

    would need 2.0 RFP

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

Decisions can be used for many things, do we need a taxonomy?

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

    Decisions in DMN are actually expressions in a formal language (by default, FEEL). These expressions describe a range of computations and calculations, including constants like 42, calculations like (x-y)/2, and decisions using decision tables. It's awkward referring to constants and math formulas as 'decisions', but most of the time, decision is the right word. Should we allow some 'decoration' of the decision rectangle (e.g. an icon) to indicate whether it is a constant, a calculation, a decision, etc.?

    Another observation - InputData and BKM are not really needed to build a working DMN product. Decisions can be used instead of InputData. All your decision services would use input decisions instead of input data. Decisions can be used instead of BKMs, as there is no prohibition about a decision's logic being a FunctionDefinition. This means that decisions can invoke other decisions or simply reference them. Either way, there is an information requirement.

  • Reported: DMN 1.1 — Mon, 11 Apr 2016 19:42 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    withdrawn by submitter

    Do not see much value here.

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

Spaces and additional characters in names / identifiers

  • Key: DMN13-58
  • Status: closed  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    Having spaces and additional characters in useful from a user / BA perspective. However, is not good practice when it comes to implementing / designing programming languages / DSL. That's mainly due to ambiguities introduced by this approach. This is the reason none of the main stream PL do not support this feature.

    I suggest the following approach:

    • use spaces and additional characters in labels to improve the usability of FEEL (display labels in DRD diagrams)
    • if the name of a DMN entity (e.g. decision) contains a a space of additional character, use ' as delimiters. For example, 'A nice decision name ?'
    • reference ItemDefinitions by id and not by name to avoid ambiguities.
    • use the same delimiters to handle FEEL keywords as names (e.g. an OutputClause has name/label date)

    The same approach has been used successfully for SQL and OCL. OCL 2.4. specification is here
    http://www.omg.org/spec/OCL/2.4/

  • Reported: DMN 1.1 — Wed, 23 Nov 2016 10:58 GMT
  • Disposition: Closed; Out Of Scope — DMN 1.3
  • Disposition Summary:

    non-backward compatible change to FEEL and metamodel

    would need to wait for 2.0 RFP

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

null is not defined in the S-FEEL grammar

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

    null is not defined in the S-FEEL grammar.
    But it could be obtained as an input to a decision table so it would make sense to allow this value in the decision table as unitary test.

  • Reported: DMN 1.1 — Tue, 20 Sep 2016 17:42 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    we decided in DMN 1.2 to "deprecate" SFEEL.

    We should not change SFEEL anymore.

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

Semantics of variable in decision table input entry

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

    (on behalf of Bruce)
    On p122 it says "In Grammar Rule 51c, the qualified name must evaluate to a comparable constant value at modeling time, i.e., the endpoint must be a literal or a named constant". This says variables, except design-time constants, may not be used in decision tables. I think this constraint is not supported by the grammar and eliminates important functionality. Any name in scope should be allowed.

  • Reported: DMN 1.1 — Mon, 8 Aug 2016 20:37 GMT
  • Disposition: Closed; No Change — DMN 1.3
  • Disposition Summary:

    No longer an issue

    I don't see the prohibition against variables in the current spec. It may have been lifted by the introduction of generalized unary tests. Let's close if no longer an issue.

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

Clarification needed if null is passed as value for optional parameter of built in function

  • Key: DMN13-26
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

  • Key: DMN13-25
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

  • Key: DMN13-24
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Improve description of built-in function string()

  • Key: DMN13-27
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

FEEL grammar readbility

  • Key: DMN13-36
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Lexical representation of time string has ambiguous definitons

  • Key: DMN13-32
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

More Generic Ways to Define Decision Table Properties

  • Key: DMN13-38
  • Status: closed  
  • Source: OpenRules ( Jacob Feldman)
  • Summary:

    I described several issues with the current way of representing decision table properties and made concrete suggestions for improvement in this LinkedIn post: https://www.linkedin.com/pulse/decision-table-properties-dmn-beyond-jacob-feldman

  • Reported: DMN 1.1 — Sat, 20 May 2017 19:09 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

  • Key: DMN13-39
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

  • Key: DMN13-43
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

  • Key: DMN13-18
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Enhancement suggestion: allow for expressions to be used as "end points"

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

    This is a suggestion for future revisions of the specification:

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

    { Thanksgiving holiday: [ date(“2016-11-24”) .. date(“2016-11-27”) ] }

    This is extremely useful for users that no longer have to create dummy variables in order to use expressions as "end points".

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

    RTF 1.3 is ending

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

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

Include Test Cases in Decision Model

  • Key: DMN13-16
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Change depiction of Input to be harmonized with BPMN and CMMN


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

  • Key: DMN13-12
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

  • Key: DMN13-28
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Add two new concrete numeric types, make number abstract

  • Key: DMN13-31
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Formally define enumerations and use throughout

  • Key: DMN13-33
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions

  • Key: DMN13-20
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Wrong character in expression for PMT function definition

  • Key: DMN13-30
  • 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: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Requested additional built-in functions

  • Key: DMN13-55
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Collect decision tables

  • Key: DMN13-69
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

FEEL ambiguity

  • Key: DMN13-68
  • 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: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

  • Key: DMN13-71
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

need set operations and equality in FEEL

  • Key: DMN13-73
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

  • Key: DMN13-76
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Unspecified conclusion

  • Key: DMN13-78
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

We need a way to identify current date and time. I propose Now()

  • Key: DMN13-79
  • 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: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

  • Key: DMN13-44
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Should name declarations in same context fail or overwrite?

  • Key: DMN13-46
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

  • Key: DMN13-47
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

  • Key: DMN13-48
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Improvement of Semantic Domains Specification

  • Key: DMN13-50
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Semantic domain mapping for simple expressions

  • Key: DMN13-52
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Metamodel constraints & validation

  • Key: DMN13-65
  • 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.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Generalized Unary Tests

  • Key: DMN12-29
  • Status: closed  
  • Source: Sapiens Decision NA ( Mr. Gil Ronen)
  • Summary:

    Modeling with collections of items is fundamental to much business processing (as was noted in various LinkedIn threads). Simple comparisons such as ‘does A,B contain A’ should be done in decision tables using dedicated operators and not require exiting to FEEL and structures external to the decision tables. Several tools already support these operators. While you can write these expressions in FEEL it is useful that a table segregates each row as a rule so that one row matches "list contains both a and b", the next row matches "list contains c, d, and e", etc. We find these representations of the logic to be both common and easily understood by business folks. The proposal is to add ‘Is In’, ‘Contains’ and ‘Contains Any’ operators and their negation (symbols can be used instead of the full operator textual name).

    Attached images show this feature used in a business setting.

    Examples below of how these operators work (1st element is the Input Expression result and the 2nd is an Input Entry):

    {A,B} Contains A returns True {A,B,C} Contains {A,B}

    returns True

    {A,B,C} Contains {A,D} returns False
    {A,B} Contains Any A returns True{A,B,C}

    Contains Any

    {A,D}

    returns True

    {A,B} Contains Any C returns False

    A Is In {A,B}

    returns True

    {A,B} Is In {A,B,C} returns True{A,B}

    Is In

    {A,C}

    returns False

  • Reported: DMN 1.1 — Thu, 5 May 2016 14:28 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Expanding the definition of unary test to allow boolean literal expressions

    Change section 10.3.1.2 Grammar Rules (for FEEL) as follows:
    Add a grammar rule 17d, a 'generalized unary test' as a 4th option for 'unary tests'.
    Define 'generalized unary test' in a new grammar rule: generalized unary test = literal expression
    In the Semantics section (probably in 10.3.2.8) add:
    The name '?' refers to the value of the corresponding input expression, and add another grammar rule (not a syntactic one) that restricts the generalized unary test to a Boolean result:

    grammar rule 17.d: FEEL(t')=true, where t' is t with every occurrence of the symbol ? in t substituted with e.

    Will require some occurrences of 'unarytests' and 'unary tests' in the spec to be changed to 'generalized unary tests'. Will need examples showing 'generalized unary test' in decision tables, probably in the decision table chapter.

    Examples:
    1. The Input Expression Order.Total that evaluates to 5, combined with the Input Entry “>0” will result in the evaluation of “5>0” and a “true” result.

    2. The Input Expression Order.Total that evaluates to 5, combined with the Input Entry “?>0” will result in the evaluation of “5>0” and a “true” result.

    3. The Input Expression 'List of Codes' that evaluates to [“red”, “blue”], combined with the Input Entry “list contains (?,”green”)” will evaluate as “list contains ([“red”, “blue”],”green”) resulting in “false”.

    4. The Input Expression Tax.Threshold that evaluates to 100000 combined with the Input Entry “?>gross pay*0.7” will result in the evaluation of “100000>gross pay*0.7” where gross pay is another Information Requirement.

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

semantics of import is unspecified

  • Key: DMN12-188
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    for example, if 'lib' is the name of an imported model, and Input1 is an input data in that model, then one can refer to the input in FEEL using lib.Input1, but this is not specified in 10.4

  • Reported: DMN 1.1 — Thu, 14 Sep 2017 15:18 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    improve specification of import and qualified names

    see attached word doc

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Execution Semantics of Decision Services does not explain imported elements

  • Key: DMN12-131
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The semantics in 10.4 provides a mapping from a decision service to a function definition (which already has execution semantics defined earlier in Ch 10). The mapping does not explicitly consider imported elements. E.g. we could map an imported definition named 're-use this' to a nested context with the same name in the top context.

  • Reported: DMN 1.1 — Thu, 2 Feb 2017 15:54 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    resolved as DMN12-188

    duplicate issue

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Confusing semantics of ItemDefinitons

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

    According to the ItemDefinition specification, an ItemDefinition can be defined in two ways:

    • reference to a built-in or imported typeRef
    • composition of ItemDefinition via itemComponents

    According to the metamodel in Figure 7.6 and Table 23 typeRef is optional and itemComponent has [0..*] cardinality.

    That means an ItemDefinition can be defined as

    <itemDefinition id="1234" name="name"/>

    What is the actual semantics of this type? Is it some sort of a root type in a type system?

    To make the semantics more readable and fix some some typos or missing info, I suggest the following:
    1. Add missing cardinality for ItemDefintion.itemComponent in Figure 7.6. (missing info)
    2. In Table 23 change cardinality of typeRef to be [0..1] to match the metamodel (typo).
    3. Add an extra constraint in Table 23 itemComponent row:
    When typeRef is missing, itemComponent has at least one ItemDefinition.

  • Reported: DMN 1.1 — Wed, 6 Dec 2017 13:13 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Improve type checking semantics

    see attached word doc v8

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Formatting problems in Ballot 15 convenience doc

  • Key: DMN12-250
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Number for section 10.5 is missing, and title 'Metamodel' is small font

    (additional issues, if any, can be added here)

  • Reported: DMN 1.1 — Tue, 20 Mar 2018 16:53 GMT
  • Disposition: Closed; No Change — DMN 1.2
  • Disposition Summary:

    not an issue in the official spec

    this is a tracking issue about producing a convenience document.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Missing type names in FEEL functions (user and external)

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

    Currently there are three kind of functions in DMN / FEEL:

    • builtin functions (see page 130), strongly typed with optional parameters and var args, with static typing.
    • DMN functions defined in the metamodel (see functionDefinition element in xsd schema), strongly typed, with static binding
    • FEEL functions defined in FEEL (see grammar rule 57), weakly typed with dynamic typing.

    Mixing both static typing and dynamic typing in the same language is not a great idea from the execution point of view.

    I am not a fan of dynamic typing mainly because it pushes semantic rules in the dynamic semantics and diminishes the quality of software products (e.g. increases maintenance costs) .

    Imagine for example a context that contains an entry x with
    function(a, b) a + b
    and another one calling
    x(1, 2)
    The semantic analyzer cannot type check and infer the return type of the definition, it has to wait until the function is invoked. The type of x is partial (unknown parameter types and return types) for the rest of execution.

    On top of that the function can be used both for numbers and strings. If the intended behavior changes over time for one use case the user has to write another function anyway.

    It gets even harder to handle type checking for external functions.

    I suggest adding an a parameter type in rule 58

    formal parameter = parameter name ":" type name

    where type name is a FEEL type or a complex type (defined via a typeRef)

  • Reported: DMN 1.1 — Fri, 25 Aug 2017 09:12 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    part of improved types/itemdefinitions

    DMN12-216 adds optional types to FEEL functions

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Support for function calls in unary tests

  • Key: DMN12-119
  • Status: closed   Implementation work Blocked
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    Endpoints in SFEEL grammar are

    endpoint = simple value ;
    simple value = qualified name | simple literal ;

    Adding an extra alternative to support function calls will be useful, especially for tests on strings and lists.

    A Prolog-like notation can be used to specify the position of the input entry. For example,
    contains(?, "abc")

  • Reported: DMN 1.1 — Wed, 23 Nov 2016 10:43 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    covered by generalized unary tests

    the boolean expression containing '?' can invoke functions

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Missing RuleAnnotation attributes and model associations table

  • Key: DMN12-280
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Section 8.3.3 Decision rule metamodel do not list the attribute in a table for RuleAnnotation as it is usually done.

  • Reported: DMN 1.1 — Mon, 23 Apr 2018 17:51 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Add table RuleAnnotation attributes and model associations

    Add the following table to section 8.3.3

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Limitations of FEEL for..in..return

  • Key: DMN12-223
  • Status: closed  
  • Source: Red Hat ( Edson Tirelli)
  • Summary:

    Iteration is supported in DMN1.1 using the for..in..return operator, such as

    for j in myList return myFunction(j,…)

    But this only handles the case where each iteration of myFunction depends only on the value of j, the nth item in myList. It excludes cases where the iteration depends on:

    1. The n-1st item in the list, or
    2. The nth item of another list, or
    3. The result of the n-1st iteration

    These are all very common iteration use cases.

  • Reported: DMN 1.1 — Thu, 4 Jan 2018 14:46 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    add iteration context and 'partial' keyword to for..in..return

    Proposal

    The solution requires two simple enhancements to the for..in..return operator.

    1. Loop on index. Following “in”, instead of the list variable myList use the range syntax a..b, where expressions a and b are integers, for example:

    for n in 1..N return myFunction(n, myList,…)

    Most often N will be the count of myList and n an index into myList:

    for n in 1..count(myList) return myFunction(myList[n],…)

    2. Include partial results in the iteration. Much like the built-in variable item is defined for filter expressions, we introduce a new built-in variable partial for iteration, a list variable holding the results of previous iterations, for example:

    for n in 1..N return myFunction(n, myList, partial, …)

    Typically this would be used in an expression like

    for n in 1..count(myList) return myFunction(myList[n], partial, …)

    These two small changes allow for..in..return to handle all 3 iteration use cases.

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Typo in sublist() function example

  • Key: DMN12-79
  • Status: closed  
  • Source: Red Hat Inc ( Edson Tirelli)
  • Summary:

    There is a typo in the sublist() function example on page 134. It states:

    sublist([1,2,3], 1, 2) = [2]

    But the correct would be:

    sublist([1,2,3], 1, 2) = [1, 2]

  • Reported: DMN 1.1 — Tue, 23 Aug 2016 01:28 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    issue subsumed by DMN12-74

    issue subsumed by DMN12-74

  • Updated: Wed, 3 Oct 2018 14:17 GMT

FEEL + operator semantics operand-dependent

  • Key: DMN12-41
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    (from Bruce)
    It means addition for most operand types but concatenation for strings. This is another implementation barrier because the mapping from FEEL to another language requires evaluation of operands to determine their datatype. Making + addition only and adding a string concat function would simplify implementation.

  • Reported: DMN 1.1 — Sat, 14 May 2016 23:30 GMT
  • Disposition: Closed; Out Of Scope — DMN 1.2
  • Disposition Summary:

    changes to FEEL (even small ones) would not be backward compatible

    out of scope for RTF to change meaning of "foo" + "bar"

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Spaces in FEEL builtin functions

  • Key: DMN12-40
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    (from Bruce)
    one barrier to FEEL implementation is parsing when both variables and built in function names contain spaces. Modelers and tools can elect not to use spaces in variable names but the functions are defined in the spec. Eliminating spaces in builtin function names would simplify parsing. E.g., distinct-values() instead of distinct values(). Xpath does it this way.

  • Reported: DMN 1.1 — Sat, 14 May 2016 23:29 GMT
  • Disposition: Closed; Out Of Scope — DMN 1.2
  • Disposition Summary:

    changing names of built-ins is not backward compatible

    Changing names would not be backward compatible and hence is out of scope for an RTF; and there should be a higher bar to standardize multiple names for the same builtin.

  • Updated: Wed, 3 Oct 2018 14:17 GMT


Supporting text about Expression lists non-existing name attribute

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

    On page 64 (PDF 68) the supporting text says:

    Expression is an abstract specialization of DMNElement, from which it inherits the name, and optional id, description, and label attributes.

    However, DMNElement does not have a name attribute.

  • Reported: DMN 1.1 — Fri, 31 Mar 2017 08:48 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Remove name from attribute list of Expression

    See revised text.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Inconsistencies between metamodel and xsd schema

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

    The DMN metamodel doesn't seem to match the XSD schema:

    Page 37. DMNElement.extensionAttribute[0..*] in metamodel vs otherAttributes in XSD

    Page 39: Definitions.collection[0..*] in metamodel vs elementCollection in XSD

    Definitions.decisionService[0..*] in metamodel, missing in xsd.

    Page 64: ItemDefinition.itemComponents[0..] in metamodel ItemDefinition.itemComponent[0..] in XSD (extra s in metamodel)

  • Reported: DMN 1.1 — Tue, 14 Mar 2017 10:28 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Align names in MM with XSD for Definitions/@elementCollection and ItemDefinition/@itemComponent

    In MM:

    • rename 'collections' to 'elementCollection' in Figure 19: "Definitions Class Diagram"
    • rename 'itemComponents' to 'itemComponent' in Figure 31: "Expression class diagram".
  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Expected behavior for list/sort built-in functions in combination with singleton lists

  • Key: DMN12-210
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    The DMN specification says about singleton lists:

    • Chapter 10.3.1.4 on page 110: "A singleton list is equal to its single item, i.e., [e] = e for all FEEL expressions e."
    • Chapter 10.3.2.5 on page 113: “Therefore, any function or operator that expects a list as input but instead receives a non-list semantic domain element e behaves as if it had received [e] as input.”

    This works for most expressions and built-in functions, but for list built-in functions and the sort built-in function the behavior is ambiguous. This leads to different possible valid results for a FEEL expression. The problem here is that the further processing of this result (in DMN and/or other FEEL expressions) leads to different behavior/results of subsequent (boxed) expressions.

    Examples of ambiguous FEEL expressions:

    • distinct values(["a", ["a"]])
      • possible results: ["a"] or [["a"]] or ["a", ["a"]]
    • union(["a"], [["a"]])
      • possible results: ["a"] or ["a", ["a"]]
    • index of(["a", ["a"]], "a")
      • possible results: [1,2] or [1]
    • count([[]])
      • possible results: 0 or 1
    • list contains(["a", ["b"]], "b")
      • possible results: true or false
    • min([1],2)
      • possible results: [1] or 1
    • flatten([“a”, [], [[]]])
      • possible results: [“a”] or [“a”, []]

    Therefore we think, the specification must be detailed to ensure cross vendor interoperability.

    Our proposal for DMN 1.2 is not a change of the existing behavior, but a more detailed description of the expected behavior:

    Add the following 5 bullet points to chapter 10.3.4.4 List functions before table 61:

    • List built-in functions work on the passed lists as they are. A single element may be converted to a singleton list where the parameter domain requires this. (For example count(), list con-tains(), index of()).
    • If a built-in function returns a list, any list item originating from the parameters are pre-served, i.e. singleton lists remain (for example reverse(), sort(), min()).
    • To operate on list items, singleton lists may be resolved to their single item (for example min(), and(), mean()).
    • If a list built-in function identifies list items, FEEL equality is used (for example index of(), list contains()).
    • If FEEL equality matches two or more list elements and the built-in function has to decide which equal element should be returned, the function MUST return the element with the lowest position. (For example distinct values())

    Additionally the description of the flatten() built-in function should be changed to:

    “flatten nested lists and removes empty and nested empty lists”

    Additionally it may be helpful to categorize the list built-in functions to the following categories:

    • Functions searching for list items:
      list contains(), index of()
    • Functions creating a new list with additional or removed items:
      sublist(), append(), concatenate(), insert before(), remove()
    • Functions changing the list order of items:
      reverse(), sort()
    • Functions operating on list items and calculating a result:
      count(), min(), max(), sum(), mean(), and(), or()
    • Set theory functions:
      distinct values(), flatten(), union()


    We could add a new column “category” to table 61 or divide table 61 into more tables.

    Examples for the above FEEL expressions with the new applied specification changes:

    • distinct values(["a", ["a"]]) = [“a”]
    • union(["a"], [["a"]]) = [“a”]
    • index of(["a", ["a"]], "a") = [1, 2]
    • count([[]]) = 1
    • list contains(["a", ["b"]], "b") = true
    • min([1],2) = [1]
    • flatten([“a”, [], [[]]]) = [“a”]
    Even more examples

    list contains([], []) = false // processes passed list as is. This list is empty and cannot contain items.
    list contains([[]], []) = true // note: different result as for []
    list contains("a", "a") = true // automatic conversion from first parameter "a" to ["a"]
    list contains(["a"], "a") = true
    list contains([["a"]], "a") = true // FEEL equality is applied where [e] = e
    list contains(["a", "b", []], []) = true
    list contains(["a", "b", [[]]], []) = true

    index of([], []) = [] // processes passed list as is. This list is empty and cannot contain items.
    index of([[]], []) = [1] // note: different result as for []
    index of("a", "a") = [1] // automatic conversion from first parameter "a" to ["a"]
    index of(["a"], "a") = [1]
    index of([["a"]], "a") = [1] // FEEL equality is applied where [e] = e
    index of(["a", "b", []], []) = [3]
    index of (["a", "b", [[]]], []) = [3]

    sublist([],1,1) = null // invalid position
    sublist([[]],1,1) = [[]]
    sublist("a", 1, 1) = ["a"] // automatic conversion from first parameter "a" to ["a"]
    sublist(["a"], 1, 1) = ["a"]
    sublist([["a"]], 1, 1) = [["a"]]
    sublist(["a", "b", []], 3, 1) = [[]]

    append([], 1) = [1]
    append([[]], 1) = [[], 1]
    append("a", 1) = ["a", 1] // automatic conversion from first parameter "a" to ["a"]
    append(["a"], 1) = ["a", 1]
    append([["a"]], 1) = [["a"], 1]

    concatenate([], []) = []
    concatenate([[]], []) = [[]]
    concatenate("a", []) = ["a"] // automatic conversion from first parameter "a" to ["a"]
    concatenate(["a"], []) = ["a"]
    concatenate([["a"]], []) = [["a"]]

    insert before([], 1, "a") = null // invalid position
    insert before([[]], 1, "a") = ["a", []]
    insert before("a", 1, "b") = ["b", "a"] // automatic conversion from first parameter "a" to ["a"]
    insert before(["a"], 1, "b") = ["b", "a"]
    insert before([["a"]], 1, "b") = ["b", ["a"]]

    remove([], 1) = null // invalid position
    remove([[]], 1) = []
    remove("a", 1) = [] // automatic conversion from first parameter "a" to ["a"]
    remove(["a"], 1) = []
    remove([["a"]], 1) = []

    sort([[[]], [], ["a"], [["a"]]], function (x,y) count(x) > count(y) ) = [[[]], ["a"], [["a"]], []]

    reverse([]) = []
    reverse([[]]) = [[]]
    reverse("a") = ["a"] // automatic conversion from first parameter "a" to ["a"]
    reverse(["a"]) = ["a"]
    reverse([["a"]]) = [["a"]]

    min([1], [2]) = [1] // return list item
    max([1], [2]) = [2] // return list item

    // mean(), sum(), and(), or() do arithmetic operations and therefore do never return a list

    count([]) = 0
    count([[]]) = 1 // note: different result as for []
    count("a") = 1 // automatic conversion from first parameter "a" to ["a"]
    count(["a"]) = 1
    count([["a"]]) = 1

    distinct values([[[]], [], "a", ["a"], [["a"]]]) = [[[]], "a"] // uses FEEL equality, preserves items, chooses for equal list items item with lower list position

    flatten([[[]], [], "a", ["a"], [["a"]]]) = ["a", "a", "a"] // removes empty lists

    union([[], [[]], "a", ["a"], [["a"]]], [[["a"]], ["a"], "a", [[]], []]) = [[], "a"]
    // uses distinct values(concatenate())

  • Reported: DMN 1.1 — Thu, 19 Oct 2017 14:27 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Replace e=[e] with implicit de-listing to avoid argument domain error

    See attached word doc

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Missing attribute isExpanded for DecisionService DI

  • Key: DMN12-248
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    There is three ways to depict a decision service in DMN 1.2:
    Expanded with the divider line
    Expanded without the divider line.
    Collapsed with the plus maker

    However, in the lastest version of the specification (from Ballot 15) in the Decision Service section only 2 depictions are shown: the expanded one, with and without divider line.

    To have the last one, we need to add an isExpanded attribute to DMNShape.

  • Reported: DMN 1.1 — Fri, 16 Mar 2018 18:56 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Add isCollapsed attribute to DMNShape

    See revised text.

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Chapter 11 example in specification does not match file ch11example.xml and ch11example.xml contains errors

  • Key: DMN12-229
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    The figures in chapter 11 does not match the ch11example.xml file. There are missing requirements, typos and undefined functions.

    In order to be able to execute the ch11example.xml file the following erors must be fixed:

    • Missing information requirement from "Applicant data" to "Application risk score"
    • Missing information requirement from "Applicant data" to "Post-bureau affordability"
    • "Bureau call type" decision should have an information requirement from "Pre-bureau risk category" decision and knowledge requirement from
      "Pre-bureau risk category table" should be removed.
    • Missing information requirement from "Application risk score" to "Post-bureau risk category"
    • Missing information requirement from "Post-bureau risk category" to "Post-bureau affordability"
    • Missing information requirement from "Required monthly installment" to "Post-bureau affordability"
    • Typo in BKM "Application risk score model": Parameter name should be "Marital Status" (with space)
    • Inside "Pre-bureau risk category table" rule 2 and 3 contains wrong expressions for input clause "Application Risk Score". It should be ".." instead of "-" inside ranges
    • For the "Bureau call type" decision "Pre-Bureau Risk Category" should be renamed as "Pre-bureau risk category" (as the decision name) on the right.
    • For BKM "Affordability calculation" "Disposible Income" should be renamed as "Disposable Income" and for the first context entry "-" minus should be used (not an invalid character)
    • In case of "Strategy" decision the input clauses should be corrected as "Eligibility" and "Bureau Call Type" instead of "eligibility" and "bureauCallType"
    • For "Post-bureau risk category" decision remove invalid characters from the name of "Application Risk Score"
    • The external function "PMT" should be declared. We recommend to add a new business knowledge model "PMT" with a knowledge requirement from that business knowledge model "PMT" to "Installment calculation"

    Other issues with already reported errors concerning the chapter 11 example:

  • Reported: DMN 1.1 — Fri, 2 Feb 2018 10:00 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Revision of Chapter 11 example

    What has changed?

    • All decisions and business knowledge model names were uniformized to lower case
    • Decision table "Application risk score model" Age input entries were modified to be complete (ie [18..21], [22..25] were changed to [18..22), [22..26) )
    • Everything was recaptured to make sure we had the proper naming in parameters in the decision logic
    • XML was generated with DMN 1.2 namespace and the complete DI. There is 6 diagrams corresponding to figure 11.2 to 11.7
    • PMT function that is invoked in "Installment calculation decision logic" is now defined in its own file (Chapter 11 Example - Financial.dmn) and this file is imported by Chapter 11 Example. The imported BKM was also added to the proper diagrams.
    • A figure of the PMT function was added
  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Wrong length range check for built-in function sublist() and substring()

  • Key: DMN12-186
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    Footnote 2 of table 61 contains wrong check, therefore change footnote 2, to: "length must be in the range [1..E], where E is L - start position + 1 if start position is positive, and -start position otherwise."

    The "+ 1" is important!

    Example: sublist([1,2,3],1,3)
    --> length must be in the range from [1..3] not [1..2]

    Same applies to built-in function substring(), table 60 page 133, footnote 1, second sentence.

  • Reported: DMN 1.1 — Thu, 31 Aug 2017 14:14 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    correct the range of the length arg of 2 builtins

    see revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Wrong numbering in S-FEEL syntax

  • Key: DMN12-46
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    It is said that the numbering of S-FEEL is the same than FEEL specified in section 10.3.1.2, but from rule 33 to 39 it is not the case anymore.

    S-FEEL

    33 simple literal = numeric literal | string literal | Boolean literal | date time literal ; (should be 34)
    34 string literal = '"' ,

    { character – ('"' | vertical space) }, '"' ; (should be 35)
    35 Boolean literal = "true" | "false" ; (should be 36)
    36 numeric literal = [ "-" ] , ( digits , [ ".", digits ] | "." , digits ) ; (should be 37)
    37 digit = [0-9] ; (should be 38)
    38 digits = digit , {digit} ; (should be 39)
    39 date time literal = ("date" | "time" | "duration" ) , "(" , string literal , ")" ; (this seems to be a rewrite of rule 62)

    FEEL

    33. literal = simple literal | "null" ;
    34. simple literal = numeric literal | string literal | Boolean literal | date time literal ;
    35. string literal = '"' , { character – ('"' | vertical space) }

    , '"' ;
    36. Boolean literal = "true" | "false" ;
    37. numeric literal = [ "-" ] , ( digits , [ ".", digits ] | "." , digits ) ;
    38. digit = [0-9] ;
    39. digits = digit ,

    {digit}

    ;
    51. comparison =
    a. expression , ( "=" | "!=" | "<" | "<=" | ">" | ">=" ) , expression |
    62. date time literal = ( "date" | "time" | "date and time" | "duration" ) , "(" , string literal , ")" ;

  • Reported: DMN 1.1 — Mon, 16 May 2016 21:24 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Number the SFEEL grammar rules consecutively.

    See revised text. Change is editorial only. Does not change the grammar.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Remove tight coupling with BPMN and BMM

  • Key: DMN12-45
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The DMN metamodel has Decision with M:N relations that point to BPMN and BMM. This may/will create undesirable referencing issues. While it It is desirable to maintain "loose coupling" between DMN and these external sources (BPMN, BMM, and even CMMN) to do so normally requires these kinds of relations be defined in the caller (or source) rather than the callee (or target). In the particular context of DMN, with respect to BPMN, BMM and event CMMN, the Decision will mostly likely be the target (and not the source). It is recommended to remove the BPMN20::Process, the BPMN20::Task, the BMM::Objective elements from the metamodel and their associated relations and rather make sure that a BPMN, BMM and/or CMMN models can point to a Decision that it uses rather than a DMN Decision pointing to (the potentially not enumerable) places where it is used.

  • Reported: DMN 1.1 — Mon, 16 May 2016 15:37 GMT
  • Disposition: Closed; Out Of Scope — DMN 1.2
  • Disposition Summary:

    Cannot remove objects from meta-model, would not be backward compatible.

    DMN 1.1 models may reference BPMN or BMM elements. These models must also be valid in DMN 1.2. As I understand backward compatibility requirements, this issue is out of scope for an RTF.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Attributes in tables 29a and 29b do not correspond to metamodel Fig 51

  • Key: DMN12-55
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    the tables are using 'inputEntry' and 'outputEntry' whereas the MM uses 'inputValues' and 'outputValues'. The MM is correct.

  • Reported: DMN 1.1 — Thu, 23 Jun 2016 21:27 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    *change inputEntry to inputValues and outputEntry to outputValues *

    Apply editing instructions in Revised Text.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

typeRef from tables 10 and 15 not in figures 20 and 23

  • Key: DMN12-23
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    according to the UML diagrams in the figures, Decision and InputData do not have typeRefs. They have variables, which are InformationItems, and it is the InformationItems that have the typeRef. Propose to remove typeRef from tables 10 and 15.

  • Reported: DMN 1.1 — Fri, 12 Feb 2016 17:58 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    remove typeRef from tables 10 and 15

    Apply editing instructions in Revised Text.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Decision Table hit policies C and C# should not return null when there are no matches

  • Key: DMN12-176
  • Status: closed  
  • Source: Red Hat ( Edson Tirelli)
  • Summary:

    In DMN, null seems to be used mostly to indicate absence of a value or the presence of an error.

    When using the Decision Table hit policies C and C#, failure to match rules in the decision table does not mean either. In such cases, the most appropriate and expected result should be:

    • for hit policy C: an empty list
    • for hit policy C#: the value 0
  • Reported: DMN 1.1 — Tue, 18 Jul 2017 19:01 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    hit policies C and C# do not return null when there are no matches

    See attached Word file

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

FEEL versions cannot be distinguished

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

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

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

  • Reported: DMN 1.1 — Thu, 26 Apr 2018 11:05 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    New URI for FEEL 1.2

    In accordance with the "OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces in OMG Specifications – Version 2" (smsc/2015-3-06) and the DMN 1.2 namespace URIs introduced together with Diagram Interchange, new namespace should be:
    http://www.omg.org/spec/DMN/20180521/FEEL/

  • Updated: Wed, 3 Oct 2018 14:17 GMT

DMN built-in functions are missing to ensure business friendliness

  • Key: DMN12-190
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    A lot of use cases of decision logic involve date and time manipulations (e.g. some decision based on the age of an invoice or a person). The current list of DMN functions is too limited to express the logic in a business friendly way.

    For example:
    floor((today()-Past Date).days/365.25) to compute the age in years of a person, an invoice, a client account etc. (where 'Past Date' is a date)

    or worst

    floor(((date and time(Past Date,time("00:00")) + duration("P" + string(floor((today()-Past Date).days/365.25)) +"Y") +duration("P1Y")) - now()) /duration("PT24H")) to compute the number of day until the yearly anniversary of person, an invoice, a client account etc.

    A list of additional required built-in functions will be submitted as proposal to this issue

  • Reported: DMN 1.1 — Wed, 20 Sep 2017 20:03 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Add more built-in functions

    Add more built-in functions

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Import is lacking extension capability

  • Key: DMN12-231
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    It would be useful to save some custom information on import declaration but no extensions are offered on import.

    ExtensionAttributes should be added and potentially ExtensionElements.

  • Reported: DMN 1.1 — Wed, 14 Feb 2018 22:29 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Make Import MM class inherit from NamedElement

    Revise 6.3.3. Import metamodel and Table 6 Import attributes and model associations to reflect Import as subclass of NamedElement.

    Make corresponding changes to the XSD.

    Backward Compatibility Argument
    The new attributes inherited from NamedElement are optional. Import elements that are valid before the change are also valid after the change.

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Problem with QName usage in typeRef

  • Key: DMN12-94
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    typeRef is a QName which has 2 parts, an optional namespace and a local name.
    In XML local name is typed as an xsd:NCName and thus cannot have spaces in it.

    In the CH11 example of the spec,
    There is a serialization error that lead to confusion about Qname…
    ex: line 447 there is a formal parameter with a typeRef to "ex:RiskCategory" but its definition at line 84 is:
    <itemDefinition name="Risk Category" id="riskCategory_t">
    RiskCategory does not reference neither name nor id (name has a space and id is wrong).

    The idea of using prefix:name as QName for typeRef in DMN is problematic as name(s) may contain spaces.

    It is recommended to use prefix:id as QName and specify this clearly in the spec so we do not run into the spaces in names problem.

  • Reported: DMN 1.1 — Tue, 20 Sep 2016 20:03 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    typeRefs and ItemDefinition names are FEEL qualified names

    In order that typeRef may reference an itemDefinition as prefixed name, as specified in 7.3.2 paragraph 9 and Table 23, the name of an itemDefinition must be a valid XML NCName, as opposed to the less stringent requirements for other NamedElements. That means it may not contain spaces and other characters used in “business-friendly” names. This is implied but not clearly stated in the spec text.

    Abstract
    • While this issue singles out typeRef, our proposal provides a common basis for representing both imported item definitions and variables (e.g., BKMs).
    • Use name not id to reference item definitions (in typeRef) and variables (in FEEL expressions). Use of id-based references should be limited to DRG elements such as in information requirements or DI.
    • To the import element, add the new attribute name, a business-friendly, easily remembered string used as a proxy for the namespace value. The name need be unique only in the importing model, not globally.
    • Limit reference of target namespace (definitions/@namespace) to models that import other models. In DMN models without import, the target namespace must be declared but is never used in expressions or typeRef.
    • For models that do not import other models, typeRef is just the item definition name or FEEL base type name; there is no change to FEEL expressions. For models that do import, both typeRef and FEEL variable references are [import element name].[local-name]. In DMN1.1 imported variables are referenced as [namespace value].[local-name]. Namespace values are typically URLs containing colon, which is disallowed in FEEL qualified names.

    Justification
    • Names are modeler-entered values, so they should be business-friendly and easily remembered. ids are tool-generated values, typically globally unique, not business-friendly, and not easily remembered. If typeRef is based on id, tool asks modeler to select item definition based on name but then uses id in the XML. This is OK, since modeler does not see the XML. But the same cannot be said for FEEL expressions referencing imported names, such as a BKM.
    • Namespace prefixes in QNames are complicated, since the global declaration in definitions may be overridden locally within the model, so the prefix in effect depends on local scope. Import name is declared once in the importing model.
    • Simpler is always better. This is much simpler.

    Argument for backward compatibility
    DMN 1.1 says that typeRefs are strings with the syntax of an XML QName.
    DMN 1.2 says that typeRefs are strings with the syntax of a FEEL qualified name. Because QNames can contain the colon character but FEEL names cannot, isn't this a problem?
    Not Really. QNames with a colon character are qualified using a namespace prefix, but in DMN 1.1, there is no standard way to define a namespace prefix for an imported type. DMN 1.2 adds the 'name' attribute to the 'Import' class to fix this problem. In DMN 1.1, only non-qualified typeRefs are specified well enough to work, and these will also work in DMN 1.2.

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Issues with Table 61

  • Key: DMN12-74
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    (on behalf of Bruce)
    1. Several functions say N>1 (N is number of list items), but elsewhere spec says a list function with a singleton argument means a list where N=1. Does the table here mean N=1 is an error for these functions?
    2. and(list). Examples are incorrect. All 4 examples should be null; the first 2 are the same, and the last 2 are actually undefined if N must be >1.
    3. or(list). Ditto 2 above.
    4. sublist. Example is incorrect. sublist([1,2,3],1,2)=[1,2]
    5. insert before. Example is incorrect. insert before([1,3],1,2)=[2,1,3]

  • Reported: DMN 1.1 — Mon, 8 Aug 2016 20:53 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Correct rows 2-8,11 of Table 61

    see Revised Text. Note that and() is renamed to all() and or() is renamed to any() as per the resolution of DMN-78.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Missing annotation in Decision Table in DMN XSD

  • Key: DMN12-282
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Changed made to the XSD for DMN12-140 added the annotationEntry but not the clause.

    Also, the annotationEntry type was created inline as all other elements have a separate type.

  • Reported: DMN 1.1 — Mon, 23 Apr 2018 21:30 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Add missing annotation to Decision table in XSD

    Add the following entry right after output in tDecisionTable

    <xsd:element name="annotation" type="tRuleAnnotationClause"  minOccurs="0" maxOccurs="unbounded"/>
    

    Remove the annotationEntry element added in DMN12-140

    Add the following line right after outputEntry in tDecisionRule

    <xsd:element name="annotationEntry" type="tRuleAnnotation" minOccurs="0" maxOccurs="unbounded"/>
    

    Add the flowing complex types after tDecisionRule

            <xsd:complexType name="tRuleAnnotationClause">
                   <xsd:attribute name="name" type="xsd:string"/>
            </xsd:complexType>
            <xsd:complexType name="tRuleAnnotation">
                   <xsd:sequence>
                           <xsd:element name="text" type="xsd:string" minOccurs="0"/>
                   </xsd:sequence>
            </xsd:complexType>
    
  • Updated: Wed, 3 Oct 2018 14:17 GMT

Wrong chapter reference for date and time / date and time subtraction

  • Key: DMN12-203
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    Row 2 describes the subtraction of date and time values. The description in column 3 says "... where value dt is defined in 10.3.2.3.5 date ...". I think this is a mistake. The reference should be "... where value dt is defined in 10.3.2.3.6 date-time ...". Otherwise a conversion from date and time to date is necessary and the minimal unit would by days.

    Page 132, table 58 lists the following example:

    date and time("2012-12-24T23:59:00") - date
    and time("2012-12-22T03:45:00") =
    duration("P2DT20H14M")
    

    The minmal unit here is minutes.

    Therefore I think this is a typo with a wrong chapter reference.

  • Reported: DMN 1.1 — Tue, 10 Oct 2017 13:37 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    fix typo in chapter reference

    see revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Type should be specified for date, time and duration properties

  • Key: DMN12-201
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    Table 53 defines the properties for different types. But the types of the properties are not specified.

    Specification should be as listed here:

    • for date
      • year, month, day (all of type number)
    • for date and time
      • year, month, day, hour, minute, second (all of type number)
      • time offset (type days and time duration)
      • timezone (type string)
    • for time
      • hour, minute, second (all of type number)
      • time offset (type days and time duration)
      • timezone (type string)
    • for years and months duration
      • years, month (all of type number)
    • for days and time duration
      • days, hours, minutes, seconds (all of type number)
  • Reported: DMN 1.1 — Tue, 10 Oct 2017 09:41 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    add type and normalize into 2 tables

    See attached proposal.

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Show diagram elements with hidden links

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

    Because Decisions, Knowledge Sources, Input Data and BKMs can appear on many diagrams they may have requirements that are not shown on a given diagram. While this is a powerful feature it can be confusing if it is not clear to a user that such links exist but are not displayed. This could be left a a tooling issue but on balance some notation (an ellipsis for instance) that was common woudl probably be more useful.

    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.

  • Reported: DMN 1.1 — Wed, 11 May 2016 04:06 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Specify ellipsis as marker for missing information

    See Revised Text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Allow DMN DI to provide an alternative notation for Input Data (DMN 1.2)

  • Key: DMN12-272
  • Status: closed   Implementation work Blocked
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    More and more, DMN is being used in conjunction with BPMN and CMMN. The recent work of the OMG BPM Healthcare initiative is a prime example. The Healthcare Field Guide being developed is anchored with the three standards as the way forward for developing healthcare clinical pathways. Feedback from this work and work being done for the VHA using all three standards, is that data notation should be consistent across all three specifications. Thus, the BPMN Data Object, the CMMN Case File, and the DMN Data Input should all look the same since they represent the same general concept to the people creating the models. Further, it will help readers of the models, who don't create them, but are responsible for their implementation within the organization, to understand how the three models work together. Such readers could be hospital clinical informatists.
    While there may be technical differences between the data representations among the three standards, these differences are not important to the business analysts who are using the models nor the readers of the models. The general concept of data used within a process, case, or decision is common across the three specs.
    Thus, the proposal for this issue is to allow modeling tools to provide an alternative notation for DMN Data Inputs that matches the notation found for BPMN Data Objects and CMMN Case Files.

  • Reported: DMN 1.1 — Tue, 3 Apr 2018 18:24 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    duplicate of dmn12-44

    close as duplicate. Note that dmn12-44 is deferred.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Chapter 11 example decision tables are incomplete

  • Key: DMN12-126
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Consider, for example, Figure 84 on pg 158. This table is missing a rule for Age in the range (21..22). For example, for Age=21.5. Note that DMN has a number type, but no integer type, so it is not possible to restrict Age to integers (within the DMN spec, at least). It would be better to use intervals that adjoin, e.g. [18..22), [22..26), [26..36), etc.

  • Reported: DMN 1.1 — Wed, 18 Jan 2017 02:32 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    use round and square bracket range notation to avoid gaps

    close proposal for integer type for now - can open a new issue (in 1.3 for integer types)

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Please clarify what is the result of a filter with non-boolean expressions (null)

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

    Example: a relation "people" with the following content:

    people : [

    { name : "Bob", age : 30 }

    ,

    {name : "Max", age : null }

    ]

    What is the result of an expression like the following:

    people[ age > 20 ]

    The filter will obviously evaluate to true for the first person "Bob", but the for second person, age is null, and the expression `age > null` will also return null.

    What is the result of the expression?

    a. [

    { name: "Bob", age : 30 }

    ]
    b. null
    c. some other value?

    Please clarify explicitly in the spec what is the result of a filter which might evaluate to null for some elements, like the above example.

  • Reported: DMN 1.1 — Thu, 15 Mar 2018 00:02 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    add example of null filter

    see revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Lost formatting in 10.3.2.2 Equality, Identity, and Equivalence

  • Key: DMN12-246
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Some formatting (bold, italics, subscript) has been lost in the 2nd para of 10.3.2.2.

  • Reported: DMN 1.1 — Tue, 13 Mar 2018 23:35 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Add formatting as given

    See revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

add weekday property to date, date and time

  • Key: DMN12-217
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    should work like XML Schema

  • Reported: DMN 1.1 — Thu, 14 Dec 2017 16:19 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    *merged *

    see DMN12-201

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Semantic mapping for XML syntactical artifacts

  • Key: DMN12-184
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Names are unique in DMN. As such there are no need to add syntactical artifacts during the mapping from XML to DMN context.

    We propose the following changes:

    Table 56

    XML Context entry in p Remark
    ... ... ...
    <q:e/> "e": null namespaces are ignored.
    ... ... ...
    <e a = "v"> <c1>v1</c1> ... "e":{"a": XV(v), ... An element containing attributes or child elements -> context
    ... ... ...

    Table 57
    Remove "@a": in the FEEL semantic Domain column for rows date, dateTime, time and duration.

    Figure 10.3.3.3.3
    Change tns$Employee for Employee
    Change tns$salary for salary

  • Reported: DMN 1.1 — Wed, 6 Sep 2017 20:28 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    ignore namespace and prefix in XML mapping

    see revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Releation between Definitions and DecisionService does not specified in XSD

  • Key: DMN12-121
  • Status: closed  
  • Source: ACTICO GmbH ( Eduard Weiss)
  • Summary:

    I am currently working on DMN and try to reuse xsd file (http://www.omg.org/spec/DMN/20151101/dmn.xsd) in our product. The problem what I have is that I cannot find definition of releation between Definitions and DecisionService inside xsd such as described in the specification page 40.

    Is it right or do I misundertand the xsd format?

  • Reported: DMN 1.1 — Mon, 5 Dec 2016 08:59 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    Fixed by DMN12-10/DMN12-174

    This issue has been fixed by DMN12-10/DMN12-174.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Need attribute for human and external decisions

  • Key: DMN12-59
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Normally, a valid executable model requires a value expression for every decision. However, human decisions and external decisions, by definition, exclude a value expression. To allow validation to skip such decisions, an attribute identifying a decision as human or external would be useful.

  • Reported: DMN 1.1 — Tue, 28 Jun 2016 14:49 GMT
  • Disposition: Closed; No Change — DMN 1.2
  • Disposition Summary:

    unnecessary - value expression can be in natural language

    According to the spec, one can use the expressionLanguage attribute set to the value http://www.omg.org/spec/DMN/uninterpreted/20140801 to indicate that the value expression of a decision is not to be interpreted.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Space in FEEL names is not well-specified

  • Key: DMN12-58
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    (from Bruce)
    Space in FEEL names is not well-specified. Space (&#x20) is not a name character allowed by rules 30-32, nor is it included in the construction of name from name start and name part|additional symbol (rule 27). But additional syntax rules says single spaces are allowed in names (somewhere). I believe the intent is that “Applicant Data” and “ApplicantData” are both valid names but are not the same name. Specific ambiguities include:

    · What is the relationship between space and name part? Does a space always act as a separator between name parts?

    · If not, can a name part begin or end with space? Can a name start begin or end with space?

    · Related: Do additional symbols also act as separators between name parts, when they do not represent operators?

    · Does . act as separator between name parts (when not used as path operator or decimal point)?

    · The chapter 11 example (e.g. fig 79) includes things like Applicant data . Age (note space before and after the period). Is this valid syntax?

  • Reported: DMN 1.1 — Tue, 28 Jun 2016 14:47 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    create new section in chapter 10 for names, tokens, and whitespace processing and improve ambiguity section

    see attached proposal

    Argument for Backwards Compatibility
    All valid DMN 1.1 names are valid in 1.2.

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Dynamic invocation

  • Key: DMN12-37
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    (raised by Bruce)
    In DMN 1.1, the target of an invocation was changed from the name of a BKM to any expression, presumably one that results in a BKM name. The reason given was to allow dynamic invocation, for example, if condition1 then BKM-X else BKM-Y. That is a potentially useful thing, but dynamic invocation would require further changes to DMN. In particular, knowledge requirements point to a particular BKM id. Changing knowledge requirement target to an expression would make it difficult (impossible?) to represent the element as a connector in the DRD. Also, the invocation bindings point to specific parameter names, requiring all targets of the dynamic invocation to have the same parameter names.

  • Reported: DMN 1.1 — Mon, 9 May 2016 19:25 GMT
  • Disposition: Closed; No Change — DMN 1.2
  • Disposition Summary:

    had discussion, no change needed

    no change

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Show implied Information Requirements

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

    It is easy to take advantage of the ability to have multiple DRDs showing the same objects to create multiple layers of detail - a high level DRD, more detailed ones for each "leg" etc. In general this works perfectly with decisions "encapsulating" their dependency network. The one thing that would occasionally be useful is an ability to see how Input Data is used throughout.
    For instance, when Decision A requires Decision B which requires Decision C which requires Input Data D it would be useful to see that Decision A indirectly requires Input Data D. A version of a information requirement link that showed an indirect requirement would allow this to be shown without in any way violating or undermining the current approach to reuse across diagrams.

    The scope of this issue is limited to "flat" DRDs, that is, no "sub-DRDs" nested inside an outer decision or BKM.

  • Reported: DMN 1.1 — Wed, 11 May 2016 04:11 GMT
  • Disposition: Closed; No Change — DMN 1.2
  • Disposition Summary:

    too difficult to do with diagram interchange framework

    The DI framework can diagram semantic elements, but here there is no actual element, only an element that can be derived by transitivity. That is not sufficient for DI, and we do not want to materialize all possible transitive links.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Graphical representation of Context - "sub-DRDs"

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

    This issue is meant to factor-out the "sub-DRD issue" from a number of issues (DMN12-27, DMN12-38) that are actually independent of whether we have "sub-DRDs". There may be better ways or alternate ways of expressing notation and meaning of a 'DRD in a box' but this seems to be a recurring theme so similar issues or competing proposals should be linked here for comparison.

    Context is an important form of value expression but tool vendors appear reluctant to implement it, believing it to be not as business-friendly as a DRD expressing the same logic. I propose that DMN 1.2 add a graphical representation of a context, in which nodes represent a context entries, linked by information requirements. A decision whose value expression is a context represented in this way would be indicated in the DRD with a special marker.

    The benefits of such a change are these:
    1. Increased support for Contexts by tool vendors
    2. More business-friendly representation
    3. Simpler “top-level” DRD representation of complex end-to-end logic
    4. Reusability of more complex decision logic, since BKMs can visualize their value expression in this way.
    5. Compatibility with Bastian’s MID proposal 12-27.

  • Reported: DMN 1.1 — Wed, 4 May 2016 18:15 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    Invocable decision service addresses this issue

    See DMN12-10

  • Updated: Wed, 3 Oct 2018 14:17 GMT

FEEL 'instance of' operator is underspecified

  • Key: DMN12-47
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    it seems clear from Ch 10 that 'x instance of string' and 'x instance of number', for example, are defined and are true when the value of x is a string or number as defined in Ch 10. However, if the value of x is a context that conforms to some ItemDefinition or XML Schema type, then it is not defined whether this is possible or exactly what it means. We would need to define what it means for a context (and list) to be valid w.r.t. a typeRef. FEEL semantics are execution semantics, and are not validation semantics. A precise statement of validation semantics could be very useful for standardized validation of a model w.r.t. input data (which have typeRefs but not executable input values). However, this is a big job.

  • Reported: DMN 1.1 — Sat, 21 May 2016 18:52 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    better type checking spec covers this

    now we have defined instance of on feel constructed types - lists and contexts

  • Updated: Wed, 3 Oct 2018 14:17 GMT

SFEEL makes too few people happy

  • Key: DMN12-48
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    There are many reported issues complaining that SFEEL lacks something in FEEL, or with people unhappy with something that is in both FEEL and SFEEL. For example,
    The current SFEEL EBNF does not provide for the use of parentheses to set arithmetic precedence of operations.
    The current EBNF only supports precedence of operators e.g. 2+3*4 = 14
    In Decisions relying on more advanced arithmetic (e.g. Financial decisions related to mortgages or claims) it is desirable to allow the expressiveness of "scientific" calculation to allow the
    use of parenthesis to set precedence e.g (2+3)*4 = 20.
    It is recommended to add the use of parenthesis in arithmetic expressions and have them set precedence of operations.

  • Reported: DMN 1.1 — Wed, 25 May 2016 15:09 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    recommend full FEEL

    See revised text.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Missing support for escape sequences in string literals

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

    Currently the syntax for string literals does not support escape sequences.

  • Reported: DMN 1.1 — Fri, 26 Jan 2018 16:20 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Add support for escape sequences in string literals

    Change production for string literals in FEEL grammar to add support for escape sequences

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Would like to use duplicate shapes/names in diagram to avoid multiple requirement line crossings

  • Key: DMN12-129
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Multiple occurrences of shape/element X are currently prohibited in the spec (6.2.1.1). Would be nice to allow multiple occurrences instead of one with many outgoing requirement arrows. This affects diagram interchange, because there would be >1 diagram element per metamodel element. Need a MM element per occurrence in diagram.

  • Reported: DMN 1.1 — Thu, 26 Jan 2017 16:21 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    DMN12-62 Diagram Interchange allows multiple diagram elements per DMN element.

    The latest proposal of Diagram Interchange DMN12-62 removed the following sentence, which was inherited from BPMN and DMN:

    Multiple depictions of a specific DMN element in a single diagram are not allowed.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Invalid example for date and time property access

  • Key: DMN12-206
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    Excerpt from specification: "For example, FEEL(date and time("03-07-2012Z").year) = 2012"

    The string literal format of the date and time string is invaild. It doesn't match XML Schema Part 2 Datatypes as mentioned on page 131 for type date.

    Please change the text to: "For example, FEEL(date and time("2012-07-03T00:00Z").year) = 2012"

  • Reported: DMN 1.1 — Thu, 12 Oct 2017 08:03 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    fix typo in date and time string

    see revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

DRD elements must be labeled with their name

  • Key: DMN12-133
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    section 6.2.1.1 allows elements such as decisions to be labeled with add'l attributes, and does not actually require a label at all. This is unnecessarily general and may cause problems for DI and for using multiple occurrences to avoid line crossings.

  • Reported: DMN 1.1 — Thu, 9 Feb 2017 16:36 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    DMN12-62 removes other attributes than the name from diagrams

    DMN12-62 already contains a text proposal that removes other attributes than the name (or a pretty-printed version of that) from diagrams

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Impossible to invoke functions and() and or()

  • Key: DMN12-78
  • Status: closed   Implementation work Blocked
  • Source: Red Hat Inc ( Edson Tirelli)
  • Summary:

    Page 109 of the specification, 3rd bullet, states:

    “A name start (grammar rule 28) SHALL NOT be a language keyword. (Language keywords are enclosed in double quotes in the grammar rules, for example, "and", "or", "true", "false".)"

    The specification defines a function invocation on page 108, rule 40, as:

    function invocation = expression , parameters ;

    The list of built-in functions on page 134 lists both functions “and(…)” and “or(...)” as built in functions, but from the grammar rules mentioned above, it is clear that “and”, is not a valid "expression", and so “and(…)” is also not a valid function invocation.

    The same is true for “or(...)”.

    Either the functions need to be renamed to use valid identifiers (i.e., identifiers that do not start with a keyword) or the grammar has to be changed to allow for this special case. My personal preference is to rename the built in functions to something like “list and(...)” and “list or(...)”.

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

    rename 'and' to 'all' and 'or' to 'any'

    see revised text

    Argument for Backward Compatibility
    Normally, a change of name of built-in function would be an incompatible change. However, this part of the 1.1 spec proved impossible to implement, because the name of a built-in cannot be a language keyword. I.e., nothing to be compatible with here.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Label versus name attribute

  • Key: DMN12-89
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Most element inherit DMNElement which includes a label.
    Some elements extends NamedElement that extends DMNElement and adds a required name to it.

    Some text should be added to the specification to determine how those two attributes should be used.
    For example, what should be depicted on a Decision in the diagram?
    It’s name or its label?
    Is that label really required on all elements?
    (please note that a label may contain ctrl char like carriage return where I presume the name would not)

    NB (This issue also relate to the upcoming Diagram Interchange (DI) capability coming)

  • Reported: DMN 1.1 — Fri, 26 Aug 2016 18:40 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Clarify role of label

    1. Clearly define that the name attribute is displayed in the notation
    2. Explain label attributes purpose as an alternative short description and that it is not displayed and not to be confused with names, which are used for referencing
    3. Should not be used on elements that already have a name

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Label of Input in decision table

  • Key: DMN12-88
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In Decision table, the input extends DMNElement which gives them a label.
    However, the spec clearly states that what is depicted on a Decision Table is the input expression (ref: Fig 33), not the label therefore the label attribute is useless .
    What should be done with it?

    NB (This issue also relate to the upcoming Diagram Interchange (DI) capability coming)

  • Reported: DMN 1.1 — Fri, 26 Aug 2016 18:37 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    Close as duplicate of DMN12-89

    The role of label has been clarified by DMN12-93, which is the proposal for issue DMN12-89.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

FEEL path expression has same precedence as filter and invocation

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

    Grammar rules 2g and 2h indicate that filter and invocation have higher precedence than path expressions. Actually, they have the same precedence are left associative. Suggest combining these 2 rules into 1.

  • Reported: DMN 1.1 — Wed, 29 Jun 2016 14:59 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    combine grammar rules 2g and 2h

    Apply editing instructions in Revised Text.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Decision Service Cannot be Shown in DRD

  • Key: DMN12-136
  • Status: closed  
  • Source: Sapiens Decision NA ( Mr. Gil Ronen)
  • Summary:

    The DMN Element Metamodel (Fig. 18 in the specification) shows that Decision Services are NOT a subclass of DRGElement. The definition of the DRD requires its components to be DRGElement (“A Decision Requirements Diagram (DRD) is the diagrammatic representation of one or more instances of DRGElement and their information, knowledge and authority requirement relations “). I think the Decision Service should be part of the DRD, especially if it is a callable unit within the DRD (that is, can be linked to a BKM as per DMN12-10/DMN12-135).

  • Reported: DMN 1.1 — Thu, 23 Feb 2017 13:16 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    fixed by invocable decision service DMN12-10

    In the current MM (e.g. see the Ballot13 convenience doc) the DecisionService class extends Invocable which extends DRGElement.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Transitive information requirements maybe inferred from the spec text

  • Key: DMN12-225
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Page 60 para 5 says:
    "As explained above, every information requirement at the DRG level is associated with a variable used at the decision
    logic level. Each variable that is referenced by a decision’s expression must be a variable referenced by one of the
    decision’s information requirements or an information requirement in the decision's requirement subgraph."

    Page 177 Glossary entry for "Requirement Subgraph" says:
    "The directed graph resulting from the transitive closure of the
    requirements of a DRG element; i.e., the sub-graph of the DRG
    representing all the decision-making required by a particular element"

    From these two entries one could erroneously infer that Information Requirement is transitive in nature. This creates serious concerns for BKMs and Decisions Services.

  • Reported: DMN 1.1 — Mon, 29 Jan 2018 18:55 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    *Review text section 7.1 to remove potential misinterpretation of transitivity due to subgraph def and so it better reflects meta model *

    See revised text.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Requirements don't have an ID (needed for DI)


Drg element labels

  • Key: DMN12-43
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    (from Bruce)
    A drg element name is supposed to match the name of the variable owned by the element, but many tools allow the element shape label to be different from the variable name. The spec should clarify whether this is allowed, possibly saying that the shape label is explicitly the label attribute and not the name.

  • Reported: DMN 1.1 — Sat, 14 May 2016 23:32 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    DMN12-93 explains that name is preferred to label if it exists

    Also says label is not used in notation. This should clarify any confusion.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Eliminate () from FEEL and S-FEEL

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

    The notation for ranges in FEEL currently allows ( ) , [ ] , ][ or combinations to show inclusive or exclusive ranges. The use of ( ) to show exclusive ranges is extremely confusing to non-computer science people. The non-technical assumption is that all ranges are inclusive and the distinction between ( and [ is too minor - it forces people to KNOW where they should be able to intuit.
    If we remove support for () but leave support for ][ we don't eliminate the ability to use exclusive ranges, we just make it much clearer.

  • Reported: DMN 1.1 — Tue, 19 Jan 2016 23:37 GMT
  • Disposition: Closed; No Change — DMN 1.2
  • Disposition Summary:

    no change because some people are using the feature

    no change

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Add id to context entry


DMN 1.1 XML schema starts with ZERO WIDTH NO-BREAK SPACE (U+FEFF)

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

    The DMN 1.1 XML schema (dmn.xsd) starts with zero width no-break space character (U+FEFF).

    This can be seen with less dmn.xsd:

    <U+FEFF><?xml version="1.0" encoding="UTF-8"?>
    <xsd:schema xmlns="http://www.omg.org/spec/DMN/20151101/dmn11.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.omg.org/spec/DMN/20151101/dmn11.xsd" elementFormDefault="qualified">
    ...
    

    Proposal:
    Remove the character using sed 's/\xef\xbb\xbf//g' dmn.xsd > fine.xsd

  • Reported: DMN 1.1 — Tue, 12 Jul 2016 22:45 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Remove zero-width non-breaking space from DMN XML schema

    Remove the character using sed 's/\xef\xbb\xbf//g' dmn.xsd > fine.xsd

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Scope of Variables in Context Boxed Expression

  • Key: DMN12-33
  • Status: closed  
  • Source: Sapiens Decision NA ( Mr. Gil Ronen)
  • Summary:

    Visibility (scope) for variables in Context Boxed Expressions that have a final result box is not clear; The spec does not address whether they are available through dot notation or are they local in scope and not accessible from outside the Context. For Contexts without a final result box it is implied that the variables are accessible through dot notation.

  • Reported: DMN 1.1 — Thu, 5 May 2016 15:48 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    clarify that context entries visible iff no result box

    See revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

some/every ... satisfies not defined for empty list

  • Key: DMN12-87
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Table 37 gives semantics but does not cover empty list

  • Reported: DMN 1.1 — Thu, 25 Aug 2016 15:26 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    define some... of empty list to be false and every... of empty list to be true

    See revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Table 45 does not provide the semantic of addition and subtraction between elements of type Date and Duration

  • Key: DMN12-211
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Table 45 does not explicitly state semantics of arithmetics for date and duration values

  • Reported: DMN 1.1 — Tue, 14 Nov 2017 16:42 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    add 4 rows to table 45 (now 49) to account for date input/output

    see revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

FEEL precedence for function definition

  • Key: DMN12-162
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    on page 109: "Operator precedence is given by the order of the alternatives in grammar rules 1, 2 and 4, in order from lowest to highest."

    But grammar rule 2.a and 1.b contains "function definition". Therefore the precedence of a function definition is not clearly specified. Should we use 2.a (lower precedence) or 1.b (higher precedence) for a function definition?

  • Reported: DMN 1.1 — Wed, 3 May 2017 08:47 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    remove redundant grammar rule for function defn and reverse rules 1a and 1b

    The current grammar has a duplicate reference to the function definition rule. Rules 1a and 1b are also in the wrong priority order.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Metamodel is missing the "kind" attribute on function


Return All Annotations for All Hit Policies

  • Key: DMN12-124
  • Status: closed  
  • Source: Sapiens Decision NA ( Mr. Gil Ronen)
  • Summary:

    Typically, we want to know all the reasons for a conclusion and this requires metadata information about all the Hits even when returning a single conclusion.

    For example, for an ‘Any’ Hit Policy Decision Table that results in the conclusion ‘Ineligible’ we want to know that the reasons are ‘Credit score too low’ and ‘Debt-to-income ratio too high’. Similarly, for an aggregated result using ‘Sum’ in the Decision ‘Total Tuition’, besides the total of $1,300, we want to know that the total includes ‘Materials $350’ and ‘Classes $950’.

    Possible approaches:
    1. Attribute on the Decision Table itself that includes a list of annotation columns to return in full regardless of the Hit Policy.
    2. By default, always return all the annotations.

  • Reported: DMN 1.1 — Thu, 5 Jan 2017 15:46 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Annotation Outputs

    See attached (version 6).
    Higher resolution figures attached as pptx.
    MM attached.
    XSD change linked.

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Parameter names of built-in function date and time(date, time) are not allowed by name rules

  • Key: DMN12-195
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    Table 58 on page 131 defines the built-in function date and time(date, time) with parameter name "date" and parameter name "time".

    But on page 109 additional syntax rules are listed:
    "A name start (grammar rule 28) SHALL NOT be a language keyword."

    These two definitions are conflicting.

    Since "date" and "time" are language keywords (listed in grammar rule 62 for date time literal) the parameter names are illegal. The invocation of the built-in function with named parameters is not possible:
    date and time(date: date("2017-01-01"), time: time("11:00:00"))

    The recommendation is to define other named parameter names for the built-in function:

    • rename "date" parameter to "date part"
    • rename "time" parameter to "time part"
  • Reported: DMN 1.1 — Thu, 21 Sep 2017 14:19 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    remove date builtins as keywords

    see revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Table 45 does not provide the semantic of addition and subtraction between two elements of type date

  • Key: DMN12-189
  • Status: closed   Implementation work Blocked
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    A row is missing in table 45 to present the addition and subtraction semantic when e1 and e2 are both of type Date.

  • Reported: DMN 1.1 — Wed, 20 Sep 2017 19:45 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Clarify semantics of addition/subtraction between dates and date and time values on table 45

    Table 45 does not explicitly state semantics of arithmetics for date and date and time values.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Unclear meaning of unique name constraint for ItemDefinitions and DRGElements

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

    The following sentence on page 65 / 69 in paragraph 7.3.2 has been interpreted differently:

    "The name of an ItemDefinition element SHALL be unique within the containing instance of Definitions and its associated namespace"

    Also, may be common to use same name for input data and an item definition that describes its shape, e.g. PurchaseOrder.

    Need to account for namespaces (uniqueness always within Definitions element)

    At least, all the 'variables' should have unique names, that is, Decisions, InputData, BKMs, and DecisionServices must have unique names within the containing Definitions. Further, all ItemDefinitions must have unqiue names (but could duplicate an input data, e.g.).

    Imported elements are qualified by the name of the import. e.g. short.my-decision + 1

  • Reported: DMN 1.1 — Tue, 14 Mar 2017 08:39 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    re-phrase unique name constraint for ItemDefinitions

    improve description of unique name constraint for ItemDefinitions to make clear that it refers to ItemDefinition only

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Parameter domain for built-in function years and months duration() is wrong

  • Key: DMN12-187
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    Table cell of table 58 says that date and time is the needed type, but example in last column uses date. Therefore, please change the text in the Parameter Domain cell to "both are date".

  • Reported: DMN 1.1 — Fri, 1 Sep 2017 14:07 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    explicitly allow date args to years and months duration builtin

    see revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Decision table is not a good example of a builtin function

  • Key: DMN12-84
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    10.3.2.11 Function Semantics
    FEEL functions can be
     built-in, e.g., decision table (see 10.3.4.6 Decision Table), or

    Actually, decision table is not a real builtin function (as DMN12-81 points out), so a better example is something like sum()

    should remove textual decision table builtin (ch 10) and use schematic DT boxed expr instead (something like Figure 36)

  • Reported: DMN 1.1 — Thu, 25 Aug 2016 05:45 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    remove all mention of decision table builtin function

    Decision tables are an aggregation of LiteralExpressions, UnaryTests, and other things, but are not actually builtin functions because UnaryTests have no interpretation by themselves. See Revised Text.

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

X and TBD are undefined in Table 35

  • Key: DMN12-83
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    I think both mean that 'no mapping is defined' and probably a blank cell would be better. And the text should say 'a blank cell means no mapping is defined'.

  • Reported: DMN 1.1 — Thu, 25 Aug 2016 05:39 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    replace 'X' and 'TBD' in Table 35 with empty cells

    see revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

grammar rule 56 missing comma

  • Key: DMN12-86
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    change
    56. list = "[" [ expression ,

    { "," , expression } ] , "]" ;
    to
    56. list = "[" , [ expression , { "," , expression }

    ] , "]" ;

  • Reported: DMN 1.1 — Thu, 25 Aug 2016 15:20 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    add comma to grammar rule 56

    see revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Different definition of hit policy collect aggregations in FEEL and DMN

  • Key: DMN12-175
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    On page 83 for DMN: "the result of the decision table is the sum of all the distinct outputs"
    On page 137 for FEEL built-in function: "return the sum of the outputs"

    Same applies to count aggregation.

    Why does a DMN decision table only aggregates distinct values, but a FEEL built-in function does not?

    Is this difference between the DMN Decision Table in chapter 8 and the FEEL built-in function in chapter 10 the intended meaning?

  • Reported: DMN 1.1 — Fri, 26 May 2017 09:28 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    remove 'distinct' from hit policy aggregation definitions

    see attached Word document

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

clarify format of time literals / resolve inconsistency

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

    page 132/136, in table 58, shows the following example:
    time(“T23:59:00z")
    The time literal string has a leading 'T'.

    Other areas of the spec define time strings as:
    "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, ..."

    As far as I know, XML schema and the ISO standard do not define a leading 'T' for time literals.

    Let's clarify this and get all examples consistent.

  • Reported: DMN 1.1 — Tue, 28 Feb 2017 13:56 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    remove leading 'T' from all time literal examples

    remove leading 'T' from all time literal examples

  • Updated: Wed, 3 Oct 2018 14:17 GMT

decision table structure in 8.1 does not agree with MM

  • Key: DMN12-148
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Inputs are said to be a set, and each input is said to contain the input entries. But according to the MM, inputs (really input clauses) are a list, and each input does not contain the input entries, but rather implicitly references the input entries in the rules by position. Similar issue for outputs.

    Trouble continues in 8.2.1, where it says there is a double line between input/output expressions and the rule entry cells. There are no output expressions. Probably, given that the clauses in the MM do not include the entry cells (those are contained in the rules), we should say the double line is between the clauses and the rules.

  • Reported: DMN 1.1 — Mon, 20 Mar 2017 05:30 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Align text in Ch 8 with metamodel

    see revised text

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Output Order hit policy on pg 85 is incorrect

  • Key: DMN12-149
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Compare with priority policy. Correct to

    if the associated hitPolicy is OUTPUT ORDER, the value of an instance of DecisionTable is the list of the values of the conclusions of all the applicable rules, according to the ordering of the outputEntry in the list
    of output values

  • Reported: DMN 1.1 — Mon, 20 Mar 2017 23:44 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Remove redundant out of date semantics and point to 10.3.2.8

    The 'semantics' in 8.3.1 is redundant with 10.3.2.8. It is also out of date, e.g. there is no 'conclusion' in the metamodel anymore. Let's remove it.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Add specification for DMN diagrams layout

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

    Currently the standard contains a specification of the AST. It does not contain a specification for the CS of the diagrams (e.g. (x,y) coordinates of the DRG elements on the screen).

    Having such a specification will make the diagrams portable between different tool providers.

    One way of doing it is to have an optional (backwards compatibility) section at the end of the DMN document with DRGElement Views that contain the graphical info (e.g. coordinates, color etc) and references by ID to the AST elements (e.g. DRGElements)

  • Reported: DMN 1.1 — Tue, 14 Mar 2017 09:36 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    Duplicate of DMN12-20

    DMN12-20/DMN12-62 will add Diagram Interchange to DMN.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Duplicate definition of BKM/@variable in Table 14

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

    On page 50 (PDF 54) in Table 14 "BusinessKnowledgeModel attributes and model associations" the attribute variable is defined twice:

    variable: InformationItem The instance of InformationItem that is bound to the function. An invocation can reference this variable by name.
    variable: InformationItem This attribute defines a variable that holds the FunctionDefinition, allowing a Decision to invoke it by name.
  • Reported: DMN 1.1 — Wed, 8 Mar 2017 14:00 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Merge duplicate definitions of BKM/@variable in Table 14

    Merge the two descriptions into one.

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Missign Comma in Grammar Rule 48 (some/every...)

  • Key: DMN12-127
  • Status: closed   Implementation work Blocked
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    On page 109 (PDF 113) the grammar rule 48 "quantified expression" is missing a comma. It should look similar to rule 46.

  • Reported: DMN 1.1 — Thu, 26 Jan 2017 13:28 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Add missing comma in grammar rule 48 "quantified expression"

    Add "," to grammar rule 48 similar to rule 46.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

singular helping verb used with plural subject

  • Key: DMN12-103
  • Status: closed  
  • Source: IBM Cloud Support ( Tom Scanlan)
  • Summary:

    Last sentence in Scope section uses both "have" and "has" for the same plural subject "authors".

    "The authors have brought forth expertise and experience from the existing decision modeling community and has sought
    to consolidate the common ideas from these divergent notations into a single standard notation."

    --> Correction: change "has" to ""have".

  • Reported: DMN 1.1 — Wed, 26 Oct 2016 15:19 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    Change 'has' to 'have'

    Fix grammar in one sentence

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Alternative DRD representation of BKM

  • Key: DMN12-36
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    (raised by Bruce)
    By allowing reuse of a value expression, BKMs provide useful semantics. But their representation in DRD adds visual complexity without a lot of value. The Chapter 11 example in the spec is a good example. Representing both the calling decision and the called BKM in the diagram effectively doubles the number of elements in the DRD, while the knowledge requirement connector does not reveal the elements used in the BKM value expression. As an alternative, a distinctive marking in the DRD of a decision invoking a BKM could provide virtually the same information without adding clutter to the diagram. Since DRD is a filtered and truncated view of the DRG, a tool could already do this today, but not in any standardized notation.

  • Reported: DMN 1.1 — Mon, 9 May 2016 19:22 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    *duplicate *

    duplicate

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Expressions in Input Entries

  • Key: DMN12-32
  • Status: closed  
  • Source: Sapiens Decision NA ( Mr. Gil Ronen)
  • Summary:

    Input Entries are defined as unary tests and as such do not allow even simple expressions. The need to exit the decision table into other FEEL constructs for simple expressions such as “Dividend Income * 0.30” makes the overall logic less readable. There are currently several tools that support expressions in decision table cells and this feature is also on Jan and James’ wishlist. The latter wrote about in more detail (http://blog.luxmagi.com/2016/04/our-dmn-2-0-wish-list-i-decision-logic/) so I won’t repeat it except to quote “This is something we see a lot of demand for by business users of DMN ‘in the field’.”

  • Reported: DMN 1.1 — Thu, 5 May 2016 13:16 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    duplicate

    duplicate

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Collection Operators

  • Key: DMN12-31
  • Status: closed  
  • Source: Sapiens Decision NA ( Mr. Gil Ronen)
  • Summary:

    Modeling with collections of items are fundamental to much business processing (as was noted in various LinkedIn threads). Simple comparisons such as ‘does A,B contain A’ should be done in decision tables using dedicated operators and not require exiting to FEEL and structures external to the decision tables. Several tools already support these operators. While you can write these expressions in FEEL it is useful that a table segregates each row as a rule so that one row matches "list contains both a and b", the next row matches "list contains c or e", etc. We find these representations of the logic to be both common and easily understood by business folks. The proposal is to add ‘Is In’, ‘Contains’ and ‘Contains Any’ operators and their negation (symbols can be used instead of the full operator textual name).

    Attached images show this feature used in a business setting.

    Examples below of how these operators work (1st element is the Input Expression result and the 2nd is an Input Entry):

    {A,B} Contains A returns True {A,B,C} Contains {A,B}

    returns True

    {A,B,C} Contains {A,D} returns False
    {A,B} Contains Any A returns True{A,B,C}

    Contains Any

    {A,D}

    returns True

    {A,B} Contains Any C returns False

    A Is In {A,B}

    returns True

    {A,B} Is In {A,B,C} returns True{A,B}

    Is In

    {A,C}

    returns False

  • Reported: DMN 1.1 — Thu, 5 May 2016 12:37 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    duplicate

    duplicate

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Table 47 should specify duration/duration rather than number/duration

  • Key: DMN12-24
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Table 47 gives specific semantics of multiplication and division for various types of operands. It gives a row for division of a number by a duration (e.g. 4 divided by 1 hour) which makes little sense. Instead, the case of dividing a duration by a duration (e.g. 1 hour divided by 15 minutes equals 4) should be specified.

  • Reported: DMN 1.1 — Tue, 1 Mar 2016 06:27 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    change table 47 to remove number/duration and add duration/duration

    Apply editing instructions in Revised Text.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Missing comma to split “in” in quantified expression in FEEL syntax

  • Key: DMN12-53
  • Status: closed   Implementation work Blocked
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Rule 48 of Feel expression is as follow:
    48. quantified expression = ("some" | "every") , name , "in" , expression ,

    { name , "in" , expression }

    , "satisfies" ,expression ;

    Without a comma, it is really hard to tell when a new “in” part starts. The for expression, in rule 46, does add a comma to split the various in part:
    46. for expression = "for" , name , "in" , expression

    { "," , name , "in" , expression }

    , "return" , expression ;

    Recommend that Rule 48 should be as follow:
    48. quantified expression = ("some" | "every") , name , "in" , expression ,

    {“,”, name , "in" , expression }

    , "satisfies" , expression ;

  • Reported: DMN 1.1 — Wed, 15 Jun 2016 19:22 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    add comma to grammar rule 48

    Apply editing instructions in Revised Text.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

FEEL operators in names

  • Key: DMN12-42
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    If FEEL variable names can contain spaces, they should not be allowed to contain operator names like and, or, etc. for example the name "make and model" in the Collections of Cars example should not be allowed. It might be possible to determine from the context whether this is a name or an expression of 2names, it's just too hard.

  • Reported: DMN 1.1 — Sat, 14 May 2016 23:31 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    no simple backward compatible solution was found

    perhaps we need to break with backward compatablilty in 2.0

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Expressions in Input Entries

  • Key: DMN12-30
  • Status: closed  
  • Source: Sapiens Decision NA ( Mr. Gil Ronen)
  • Summary:

    Input Entries are defined as unary tests and as such do not allow even simple expressions. The need to exit the decision table into other FEEL constructs for simple expressions such as “Dividend Income * 0.30” makes the overall logic less readable. There are currently several tools that support expressions in decision table cells and this feature is also on Jan and James’ wishlist. The latter wrote about in more detail (http://blog.luxmagi.com/2016/04/our-dmn-2-0-wish-list-i-decision-logic/) so I won’t repeat it except to quote “This is something we see a lot of demand for by business users of DMN ‘in the field’.”

  • Reported: DMN 1.1 — Thu, 5 May 2016 14:34 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    similar to generalized unary tests

    any boolean expression can be a unary test, so while you cannot enter 20 * rate, you can enter ? = 20 * rate. Defer to make ?= implied if no ? in expression.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

ranges do not map to the semantic domain

  • Key: DMN12-260
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    section 10.3.2.7 Ranges says that ranges map to the semantic domain. But in DMN 1.1, ranges are unary tests and as such, do not map to the semantic domain. Also, the literal context shown is wrong, as you cannot have the entry 'soon' with value of a range (such value would have to map to the semantic domain).
    Now, in DMN 1.2, perhaps we would like to map unary tests to the semantic domain, but it must be all unary tests, and not only ranges.

    Proposed remove section 10.3.2.7

  • Reported: DMN 1.1 — Fri, 6 Apr 2018 17:36 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    defer for better spec of unary test semantics

    defer

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Enhancement suggestion: allow for expressions to be used as "end points"

  • Key: DMN12-80
  • Status: closed  
  • Source: Red Hat Inc ( Edson Tirelli)
  • Summary:

    This is a suggestion for future revisions of the specification:

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

    { Thanksgiving holiday: [ date(“2016-11-24”) .. date(“2016-11-27”) ] }

    This is extremely useful for users that no longer have to create dummy variables in order to use expressions as "end points".

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

    closed by submitter

    relevant but out of time

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Include Test Cases in Decision Model

  • Key: DMN12-49
  • 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.2
  • Disposition Summary:

    Defer new features without complete proposals due to lack of time

    May be more appropriate for DMN 2.0.

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

Change depiction of Input to be harmonized with BPMN and CMMN


Decisions can be used for many things, do we need a taxonomy?

  • Key: DMN12-25
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Decisions in DMN are actually expressions in a formal language (by default, FEEL). These expressions describe a range of computations and calculations, including constants like 42, calculations like (x-y)/2, and decisions using decision tables. It's awkward referring to constants and math formulas as 'decisions', but most of the time, decision is the right word. Should we allow some 'decoration' of the decision rectangle (e.g. an icon) to indicate whether it is a constant, a calculation, a decision, etc.?

    Another observation - InputData and BKM are not really needed to build a working DMN product. Decisions can be used instead of InputData. All your decision services would use input decisions instead of input data. Decisions can be used instead of BKMs, as there is no prohibition about a decision's logic being a FunctionDefinition. This means that decisions can invoke other decisions or simply reference them. Either way, there is an information requirement.

  • Reported: DMN 1.1 — Mon, 11 Apr 2016 19:42 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    no concrete proposal, defer

    no concrete proposal, defer

  • Updated: Wed, 3 Oct 2018 14:17 GMT

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

  • Key: DMN12-81
  • 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.2
  • Disposition Summary:

    withdrawn by submitter

    other issues have addressed key points, no longer relevent

  • Updated: Wed, 3 Oct 2018 14:17 GMT

DMN v1.2 specification