Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — All Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN16-16 Lexical representation of time string has ambiguous definitions DMN 1.1 open
DMN16-119 Knowledge Sources are not fit for ML or AI purposes DMN 1.5 open
DMN16-101 No binding to Python functions DMN 1.5 open
DMN16-64 Clarification on syntax of DMNReference needed DMN 1.3 open
DMN16-55 No way to tell that a Decision iterates over a collection DMN 1.3 open
DMN16-11 Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration DMN 1.1 open
DMN16-117 Returning null is not enough for reporting/handling errors DMN 1.5b1 open
DMN16-91 Binary operators should not return null DMN 1.5 open
DMN16-104 Missing paragraph break and new constraintType DMN 1.5b1 open
DMN16-94 Filter and Iterator in attribute should not require a collection DMN 1.5b1 open
DMN16-92 Inconsistent capitalization of datatypes names DMN 1.5b1 open
DMN16-82 Behaviour when decimal is provided but integer expected DMN 1.5b1 open
DMN16-81 Range of scale for number is open to interpretation DMN 1.5b1 open
DMN16-72 FEEL descendants operator DMN 1.4b1 open
DMN16-50 Missing semantics for multiple imports DMN 1.3 open
DMN16-24 Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122 DMN 1.1 open
DMN16-18 More Generic Ways to Define Decision Table Properties DMN 1.1 open
DMN16-5 XSD: global context DMN 1.0 open
DMN16-4 Business Knowledge Model can have Information Requirements DMN 1.0 open
DMN16-2 No notation for ItemDefinition DMN 1.0 open
DMN16-61 Change to the "at literal" in FEEL DMN 1.3 open
DMN16-62 Adding a new interval built-in function DMN 1.3 open
DMN16-112 XML serialization is not human friendly DMN 1.5b1 open
DMN16-106 Duplicated names and labels DMN 1.5b1 open
DMN16-105 Add `number(from: number)` function DMN 1.5b1 open
DMN16-90 Allow ONNX as well as PMML functions DMN 1.5 open
DMN16-48 Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression DMN 1.3 open
DMN16-93 Rounding functions introduced in DMN 1.4 should have single parameter version DMN 1.5b1 open
DMN16-6 Include Test Cases in Decision Model DMN 1.1 open
DMN16-3 italics and bold used for both typographic literal notation and FEEL semantic exposition DMN 1.0 open
DMN16-1 Business Context links go both ways DMN 1.0 open
DMN16-85 Grammar rule does not match with the one proposal - typo DMN 1.5b1 open
DMN16-71 Friendly enough cohersion to string DMN 1.4b1 open
DMN16-66 Missing InformationItem Association? DMN 1.3 open
DMN16-68 No Mapping of FEEL to JSON DMN 1.4 open
DMN16-79 Relation conforms to and equivalent do not cover functions with variable arguments DMN 1.5b1 open
DMN16-78 It is not possible to assign a default value to a data type DMN 1.4 open
DMN16-77 No way to show dependencies of a grey-box decision service DMN 1.5 open
DMN15-104 Acknowledgements for DMN 1.4 and 1.5 contributors needed DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-159 New Namespace URIs needed DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-155 Superfluous spaces after "1" DMN 1.4 DMN 1.5 Resolved closed
DMN15-157 Copyright section needs update DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-153 Multiple empty imports using the order as a precedence is not allowed DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-119 Incorrect function name in example DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-118 Typo in Table 66 DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-56 Typos in meta model DMN 1.2 DMN 1.5 Resolved closed
DMN15-135 Precision on Allowed Values UnaryTests DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-65 spec places unrealistic constraints on decision expressions and BKM parameter bindings DMN 1.3 DMN 1.5 Resolved closed
DMN15-44 Clarification regarding equivalence of date vs date and time DMN 1.2 DMN 1.5 Resolved closed
DMN15-6 Depiction of Input Data is not harmonized with BPMN and CMMN DMN 1.1 DMN 1.5 Resolved closed
DMN15-121 It is not possible to use a range of Dates as an iteration context DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-143 Missing FEEL function to replace items in a list DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-125 Lists and filters section does not provide a dot accessor "." example with null DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-27 Improvement of Semantic Domains Specification DMN 1.1 DMN 1.5 Closed; No Change closed
DMN15-42 data equivalence with date and time DMN 1.2 DMN 1.5 Duplicate or Merged closed
DMN15-76 The "schemaLocation" relative URLs are broken DMN 1.3 DMN 1.5 Closed; No Change closed
DMN15-74 Incorrect typeRef for variables associated to BKMs DMN 1.3 DMN 1.5 Resolved closed
DMN15-120 Wording in section above does not match the rule 35 in grammar DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-98 DMN 1.4 updated XMI references external file DMN14.mdxml DMN 1.4 DMN 1.5 Closed; No Change closed
DMN15-36 No way to represent a black-box or incompletely defined Decision Service DMN 1.2 DMN 1.5 Deferred closed
DMN15-142 Misprint in DMN 1.4b1 DMN 1.5 Duplicate or Merged closed
DMN15-149 Typo - "duraion" DMN 1.4 DMN 1.5 Duplicate or Merged closed
DMN15-45 Clean up example xml files DMN 1.2b1 DMN 1.5 Closed; No Change closed
DMN15-108 Positive unary tests lack equality operators DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-88 UNused Requirements are considered invalid DMN 1.4 DMN 1.5 Resolved closed
DMN15-78 Underspecified when ranges may include a qualified name for the endpoint, which resolves to null DMN 1.3 DMN 1.5 Resolved closed
DMN15-99 No built-in function to support Range conversion DMN 1.4 DMN 1.5 Resolved closed
DMN15-86 Table 62 limited to "negative numbers" DMN 1.4 DMN 1.5 Resolved closed
DMN15-94 Typo in "10.3.1.2 Grammar rules" 3rd bulletpoint in the bottom DMN 1.4 DMN 1.5 Resolved closed
DMN15-107 No support for numbers in scientific notation DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-137 Allowed Values for collection item definitions DMN 1.4b1 DMN 1.5 Duplicate or Merged closed
DMN15-131 Another False, or at least ignored statement by most vendors DMN 1.4b1 DMN 1.5 Duplicate or Merged closed
DMN15-130 False, or at least ignored statement by most if not all vendors DMN 1.4b1 DMN 1.5 Duplicate or Merged 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-4 Business Knowledge Model can have Information Requirements DMN 1.0 DMN 1.5 Deferred closed
DMN15-2 No notation for ItemDefinition DMN 1.0 DMN 1.5 Deferred closed
DMN15-5 XSD: global context DMN 1.0 DMN 1.5 Deferred closed
DMN15-7 Include Test Cases in Decision Model DMN 1.1 DMN 1.5 Deferred closed
DMN15-3 italics and bold used for both typographic literal notation and FEEL semantic exposition DMN 1.0 DMN 1.5 Deferred closed
DMN15-96 Gaps: Range as input, mapping to JSON, evaluation of non-FEEL expression languages DMN 1.4 DMN 1.5 Duplicate or Merged closed
DMN15-83 Typo in 6.3.7 Decision metamodel DMN 1.4 DMN 1.5 Resolved closed
DMN15-18 Enumerations can only be defined as strings DMN 1.1 DMN 1.5 Closed; Out Of Scope closed
DMN15-109 There are questions regarding precedence of operator between negation and exponation DMN 1.4 DMN 1.5 Resolved closed
DMN15-81 Typo in 8.3.1 Decision Table metamodel "DecsionTable" DMN 1.4 DMN 1.5 Resolved closed
DMN15-1 Business Context links go both ways DMN 1.0 DMN 1.5 Deferred closed
DMN15-106 Incorrect reference to FEEL rule DMN 1.4b1 DMN 1.5 Duplicate or Merged closed
DMN15-79 Typo in the DMN 1.4 XSD schema (complexType tFilter) DMN 1.4 DMN 1.5 Closed; No Change 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-10 Should encapsulated decisions of a decision service include output decisions? DMN 1.0 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-39 inconsistent date comparisons make unavoidavle paradoxes DMN 1.2 DMN 1.5 Deferred closed
DMN15-29 Requested additional built-in functions DMN 1.1 DMN 1.5 Deferred closed
DMN15-52 Inconsistency DMNv1.2 dropping [a]=a and get entries example DMN 1.2b1 DMN 1.5 Deferred closed
DMN15-57 Add an itemKind property to ItemDefinition DMN 1.3b1 DMN 1.5 Deferred closed
DMN15-55 Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression DMN 1.3 DMN 1.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-38 DMN Models need a default timezone DMN 1.2 DMN 1.5 Deferred closed
DMN15-40 Situational Data Model and Notation (SDMN) DMN 1.2b1 DMN 1.5 Deferred closed
DMN15-35 Unspecified conclusion is not supported DMN 1.1 DMN 1.5 Deferred closed
DMN15-37 Fix interchange of links to objects in BPMN/BMM DMN 1.2 DMN 1.5 Deferred closed
DMN15-48 Lack of visual notation for processing of / iteration over lists in FEEL DMN 1.2 DMN 1.5 Deferred closed
DMN15-49 Support for recursive calls by Business Knowledge Models DMN 1.2 DMN 1.5 Deferred closed
DMN15-51 properly define type(e) DMN 1.2 DMN 1.5 Deferred closed
DMN15-41 Knowledge Package Model and Notation (KPMN) DMN 1.2b1 DMN 1.5 Deferred closed
DMN15-50 Clarification on DMN case sensitivity of timezones DMN 1.2 DMN 1.5 Deferred closed
DMN15-53 "instance of" not possible with some built-in functions DMN 1.2b1 DMN 1.5 Deferred closed
DMN15-54 Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests. DMN 1.3 DMN 1.5 Deferred closed
DMN15-43 Temporal precision inconsistencies DMN 1.2b1 DMN 1.5 Deferred closed
DMN15-46 Provide better spec and examples for Equality, Identity, and Equivalence DMN 1.2b1 DMN 1.5 Deferred closed
DMN15-47 Friendlier handling of null values DMN 1.2b1 DMN 1.5 Deferred closed
DMN15-58 Missing semantics for multiple imports DMN 1.3 DMN 1.5 Deferred closed
DMN15-61 DRG requirements only state am unused knowledge requirement is illegal DMN 1.3 DMN 1.5 Deferred closed
DMN15-59 Spec does not mandate that all user-defined function parameters are utilised DMN 1.3 DMN 1.5 Deferred closed
DMN15-62 No way to show relative multiplicity of decisions and their information requirements DMN 1.3 DMN 1.5 Deferred closed
DMN15-60 Spec does not mandate that all formal parameters are utilised. DMN 1.3 DMN 1.5 Deferred closed
DMN15-63 No way to tell that a Decision iterates over a collection DMN 1.3 DMN 1.5 Deferred closed
DMN15-64 P0D == P0Y in SFEEL, but it is unclear if P0D == P0Y in FEEL DMN 1.3 DMN 1.5 Deferred closed
DMN15-66 the operation of is() function is not well specified DMN 1.3 DMN 1.5 Deferred closed
DMN15-69 Allow for partial temporal values DMN 1.3 DMN 1.5 Deferred closed
DMN15-68 FunctionItem `parameters` array attribute is plural, not singular in name DMN 1.3 DMN 1.5 Deferred closed
DMN15-72 Allow input data to be of type Interval DMN 1.3 DMN 1.5 Deferred closed
DMN15-67 Ambiguous named params for before() and after() range functions DMN 1.3 DMN 1.5 Deferred closed
DMN15-70 Change to the "at literal" in FEEL DMN 1.3 DMN 1.5 Deferred closed
DMN15-71 Adding a new interval built-in function DMN 1.3 DMN 1.5 Deferred closed
DMN15-75 Links with other standards DMN 1.3 DMN 1.5 Deferred closed
DMN15-101 No Mapping of FEEL to JSON DMN 1.4 DMN 1.5 Deferred closed
DMN15-73 Clarification on syntax of DMNReference DMN 1.3 DMN 1.5 Deferred closed
DMN15-77 Missing InformationItem Association? DMN 1.3 DMN 1.5 Deferred closed
DMN15-91 Functions cannot invoke external services DMN 1.4 DMN 1.5 Deferred closed
DMN15-139 Import into default namespace is undefined DMN 1.4b1 DMN 1.5 Resolved closed
DMN15-151 Friendly enough cohersion to string DMN 1.4b1 DMN 1.5 Deferred closed
DMN15-123 Importing libraries of functions is not business friendly DMN 1.4b1 DMN 1.5 Deferred closed
DMN15-124 Interchanging models that use external libraries of functions is complicated DMN 1.4b1 DMN 1.5 Deferred closed
DMN16-67 Functions cannot invoke external services DMN 1.4 open
DMN16-69 Importing libraries of functions is not business friendly DMN 1.4b1 open
DMN16-73 Incorrect names for parameters DMN 1.4b1 open
DMN16-70 Interchanging models that use external libraries of functions is complicated DMN 1.4b1 open
DMN16-65 Links with other standards DMN 1.3 open
DMN16-59 FunctionItem `parameters` array attribute is plural, not singular in name DMN 1.3 open
DMN16-60 Allow for partial temporal values DMN 1.3 open
DMN16-63 Allow input data to be of type Interval DMN 1.3 open
DMN16-56 P0D == P0Y in SFEEL, but it is unclear if P0D == P0Y in FEEL DMN 1.3 open
DMN16-57 the operation of is() function is not well specified DMN 1.3 open
DMN16-58 Ambiguous named params for before() and after() range functions DMN 1.3 open
DMN16-53 DRG requirements only state am unused knowledge requirement is illegal DMN 1.3 open
DMN16-51 Spec does not mandate that all user-defined function parameters are utilised DMN 1.3 open
DMN16-52 Spec does not mandate that all formal parameters are utilised. DMN 1.3 open
DMN16-54 No way to show relative multiplicity of decisions and their information requirements DMN 1.3 open
DMN16-49 Add an itemKind property to ItemDefinition DMN 1.3b1 open
DMN16-45 Inconsistency DMNv1.2 dropping [a]=a and get entries example DMN 1.2b1 open
DMN16-44 properly define type(e) DMN 1.2 open
DMN16-43 Clarification on DMN case sensitivity of timezones DMN 1.2 open
DMN16-46 "instance of" not possible with some built-in functions DMN 1.2b1 open
DMN16-47 Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests. DMN 1.3 open
DMN16-42 Support for recursive calls by Business Knowledge Models DMN 1.2 open
DMN16-39 Provide better spec and examples for Equality, Identity, and Equivalence DMN 1.2b1 open
DMN16-40 Friendlier handling of null values DMN 1.2b1 open
DMN16-41 Lack of visual notation for processing of / iteration over lists in FEEL DMN 1.2 open
DMN16-37 Knowledge Package Model and Notation (KPMN) DMN 1.2b1 open
DMN16-38 Temporal precision inconsistencies DMN 1.2b1 open
DMN16-30 need set operations and equality in FEEL DMN 1.1 open
DMN16-31 notion of arbitrary order conflicts with lack of an unordered collection data type DMN 1.1 open
DMN16-34 DMN Models need a default timezone DMN 1.2 open
DMN16-32 Unspecified conclusion is not supported DMN 1.1 open
DMN16-33 Fix interchange of links to objects in BPMN/BMM DMN 1.2 open
DMN16-36 Situational Data Model and Notation (SDMN) DMN 1.2b1 open
DMN16-35 inconsistent date comparisons make unavoidavle paradoxes DMN 1.2 open
DMN16-26 Requested additional built-in functions DMN 1.1 open
DMN16-28 Collect decision tables DMN 1.1 open
DMN16-27 Metamodel constraints & validation DMN 1.1 open
DMN16-29 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 open
DMN16-21 Can an expression in user defined function body reference a name outside of it's scope? DMN 1.1 open
DMN16-22 Should name declarations in same context fail or overwrite? DMN 1.1 open
DMN16-23 Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test DMN 1.1 open
DMN16-25 Semantic domain mapping for simple expressions DMN 1.1 open
DMN16-14 Can the same Definitions/namespace be used by more than one model? DMN 1.1 open
DMN16-15 Add two new concrete numeric types, make number abstract DMN 1.1 open
DMN16-17 FEEL grammar readability DMN 1.1 open
DMN16-20 How to get FEEL type if evaluation is not an option? DMN 1.1 open
DMN16-19 Scope of decision table input/output entries is not well defined in the specification DMN 1.1 open
DMN16-10 No adjustment for last day in month if duration is added/subtracted to date and time value DMN 1.1 open
DMN16-7 Enhancement suggestion: make unary tests first class citizens of the FEEL language DMN 1.1 open
DMN16-9 Should encapsulated decisions of a decision service include output decisions? DMN 1.0 open
DMN16-8 Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions DMN 1.1 open
DMN16-13 Improve description of built-in function string() DMN 1.1 open
DMN16-12 Clarification needed if null is passed as value for optional parameter of built in function DMN 1.1 open
DMN14-197 Underspecified when ranges may include a qualified name for the endpoint, which resolves to null DMN 1.3 DMN 1.4 Deferred closed
DMN14-182 New built-in function to merge/concatenate two or more contexts DMN 1.3 DMN 1.4 Duplicate or Merged closed
DMN14-183 New built-in function to create a new context DMN 1.3 DMN 1.4 Duplicate or Merged closed
DMN14-181 No function to add an entry to a context DMN 1.3 DMN 1.4 Resolved closed
DMN14-166 New XML Namespace needed DMN 1.3 DMN 1.4 Resolved closed
DMN14-194 Missing boxed expression for iterator expression DMN 1.3 DMN 1.4 Resolved closed
DMN14-192 Missing boxed expression for filter expression DMN 1.3 DMN 1.4 Resolved closed
DMN14-190 Missing boxed expression for conditional statement DMN 1.3 DMN 1.4 Resolved closed
DMN14-196 Typo Table55 row 7 DMN 1.3 DMN 1.4 Resolved closed
DMN14-178 Are the names of boxed context entries unique in a given context ? DMN 1.3 DMN 1.4 Resolved closed
DMN14-55 Incorrect example in Table 40: Examples of equivalence and conformance relations DMN 1.2 DMN 1.4 Resolved closed
DMN14-164 More examples of replace() function needed DMN 1.3 DMN 1.4 Resolved closed
DMN14-117 typo - incorrect indexing DMN 1.3 DMN 1.4 Resolved closed
DMN14-185 Incorrect figure reference DMN 1.3 DMN 1.4 Resolved closed
DMN14-87 Wrong and Incomplete FEEL grammar rule 52 DMN 1.3 DMN 1.4 Resolved closed
DMN14-156 the word 'decision' is misspelt. DMN 1.3 DMN 1.4 Resolved closed
DMN14-126 Missing functions for rounding DMN 1.3 DMN 1.4 Resolved closed
DMN14-167 Sub-decisions are referenced but not defined DMN 1.3 DMN 1.4 Resolved closed
DMN14-150 Collections are not shown on diagrams DMN 1.3 DMN 1.4 Resolved closed
DMN14-143 instance of grammar does not support range , or context, or function DMN 1.3 DMN 1.4 Resolved closed
DMN14-142 DMNDiagram 'Size' attribute has capital 'S' in schema definition DMN 1.3 DMN 1.4 Closed; No Change closed
DMN14-141 The result of product([]) is not defined DMN 1.3 DMN 1.4 Resolved closed
DMN14-74 DMNv1.3 fix DMN example files issues DMN 1.2 DMN 1.4 Resolved closed
DMN14-42 There is no way to identify current date and time, e.g. now() & today() DMN 1.1 DMN 1.4 Resolved closed
DMN14-11 Expressions cannot be used as "end points" DMN 1.1 DMN 1.4 Resolved closed
DMN14-8 Lack of visual notation for processing of / iteration over lists in DRD DMN 1.1 DMN 1.4 Deferred closed
DMN14-6 LiteralExpression and textual expression seem to mean the same thing, need to use the same term DMN 1.0 DMN 1.4 Closed; No Change closed
DMN14-61 Support for function types in metamodel and XSD DMN 1.2b1 DMN 1.4 Closed; No Change closed
DMN14-56 Spec does not clarify meaning of hex value DMN 1.2b1 DMN 1.4 Closed; No Change closed
DMN14-125 Definitions of overlaps functions DMN 1.3 DMN 1.4 Resolved closed
DMN14-45 Convenience documents DMN 1.2b1 DMN 1.4 Closed; No Change closed
DMN14-137 Typo in horizontal alignment label DMN 1.3 DMN 1.4 Resolved closed
DMN14-86 Wrong example for is() built-in function DMN 1.3 DMN 1.4 Resolved closed
DMN14-85 Wrong example for distinct values() built-in function DMN 1.3 DMN 1.4 Resolved closed
DMN14-93 Wrong XSD for tDecisionService DMN 1.3 DMN 1.4 Closed; No Change closed
DMN14-88 First (and priority) hit policy are unpredictable with partial input DMN 1.3 DMN 1.4 Closed; No Change closed
DMN14-136 Extend endpoints to support expressions DMN 1.3 DMN 1.4 Duplicate or Merged closed
DMN14-52 Clarify method signature syntax for Java Function Definition DMN 1.2 DMN 1.4 Closed; No Change closed
DMN14-116 DMN string join built-in function proposal DMN 1.3 DMN 1.4 Resolved closed
DMN14-36 FEEL ambiguity DMN 1.1 DMN 1.4 Resolved closed
DMN14-20 Wrong character in expression for PMT function definition DMN 1.1 DMN 1.4 Closed; No Change closed
DMN14-1 BigDecimal is not the only mapping of number to Java DMN 1.0 DMN 1.4 Closed; No Change closed
DMN14-46 DMN 1.3 Metamodel DMN 1.2b1 DMN 1.4 Closed; No Change closed
DMN14-73 Wrong example for 10.6.1 Context Figure 10.18: Example context DMN 1.2 DMN 1.4 Resolved closed
DMN14-72 Wrong example for substring() builtin funciton DMN 1.2 DMN 1.4 Resolved closed
DMN14-75 Wrong example snippet in 10.3.2.9.4.1 Examples DMN 1.2 DMN 1.4 Resolved closed
DMN14-23 Enumerations can only be defined as strings DMN 1.1 DMN 1.4 Deferred closed
DMN14-22 Lexical representation of time string has ambiguous definitons DMN 1.1 DMN 1.4 Deferred closed
DMN14-21 Add two new concrete numeric types, make number abstract DMN 1.1 DMN 1.4 Deferred closed
DMN14-19 Can the same Definitions/namespace be used by more than one model? DMN 1.1 DMN 1.4 Deferred closed
DMN14-18 Improve description of built-in function string() DMN 1.1 DMN 1.4 Deferred closed
DMN14-17 Clarification needed if null is passed as value for optional parameter of built in function DMN 1.1 DMN 1.4 Deferred closed
DMN14-16 Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration DMN 1.1 DMN 1.4 Deferred closed
DMN14-14 Should encapsulated decisions of a decision service include output decisions? DMN 1.0 DMN 1.4 Deferred closed
DMN14-13 Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions DMN 1.1 DMN 1.4 Deferred closed
DMN14-12 Enhancement suggestion: make unary tests first class citizens of the FEEL language DMN 1.1 DMN 1.4 Deferred closed
DMN14-10 Include Test Cases in Decision Model DMN 1.1 DMN 1.4 Deferred closed
DMN14-9 Change depiction of Input to be harmonized with BPMN and CMMN DMN 1.1 DMN 1.4 Deferred closed
DMN14-7 XSD: global context DMN 1.0 DMN 1.4 Deferred closed
DMN14-5 Business Knowledge Model can have Information Requirements DMN 1.0 DMN 1.4 Deferred closed
DMN14-4 italics and bold used for both typographic literal notation and FEEL semantic exposition DMN 1.0 DMN 1.4 Deferred closed
DMN14-3 No notation for ItemDefinition DMN 1.0 DMN 1.4 Deferred closed
DMN14-2 Business Context links go both ways DMN 1.0 DMN 1.4 Deferred closed
DMN14-48 inconsistent date comparisons make unavoidavle paradoxes DMN 1.2 DMN 1.4 Deferred closed
DMN14-44 Fix interchange of links to objects in BPMN/BMM DMN 1.2 DMN 1.4 Deferred closed
DMN14-43 Now way to represent a black-box or incompletely defined Decision Service DMN 1.2 DMN 1.4 Deferred closed
DMN14-41 Unspecified conclusion is not supported DMN 1.1 DMN 1.4 Deferred closed
DMN14-40 notion of arbitrary order conflicts with lack of an unordered collection data type DMN 1.1 DMN 1.4 Deferred closed
DMN14-39 need set operations and equality in FEEL DMN 1.1 DMN 1.4 Deferred closed
DMN14-38 In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement DMN 1.1 DMN 1.4 Deferred closed
DMN14-37 Collect decision tables DMN 1.1 DMN 1.4 Deferred closed
DMN14-35 Metamodel constraints & validation DMN 1.1 DMN 1.4 Deferred closed
DMN14-34 Requested additional built-in functions DMN 1.1 DMN 1.4 Deferred closed
DMN14-33 Semantic domain mapping for simple expressions DMN 1.1 DMN 1.4 Deferred closed
DMN14-32 Improvement of Semantic Domains Specification DMN 1.1 DMN 1.4 Deferred closed
DMN14-31 Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122 DMN 1.1 DMN 1.4 Deferred closed
DMN14-30 Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test DMN 1.1 DMN 1.4 Deferred closed
DMN14-29 Should name declarations in same context fail or overwrite? DMN 1.1 DMN 1.4 Deferred closed
DMN14-28 Can an expression in user defined function body reference a name outside of it's scope? DMN 1.1 DMN 1.4 Deferred closed
DMN14-27 How to get FEEL type if evaluation is not an option? DMN 1.1 DMN 1.4 Deferred closed
DMN14-26 Scope of decision table input/output entries is not well defined in the specification DMN 1.1 DMN 1.4 Deferred closed
DMN14-25 More Generic Ways to Define Decision Table Properties DMN 1.1 DMN 1.4 Deferred closed
DMN14-24 FEEL grammar readbility DMN 1.1 DMN 1.4 Deferred closed
DMN14-15 No adjustment for last day in month if duration is added/subtracted to date and time value DMN 1.1 DMN 1.4 Deferred closed
DMN14-53 Temporal precision inconsistencies DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-54 Clarification regarding equivalence of date vs date and time DMN 1.2 DMN 1.4 Deferred closed
DMN14-62 Support for recursive calls by Business Knowledge Models DMN 1.2 DMN 1.4 Deferred closed
DMN14-63 Clarification on DMN case sensitivity of timezones DMN 1.2 DMN 1.4 Deferred closed
DMN14-60 Lack of visual notation for processing of / iteration over lists in FEEL DMN 1.2 DMN 1.4 Deferred closed
DMN14-66 "instance of" not possible with some built-in functions DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-57 Clean up example xml files DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-58 Provide better spec and examples for Equality, Identity, and Equivalence DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-51 data equivalence with date and time DMN 1.2 DMN 1.4 Deferred closed
DMN14-59 Friendlier handling of null values DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-69 Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests. DMN 1.3 DMN 1.4 Deferred closed
DMN14-70 Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression DMN 1.3 DMN 1.4 Deferred closed
DMN14-71 Typos in the XMI files DMN 1.2 DMN 1.4 Deferred closed
DMN14-47 DMN Models need a default timezone DMN 1.2 DMN 1.4 Deferred closed
DMN14-49 Situational Data Model and Notation (SDMN) DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-50 Knowledge Package Model and Notation (KPMN) DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-65 Inconsistency DMNv1.2 dropping [a]=a and get entries example DMN 1.2b1 DMN 1.4 Deferred closed
DMN14-64 properly define type(e) DMN 1.2 DMN 1.4 Deferred closed
DMN14-153 No way to show relative multiplicity of decisions and their information requirements DMN 1.3 DMN 1.4 Deferred closed
DMN12-27 Lack of visual notation for processing of / iteration over lists DMN 1.1 DMN 1.2 Deferred closed
DMN13-127 Incorrect claim about the Unicode character range and EBNF character expressions DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-143 Should add a new unicode escape syntax DMN 1.2b1 DMN 1.3 Duplicate or Merged closed
DMN13-109 Ambiguty for the source/target of DMNEdge when there is multiple depictions of its source and target DMN 1.2 DMN 1.3 Resolved closed
DMN13-244 Incorrect figure 6.10 DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-181 PMML invocation output value in the case of single prediction DMN 1.2 DMN 1.3 Resolved closed
DMN13-175 A signature for the time() built in function is missing from table 66 DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-2 Decision Logic Examples DMN 1.0 DMN 1.3 Resolved closed
DMN13-125 Disambiguation for Modulo / Remainder function DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-139 Add built-in functions to support Allen's interval algebra DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-140 Incorrect grammar rule references and missing UnaryTests section in MM DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-141 Allegedly bug in Table Table 40 Examples of equivalence and conformance relations DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-132 type conversions are too spread out in Ch 10 DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-111 Remove the limitation that the second operand of exponentiation be an integer DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-156 Decision Requirement Metadata Examples DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-163 Decision Service output value in the case of single output Decision DMN 1.2 DMN 1.3 Resolved closed
DMN13-188 New FEEL URI needed DMN 1.2 DMN 1.3 Resolved closed
DMN13-178 Functions resolution DMN 1.2 DMN 1.3 Resolved closed
DMN13-242 Update the copyright section DMN 1.2 DMN 1.3 Resolved closed
DMN13-195 New acknowledgments needed DMN 1.2 DMN 1.3 Resolved closed
DMN13-191 New XML Namespace needed DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-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-7 No item definition for function definition DMN 1.0 DMN 1.3 Resolved closed
DMN13-6 Need group artifact in DRD, metamodel, and XSD DMN 1.0 DMN 1.3 Resolved 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-124 Disambiguation for Modulo / Remainder function DMN 1.2b1 DMN 1.3 Duplicate or Merged closed
DMN13-144 instance of clarification DMN 1.2 DMN 1.3 Resolved closed
DMN13-131 Make explicit reference to sample standard deviation DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-133 Wrong example in chapter "10.3.1.5" DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-106 Remove reference to SQL and PMML three value logic to eliminate misinterpretation DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-126 Built-in functions only described in chapter "10.3.2.6 Context", and not described in the "10.3.4 Built-in functions" DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-122 "get value" and "get entries" function not in built-in functions list DMN 1.2b1 DMN 1.3 Duplicate or Merged closed
DMN13-121 example shows literal inline function definition whereas grammar says function definitions only in boxed expressions. DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-120 Minor typos in the FEEL grammar DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-98 Example: Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses values inverted DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-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-1 BigDecimal is not the only mapping of number to Java DMN 1.0 DMN 1.3 Deferred 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-5 italics and bold used for both typographic literal notation and FEEL semantic exposition DMN 1.0 DMN 1.3 Deferred closed
DMN13-4 No notation for ItemDefinition DMN 1.0 DMN 1.3 Deferred closed
DMN13-3 Business Context links go both ways DMN 1.0 DMN 1.3 Deferred 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-10 XSD: global context DMN 1.0 DMN 1.3 Deferred closed
DMN13-9 LiteralExpression and textual expression seem to mean the same thing, need to use the same term DMN 1.0 DMN 1.3 Deferred closed
DMN13-8 Business Knowledge Model can have Information Requirements DMN 1.0 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-22 Should encapsulated decisions of a decision service include output decisions? DMN 1.0 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-91 Fix interchange of links to objects in BPMN/BMM DMN 1.2 DMN 1.3 Deferred closed
DMN13-90 Allow representation of black-box Decision Service DMN 1.2 DMN 1.3 Deferred closed
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-18 add richer variety of DT examples in Ch 11 DMN 1.0 DMN 1.2 Duplicate or Merged 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-9 Typo error on Business Knowledge Model DMN 1.0 DMN 1.2 Closed; No Change 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-20 Add Diagram Interchange to DMN DMN 1.0 DMN 1.2 Resolved 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-10 While BKMs enable re-use, the options for re-use are restricted to single pieces of decision logic DMN 1.0 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-14 Useful to denote which info requirements are unconditional DMN 1.0 DMN 1.2 Closed; No Change 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-5 Consider date and time datatype in S-FEEL DMN 1.0 DMN 1.2 Closed; No Change closed
DMN12-1 cannot interchange input data style DMN 1.0b1 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-12 definition of expression in glossary omits CL3 expressions DMN 1.0 DMN 1.2 Resolved 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-6 alternative indication of reusable logic in DRD DMN 1.0 DMN 1.2 Duplicate or Merged 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-8 Wrong DecisionTable class diagram (metamodel) DMN 1.0 DMN 1.2 Closed; No Change closed
DMN12-22 DMN XSD 1.0 invalid path DMN 1.0 DMN 1.2 Closed; No Change closed
DMN12-16 Business Knowledge Model can have Information Requirements DMN 1.0 DMN 1.2 Deferred closed
DMN12-15 No item definition for function definition DMN 1.0 DMN 1.2 Deferred closed
DMN12-17 LiteralExpression and textual expression seem to mean the same thing, need to use the same term DMN 1.0 DMN 1.2 Deferred 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-4 Business Context links go both ways DMN 1.0 DMN 1.2 Deferred closed
DMN12-3 Examples DMN 1.0 DMN 1.2 Deferred closed
DMN12-2 BigDecimal is not the only mapping of number to Java DMN 1.0 DMN 1.2 Deferred closed
DMN12-13 Need group artifact in DRD, metamodel, and XSD DMN 1.0 DMN 1.2 Deferred closed
DMN12-7 No notation for ItemDefinition DMN 1.0 DMN 1.2 Deferred closed
DMN12-11 italics and bold used for both typographic literal notation and FEEL semantic exposition DMN 1.0 DMN 1.2 Deferred closed
DMN12-260 ranges do not map to the semantic domain DMN 1.1 DMN 1.2 Deferred closed
DMN12-19 XSD: global context DMN 1.0 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
DMN11-81 extra level of indirection in decision table serialization is undesirable DMN 1.0 DMN 1.1 Resolved closed
DMN11-45 Define decision service DMN 1.0 DMN 1.1 Resolved closed
DMN11-176 DecisionService has no defined execution semantics, and decision model semantics in 10.4 is hard to understand DMN 1.0 DMN 1.1 Resolved closed
DMN11-164 use refs in XSD only to substitution groups DMN 1.0 DMN 1.1 Resolved closed
DMN11-155 DMN needs to provide a standard way for vendors to serialize extensions (Vendor Extensions) DMN 1.0 DMN 1.1 Resolved closed
DMN11-146 DMN XSD, MM, Attribute/Association Tables, and spec text are not consistent DMN 1.0 DMN 1.1 Resolved closed
DMN11-145 8.3.3. still speaks of condition and conclusion - supposedly removed by DMN11-81 DMN 1.0 DMN 1.1 Resolved closed
DMN11-122 DMN 1.1 Beta documents DMN 1.0 DMN 1.1 Resolved closed
DMN11-12 Reference to BMM::Objective, BPMN::Process and BPMN::Task in XMI DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-91 dmn.xsd and dmn3.xsd should be merged and list of machine readable files corrected DMN 1.0 DMN 1.1 Resolved closed
DMN11-89 Remove parameters from BKM MM - these belong at logic level DMN 1.0 DMN 1.1 Resolved closed
DMN11-64 'In DMN 1.0' now not only tedious but wrong DMN 1.0 DMN 1.1 Resolved closed
DMN11-47 Add association connector (artifact) with text label to represent conditional decision DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-99 Need for annotations and comments in DRD DMN 1.0 DMN 1.1 Resolved closed
DMN11-92 Need to clarify which DMNElements must and must not have names DMN 1.0 DMN 1.1 Resolved closed
DMN11-73 XSD: modify Import in tLiteralExpression DMN 1.0 DMN 1.1 Resolved closed
DMN11-69 inputVariable and itemDefinition are redundant in Expression metamodel DMN 1.0 DMN 1.1 Resolved closed
DMN11-58 Decision table default output DMN 1.0 DMN 1.1 Resolved closed
DMN11-54 XSD itemDefinition/typeRef and typeDefinition are underspecified and incorrect DMN 1.0 DMN 1.1 Resolved closed
DMN11-56 XSD; modify tItemDefinition by changing tItemComponent DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-50 Question on boxed invocation format DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-175 typos for DMN 1.1 RTF final report DMN 1.0 DMN 1.1 Resolved closed
DMN11-166 Information item name on DTs not correct in some figures DMN 1.0 DMN 1.1 Resolved closed
DMN11-139 Decision table MM and xsd need output label attribute DMN 1.0 DMN 1.1 Resolved closed
DMN11-137 Need InformationItem for the FunctionDefinition of a BKM DMN 1.0 DMN 1.1 Resolved closed
DMN11-127 would like to annotate Expression with typeRef DMN 1.0 DMN 1.1 Resolved closed
DMN11-123 Decision, InputData, and other containers of InformationItem do not ref ItemDefinition directly DMN 1.0 DMN 1.1 Resolved closed
DMN11-120 Knowledge Source metamodel diagram missing DMN 1.0 DMN 1.1 Resolved closed
DMN11-25 Definitions/@namespace has no purpose DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-24 Constraints on Decision Table elements unclear DMN 1.0 DMN 1.1 Resolved closed
DMN11-26 DecisionRule, InputClause & OutputClause should have ID and label for referencing in execution logs DMN 1.0 DMN 1.1 Resolved closed
DMN11-22 Expression defined as resulting in single value, but Decision may have multiple values DMN 1.0 DMN 1.1 Resolved closed
DMN11-21 input expression example 'age<25' is not legal in SFEEL grammar DMN 1.0 DMN 1.1 Resolved closed
DMN11-65 In metamodel, 'variable' should move from Information Requirement to Decision / Input Data DMN 1.0 DMN 1.1 Resolved closed
DMN11-32 Decision table completeness undefined, Complete code conflicts with Collect DMN 1.0 DMN 1.1 Resolved closed
DMN11-35 Dangling reference DMN 1.0 DMN 1.1 Resolved closed
DMN11-34 extraneous asterisks (*) DMN 1.0 DMN 1.1 Resolved closed
DMN11-60 Beta2 XSDs are broken DMN 1.0 DMN 1.1 Resolved closed
DMN11-52 authorityRequirement in XSD DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-44 Remove attribute DecisionTable/@isConsistent DMN 1.0 DMN 1.1 Resolved closed
DMN11-43 change "output expression" to "output name" DMN 1.0 DMN 1.1 Resolved closed
DMN11-30 add Definitions optional attributes exporter, exporterVersion DMN 1.0 DMN 1.1 Resolved closed
DMN11-13 DMN 1.1 RTF Issue: Negative numerics in decision tables DMN 1.0 DMN 1.1 Resolved closed
DMN11-147 Nested ItemDefinition doesn't work DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-130 Clarify defaults for decision table outputs DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-7 DMN issue: date syntax in table 29 DMN 1.0 DMN 1.1 Resolved closed
DMN11-6 DMN Issue: typo in 3rd well-formed requirement of KnowledgeRequirement DMN 1.0 DMN 1.1 Resolved closed
DMN11-4 DMN issue: typo in introduction of "Relating Logic to Decision Requirements" DMN 1.0 DMN 1.1 Resolved closed
DMN11-9 XSD internally inconsistent, does not match the spec DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-3 XMI issues from Pete Rivett DMN 1.0b1 DMN 1.1 Closed; No Change closed
DMN11-23 S-FEEL "expression" undefined DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-27 XSD: DecisionTable/rule/condition should be IDREF not IDREFS DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-109 need to add UnaryTests to MM and XSD DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-102 XSD: change type of LiteralExpression/text, ItemDefinition/typeDefinition, and (new) textAnnotation/text to xsd:string DMN 1.0 DMN 1.1 Resolved closed
DMN11-84 Decision Table metamodel and XSD should restrict input entries, input values, and output values to unary tests, and LiteralExpression for input expressions and output entries DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-88 8.2.10 calls crosstab tables "rules as columns" DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-80 XSD: make @id optional in tExpression DMN 1.0 DMN 1.1 Resolved closed
DMN11-62 FEEL/S-FEEL names DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-33 list variables in decision tables DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-76 XSD: Relation and List DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-57 Xsd typeRef and itemDefinitionRef DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-55 XSD: add optional @name to inputVariable DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-53 FEEL concatenate function DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-48 dmn3.xsd DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-42 output data symbol & comment symbol missing in DRDs DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-39 Clarify Decision/outputDefinition, DecisionTable/clause/outputDefinition, DecisionTable/@name, clause/@name DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-29 Examples DMN 1.0 DMN 1.1 Deferred closed
DMN11-152 not all references in DMN are by ID DMN 1.0 DMN 1.1 Resolved closed
DMN11-8 DMN Issue: Boxed context example of XML data is wrong DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-1 Change Tracking Document DMN 1.0b1 DMN 1.1 Closed; No Change closed
DMN11-5 DMN issue: InformationItem is not a specialization of Expression DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-2 Incorporate AB feedback into the FTF Report, the marked-up specification, and the clean specification DMN 1.0b1 DMN 1.1 Closed; No Change closed
DMN11-11 BigDecimal is not the only mapping of number to Java DMN 1.0 DMN 1.1 Deferred closed
DMN11-10 cannot interchange input data style DMN 1.0b1 DMN 1.1 Deferred closed
DMN11-66 No notation for ItemDefinition DMN 1.0 DMN 1.1 Deferred closed
DMN11-46 Consider date and time datatype in S-FEEL DMN 1.0 DMN 1.1 Deferred closed
DMN11-51 alternative indication of reusable logic in DRD DMN 1.0 DMN 1.1 Deferred closed
DMN11-31 Business Context links go both ways DMN 1.0 DMN 1.1 Deferred closed
DMN11-116 Need group artifact in DRD, metamodel, and XSD DMN 1.0 DMN 1.1 Deferred closed
DMNFTF-149 missing aggregation: BuiltinAggregator attribute type on figure DMN 1.0b1 DMN 1.0 Duplicate or Merged closed
DMNFTF-2 In the metamodel XMI file I found the following with the help of the NIST Validator DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-1 13-08-03.xsd file: DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-4 Stick with own definition of terms in all cases DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-3 Authority Requirement DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-144 We need a beta 2 spec to consolidate Ballots 1-4 DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-143 use round brackets instead of square for IN DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-15 metamodel for structured ItemDefinitions doesn't work DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-14 Improve FEEL specification of decision tables in Chapter 10 DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-13 boxed (tabular) expressions should be encouraged DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-6 boxed function examples lack mandatory parameter lists DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-5 Figure 67 is ambiguous DMN 1.0b1 DMN 1.0 Duplicate or Merged closed
DMNFTF-17 some examples of null handling in section 10.3.4.4. are wrong DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-16 Extend Priority hit policy to multiple-output tables DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-19 Need floor and ceiling builtins DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-18 Add extended timezone specification, as forshadowed in 10.3.4.1 DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-12 Propose to change OrganizationalUnit to OrganizationUnit DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-11 No way to write a date/time literal in simple FEEL DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-8 locationURI, in Import MUST be in URI format DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-7 Figure 2 is misleading DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-10 Propose to remove "type" from KnowledgeSource DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-9 What is DMN namespace? DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-239 8.3.2 accidentally mandates horizontal orientation DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-238 Editorial corrections followup to Issue 99 DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-233 Minor issues DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-232 Beta 5 with attachments DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-54 Decision Table Clause metamodel needs clarification DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-53 Shorthand notation for vertical tables needs clarification/correction DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-55 Decision Table input and output values not labeled consistently and should not be italicized DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-58 7.1 contains mistaken reference to 8.3 DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-56 The tables in 10.3.4.2 - 10.3.4.4 need heading row as in 10.3.4.1 DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-25 Semantics of equality should be clarified DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-24 No builtin or operator for string concatenation. DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-27 Definition of Authority Requirement DMN 1.0b1 DMN 1.0 Duplicate or Merged closed
DMNFTF-26 MM in figure 26 does not share InformationItems for shared InputData and Decisions DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-34 variable should be optional in InformationRequirement DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-36 inconsistent use of term 'average' and 'mean' DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-35 No way to associate to a Decision the ItemDefinition of its outcome without defining decisionLogic DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-29 FEEL filter should not result in singleton list DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-28 Tools may support only a subset of hit policies DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-31 cannot interchange input data style DMN 1.0b1 DMN 1.0 Deferred closed
DMNFTF-32 Beta 1 specification DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-30 Unary builtins with a list argument (e.g. minimum) should be n-ary. DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-61 RFC-2119 language DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-60 Normative References section incomplete DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-49 FEEL grammar should define precedence of boxed expressions DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-52 unary test is not a legal standalone FEEL expression DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-51 remove "smartquotes" from grammar rule 17 b,c DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-50 Grammar rule 51c should require parentheses around multiple tests DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-40 Does DMN support DRDs, Decision Tables, and Expressions independently or in combination? DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-37 All tables and figures should be numbered DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-41 cannot parse date/time/duration ranges DMN 1.0b1 DMN 1.0 Duplicate or Merged closed
DMNFTF-21 Revise Level 1 Conformance DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-20 lexical structure of FEEL is underspecified DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-23 give execution semantics to InputData DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-22 in the DMN Example in 11.3, Application Risk Score is poorly named and pre/post bureau risk category logic is implausible DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-89 No Knowledge Sources in example DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-88 All Decisions have BKMs though this is not necessary DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-74 Overlapping input entries DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-73 Hit policy summarised in one character DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-72 "Evaluation of the expressions in a decision table does not produce side-effects." DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-78 preferedOrientation behaviour DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-77 Aggregation DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-82 Interval rules DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-81 Exponentiation rule DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-76 Output priorities DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-75 Meaning of "same" DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-84 Only comparing named dates - why? DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-83 Grammar rule 9 reference DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-85 Sum weights of recent credit history example DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-80 "as many time" Typo DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-79 S-FEEL open interval syntax DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-71 "Should not conflict with FEEL Syntax" DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-70 "HC" meaning DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-69 Rule numbering DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-68 Decision table example figures DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-67 Decision table introduction DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-66 Decision table examples DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-62 Section 5.2 & 5.3 order DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-65 "value expression of type invocation" point unclear DMN 1.0b1 DMN 1.0 Duplicate or Merged closed
DMNFTF-64 "HIGH DECLINE" example DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-63 Dottedness of dotted lines DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-99 Reference to DMN elements in XML files may be ambiguous DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-102 Decisions are said to have "inputs" and "outputs", however only the "inputs" are shown in the diagrams DMN 1.0b1 DMN 1.0 Closed; No Change closed
DMNFTF-101 DMN Example should not be limited to automated decisions DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-92 Clarify Authority Requirement notation DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-91 DRD connection rules have no graphical key DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-94 Data Input notation specification and useage DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-93 Boxed Invocation has sparse references after definition DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-95 Can decision tables have zero inputs? DMN 1.0b1 DMN 1.0 Duplicate or Merged closed
DMNFTF-248 Some editorial changes DMN 1.0b1 DMN 1.0 Resolved closed
DMNFTF-247 Change Tracking Document DMN 1.0b1 DMN 1.0 Deferred closed
DMNFTF-245 Incorporate AB feedback into the FTF Report, the marked-up specification, and the clean specification DMN 1.0b1 DMN 1.0 Deferred closed

Issues Descriptions

Lexical representation of time string has ambiguous definitions

  • Key: DMN16-16
  • Status: open  
  • 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
  • Updated: Wed, 20 Mar 2024 17:29 GMT

Knowledge Sources are not fit for ML or AI purposes

  • Key: DMN16-119
  • Status: open  
  • Source: Decision Management Solutions ( Mr. James Taylor)
  • Summary:

    Especially when used in projects that use ML or AI models, the current approach to Knowledge Sources is not fit for purpose. A more structured, template-based approach is needed to specify what information should be captured about a policy document, a regulation, a MVAR/imputation approach, an ML model training regime, data distributions etc. Either a defined set of knowledge source types should be defined with more specific properties or it should be possible to define, exchange and use templates.

  • Reported: DMN 1.5 — Fri, 23 Feb 2024 22:50 GMT
  • Updated: Tue, 12 Mar 2024 17:53 GMT

No binding to Python functions

  • Key: DMN16-101
  • Status: open  
  • Source: Decision Management Solutions ( Mr. James Taylor)
  • Summary:

    There is clear value to ML projects of using DMN to document their projects (requirements, project design, MLOps). ML programmers though use Python not Java for their functions. If DMN can support Java libraries for rules developers, it should support Python for ML developers.

  • Reported: DMN 1.5 — Fri, 3 Nov 2023 22:25 GMT
  • Updated: Tue, 12 Mar 2024 17:44 GMT

Clarification on syntax of DMNReference needed


No way to tell that a Decision iterates over a collection

  • Key: DMN16-55
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • Summary:

    There is no visual way to show that a decision iterates over a collection at the top level.

  • Reported: DMN 1.3 — Wed, 24 Feb 2021 05:31 GMT
  • Updated: Tue, 27 Feb 2024 21:57 GMT

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

  • Key: DMN16-11
  • Status: open  
  • 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
  • Updated: Tue, 27 Feb 2024 21:56 GMT

Returning null is not enough for reporting/handling errors

  • Key: DMN16-117
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    Abusing null as an error indicator is not enough for reporting/handling errors.
    In particular, it does not solve the need for users to:

    • know exactly what the root cause of an error was
    • control the reaction to errors

    The specification already mentions error reporting but is neither a strict requirement nor consequently used:

    When a built-in function encounters input that is outside its defined domain, the function SHOULD report or log diagnostic information if appropriate and SHALL return null.

  • Reported: DMN 1.5b1 — Tue, 30 Jan 2024 17:00 GMT
  • Updated: Wed, 31 Jan 2024 14:03 GMT

Binary operators should not return null

  • Key: DMN16-91
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Here, I am considering the following operators: =, <, >, not(), and, or, in, between

    When considering FEEL for low-codes applications, we should expect these binary operators to always return true or false. Currently, when there is typing error, it returns null.

    ex:
    "a" = 1 => null
    false and "a" => null
    "a" in [0..100] => null
    ...

  • Reported: DMN 1.5 — Tue, 10 Oct 2023 15:57 GMT
  • Updated: Tue, 30 Jan 2024 17:14 GMT

Missing paragraph break and new constraintType

  • Key: DMN16-104
  • Status: open  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    The below text was a separate paragraph in DMN 1.4. In DMN 1.5 is a part of the previous paragraph. Also, the new typeConstraint property is missing.

    An alternative way to define an instance of ItemDefinition is as a composition of ItemDefinition elements. An instance of ItemDefinition may contain zero or more itemComponent, which are themselves ItemDefinitions. Each itemComponent in turn may be defined by either a typeRef and allowedValues or a nested itemComponent. In this way, complex types may be defined within DMN. The name of an itemComponent (nested ItemDefinition) must be unique within its containing ItemDefinition or itemComponent.

  • Reported: DMN 1.5b1 — Thu, 2 Nov 2023 11:42 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

Filter and Iterator in attribute should not require a collection

  • Key: DMN16-94
  • Status: open  
  • Source: Trisotech ( Mr. Simon Ringuette)
  • Summary:

    Currently the in parameter is defined as: This attribute holds the expression that is evaluated as the collection to be processed.

    The intention was to align with the FEEL version of filter and iterators and therefore apply the the 10.3.2.9.4 Type conversions rule: to singleton list: When the type of the expression is T and the target type is List<T> the expression is converted to a singleton list.

    The definition of the in parameter needs to be updated to properly reflect this.

  • Reported: DMN 1.5b1 — Thu, 19 Oct 2023 21:59 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

Inconsistent capitalization of datatypes names

  • Key: DMN16-92
  • Status: open  
  • Source: Trisotech ( Mr. Simon Ringuette)
  • Summary:

    In section 10.3.1.3 Literals, data types, built-in functions, there is an enumeration of FEEL datatypes.

    The first 3 starts with uppercase letters (Number, String, Boolean) while the other starts with lowercase letters.

    Number, String and Boolean should be number, string, boolean like presented in the Figure 10-26: FEEL lattice type on page 112.

  • Reported: DMN 1.5b1 — Tue, 17 Oct 2023 15:16 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

Behaviour when decimal is provided but integer expected

  • Key: DMN16-82
  • Status: open  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    In the DMN spec the only supported number type is decimal.

    However, there are a few places (e.g. scale in round functions and list access) when an integer is needed.

    What is the expected behavior when an integer is expected but a decimal number is provided? For example 'decimal(123, 5.6)' or ''remove([1, 2], 1.5).

    Is this an error or the engine recovers from the error and uses only the integer part of the number?

  • Reported: DMN 1.5b1 — Thu, 20 Jul 2023 15:34 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

Range of scale for number is open to interpretation

  • Key: DMN16-81
  • Status: open  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    According to the DMN spec (10.3.2.3.1 number) a number is equivalent to "Java BigDecimal with MathContext DECIMAL 128.".

    The Java doc states, " A BigDecimal consists of an arbitrary precision integer unscaled value and a 32-bit integer scale.".

    However, the DMN spec de scale is in range range [−6111..6176].

    The question is what is the correct range for scale?

  • Reported: DMN 1.5b1 — Thu, 20 Jul 2023 15:23 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

FEEL descendants operator

  • Key: DMN16-72
  • Status: open  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In some decision models, the input data must conform to an industry-standard xml schema in which elements of interest are many levels deep. Converting such a schema directly to a FEEL item definition requires very long path references. The xpath language has a descendants operator that significantly shortens the path expression. I propose a similar operator (or, less ideally, a function) for FEEL.

    An example is MISMO from the Mortgage Bankers Association. In home appraisals, one item of interest is the Appraiser. To reference the Appraiser from the FEEL item definition generated from the xsd requires this:
    MESSAGE.DOCUMENT_SETS.DOCUMENT_SET.DOCUMENTS.DOCUMENT.DEAL_SETS.DEAL_SET.DEALS.DEAL.SERVICES.SERVICE.VALUATION.VALUATION_RESPONSE.VALUATION_ANALYSES.VALUATION_ANALYSIS.PARTIES.PARTY[ROLES.ROLE.ROLE_DETAIL.PartyRoleType="Appraiser"][1]

    In xpath, omitting namespace prefixes, the descendants operator // simplifies this considerably:
    MESSAGE//PARTY[.//PartyRoleType='Appraiser']

    If // were used as a FEEL descendants operator, you would need only
    MESSAGE//PARTY//PartyRoleType="Appraiser"[1]

    To get the Appraiser's name, instead of
    MESSAGE.DOCUMENT_SETS.DOCUMENT_SET.DOCUMENTS.DOCUMENT.DEAL_SETS.DEAL_SET.DEALS.DEAL.SERVICES.SERVICE.VALUATION.VALUATION_RESPONSE.VALUATION_ANALYSES.VALUATION_ANALYSIS.PARTIES.PARTY[ROLES.ROLE.ROLE_DETAIL.PartyRoleType="Appraiser"].INDIVIDUAL.NAME[1]

    you would need only

    MESSAGE//PARTY//PartyRoleType="Appraiser"//NAME[1]

  • Reported: DMN 1.4b1 — Tue, 14 Mar 2023 19:38 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

Missing semantics for multiple imports

  • Key: DMN16-50
  • Status: open  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    The semantics of Import is not fully specified.

    In certain use cases the same DMN element (e.g. ItemDefinition or DRGElement) can be imported multiple times (e.g. transitive imports).

    Lets consider the following use case:

    • Model A contains the definition of an InputData for a Person (e.g. name, age etc)
    • Model B imports model A. Model B contains a decisions DB that uses the Person as input
    • Model C imports models A and B. Model C contains a decision DC that uses Person and DB as input

    In this situation model C imports Person twice due to transitive import.

    In order to evaluate DC the Person InputData has to be bound to a value. The question is how many values is the user going to provide, lets say in a Web form? A single value or one value for each import path (in this case 2)?

    I am inclining towards the first option - one single value per input data. Here is my rationale:

    • InputDatas / DRGElements are uniquely identified by model namespace and DRGElement.name
    • InputDatas own one single variable (see 6.3. Metamodel). The semnatics for InputData.variable is in Table 18:
      The instance of InformationItem that stores the result of this InputData.
    • Consistency with the import of other DMN Elements: it does not make any sense for ItemDefinitions, BKMs and DSs to have multiple variables / values when imported several times.
    • If we choose the second option and the model is refactored (e.g. models are merged), but the logic does not change, the user has to fill-in different input forms. It is not very user friendly.
    • I am not aware of any PL/DSL that uses the second option

    Lets discuss.

  • Reported: DMN 1.3 — Tue, 30 Mar 2021 08:28 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

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

  • Key: DMN16-24
  • Status: open  
  • 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
  • Updated: Wed, 17 Jan 2024 00:32 GMT


XSD: global context

  • Key: DMN16-5
  • Status: open  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

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

  • Reported: DMN 1.0 — Sun, 31 May 2015 16:35 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

Business Knowledge Model can have Information Requirements

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

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

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

  • Reported: DMN 1.0 — Thu, 23 Jul 2015 23:30 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

No notation for ItemDefinition

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

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

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

  • Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 GMT
  • Updated: Wed, 17 Jan 2024 00:32 GMT

Change to the "at literal" in FEEL

  • Key: DMN16-61
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Currently the at literal = "@", string literal
    Rather than a string following the @ symbol we would use the ISO 8601 format.
    For date : @YYYY-MM-DD e.g. @2019-09-17
    For time : @THH:MM:SS e.g. @T09:55:00
    For date and time : @YYYY-MM-DDTHH:MM:SS e.g. @2019-09-17T09:55:00
    For duration : @P[n]Y[n]M[n]DT[n]H[n]M[n]S where [n] is a number
    e.g. @P18M, @P365D, PT48H

  • Reported: DMN 1.3 — Tue, 26 Jan 2021 22:11 GMT
  • Updated: Tue, 16 Jan 2024 17:49 GMT

Adding a new interval built-in function

  • Key: DMN16-62
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Add a new interval built-in function called: width of( Interval )
    to offer the behavior as follows:
    width of( (1..10] ) = 9
    width of( [1..10] ) = 10
    width of( (1..10) ) = 8
    width of( [ time(“09:55:00”)..time(“10:35:00”) ] ) = PT40M

  • Reported: DMN 1.3 — Tue, 26 Jan 2021 22:03 GMT
  • Updated: Tue, 2 Jan 2024 17:48 GMT

XML serialization is not human friendly

  • Key: DMN16-112
  • Status: open  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    DMN models are serialized in the XML format. XML notation is not user-friendly.

    I suggest adopting an equivalent textual notation that is user-friendly similar to the HUTN notation for UML https://www.omg.org/spec/HUTN/1.0/PDF

  • Reported: DMN 1.5b1 — Tue, 5 Dec 2023 11:28 GMT
  • Updated: Thu, 28 Dec 2023 02:48 GMT

Duplicated names and labels

  • Key: DMN16-106
  • Status: open  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    According to 6.3.1 DMN Element metamodel and 6.3.5 DRG Element metamodel, DRGElements have name and label attributes.

    They also have a variable property that has a name. The DMNDI model also has a label property.

    Possible solution:

    • deprecate the attributes (e.g. DMNElement.label)
    • add a constraint (e.g. DRGElement.name == DRGElement.variable.name)
  • Reported: DMN 1.5b1 — Mon, 27 Nov 2023 10:49 GMT
  • Updated: Tue, 19 Dec 2023 09:58 GMT

Add `number(from: number)` function

  • Key: DMN16-105
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Maciej Barelkowski)
  • Summary:

    Currently, `string(string_variable) = string_variable`, but `number(number_variable) = null`.
    This leads to surprising results like `number(5) = null` but `number("5") = 5`.
    Let's add a function `number(from)` which would accept `number` as the parameter.

  • Reported: DMN 1.5b1 — Tue, 7 Nov 2023 14:46 GMT
  • Updated: Tue, 5 Dec 2023 18:58 GMT

Allow ONNX as well as PMML functions

  • Key: DMN16-90
  • Status: open  
  • Source: Decision Management Solutions ( Mr. James Taylor)
  • Summary:

    ONNX https://onnx.ai/ is an open format for ML models that supports some model types, especially neural networks, better than PMML. DMN should consider allow ONNX functions as it does PMML functions.
    PFA removed as doesn't have the traction that ONNX has
    Open issue on mappings

  • Reported: DMN 1.5 — Fri, 6 Oct 2023 21:56 GMT
  • Updated: Fri, 3 Nov 2023 22:20 GMT

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

  • Key: DMN16-48
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: DMN 1.3 — Wed, 1 Jan 2020 00:21 GMT
  • Updated: Tue, 24 Oct 2023 19:40 GMT

Rounding functions introduced in DMN 1.4 should have single parameter version

  • Key: DMN16-93
  • Status: open  
  • Source: Trisotech ( Mr. Simon Ringuette)
  • Summary:

    Currently the 4 rounding methods: round up, round down, round half up, round half down only have signatures with 2 numeric arguments (n and scale).

    However, pre-existing rounding functions: floor and ceiling have both a single numeric argument version and a 2 numeric argument function (n and scale).

    The single numeric argument is backward compatible with DMN 1.3 (and before). It assumes a scale of 0.

  • Reported: DMN 1.5b1 — Thu, 19 Oct 2023 21:52 GMT
  • Updated: Tue, 24 Oct 2023 16:18 GMT

Include Test Cases in Decision Model

  • Key: DMN16-6
  • Status: open  
  • 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
  • Updated: Thu, 12 Oct 2023 12:39 GMT
  • Attachments:

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

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

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

  • Reported: DMN 1.0 — Thu, 3 Sep 2015 15:58 GMT
  • Updated: Tue, 10 Oct 2023 17:23 GMT

Business Context links go both ways

  • Key: DMN16-1
  • Status: open  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

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

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
  • Updated: Tue, 26 Sep 2023 23:06 GMT

Grammar rule does not match with the one proposal - typo

  • Key: DMN16-85
  • Status: open  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    Grammar rule does not match to the one in proposal https://issues.omg.org/browse/DMN15-107

    35. numeric literal = [ "" ] , ( digits , [ ".", digits ] | "." , digits, [ ( "e" | "E" ) , [ "+" | "" ] , digits ] ) ;

    should be

    35. numeric literal = [ "" ] , ( digits , [ ".", digits ] | "." , digits) , [ ( "e" | "E" ) , [ "+" | "" ] , digits ] ;

  • Reported: DMN 1.5b1 — Tue, 15 Aug 2023 13:43 GMT
  • Updated: Tue, 26 Sep 2023 16:09 GMT

Friendly enough cohersion to string

  • Key: DMN16-71
  • Status: open  
  • Source: camunda.com ( Mr. Nico Rehwaldt [X] (Inactive))
  • Summary:

    Currently concatenating strings is not intuitive to users, as I always have to convert non string values to strings using the built-in `string` function.

    So

    ```
    "Today is " + now() = null
    ```

    In order to yield the actual string you explicitly convert `now()` to its string representation:

    ```
    "Today is " + string(now()) = "Today is 2021-12-12"
    ```

    A more user friendly behavior would be to coherse the second argument to string if the first argument is already a string. This always yields a string representation of the thing. If it is not what I desire I can use custom stringification mechanisms explicitly.

    We'd need to amend the Table 57 (page 128, https://www.omg.org/spec/DMN/1.4/Beta1/PDF) to support such cohersion.

    Additional details on this case can be found in https://github.com/dmn-tck/tck/issues/538 (DMN TCK issue on this topic).

  • Reported: DMN 1.4b1 — Thu, 19 Jan 2023 12:50 GMT
  • Updated: Thu, 14 Sep 2023 14:38 GMT

Missing InformationItem Association?

  • Key: DMN16-66
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    In other sections in the spec, InformationItem is described as storing the data through an ItemDefinition or Expression. Figure 6.16 shows that InformationItem has a /type association with ItemDefinition. Other figures show this also.
    But the table in the section on InformationItem (7.3.4) doesn't list this association and ItemDefinition is not mentioned in the section.

  • Reported: DMN 1.3 — Fri, 10 Jul 2020 21:28 GMT
  • Updated: Tue, 12 Sep 2023 17:17 GMT

No Mapping of FEEL to JSON

  • Key: DMN16-68
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Current DMN Specification v1.4 does not define a mapping of FEEL to JSON, while it already provides mapping for Java, XML, PMML in chapter "10.3.2.12 Mapping between FEEL and other domains"

    This capability can be useful in other use-cases beyond mapping itself. For example, but not limiting to: the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services.

  • Reported: DMN 1.4 — Wed, 13 Apr 2022 13:22 GMT
  • Updated: Tue, 12 Sep 2023 17:11 GMT
  • Attachments:

Relation conforms to and equivalent do not cover functions with variable arguments

  • Key: DMN16-79
  • Status: open  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    Sections 10.3.2.9.1 Type Equivalence and 10.3.2.9.2 Type Conformance define relations between types.

    The definitions do not contain specification for existing builtin functions with variable arguments (e.g. sum).

    The issue was discovered in TCK when testing function invocations.

  • Reported: DMN 1.5b1 — Tue, 4 Jul 2023 07:57 GMT
  • Updated: Tue, 11 Jul 2023 20:11 GMT

It is not possible to assign a default value to a data type

  • Key: DMN16-78
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    When creating a data type I cannot assign a default value (for when the user input is provided as null)

  • Reported: DMN 1.4 — Thu, 15 Jun 2023 19:56 GMT
  • Updated: Tue, 11 Jul 2023 19:53 GMT

No way to show dependencies of a grey-box decision service

  • Key: DMN16-77
  • Status: open  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    When a decision service is fully defined, its dependencies are shown as the information requirements of its encapsulated decisions on external decisions or input data. If the encapsulated decisions of a decision service are not fully defined (e.g. temporarily during analysis, or because it is modelling a 3rd-party service with partial obfuscation), this may not be possible. It would be convenient in such cases to be able to draw information dependencies attaching to the boundary of the decision service. Such a service would not be executable.

    This issue is a continuation of https://issues.omg.org/browse/DMN15-36 which was deferred to 1.6.

  • Reported: DMN 1.5 — Wed, 5 Jul 2023 16:05 GMT
  • Updated: Wed, 5 Jul 2023 16:07 GMT
  • Attachments:

Acknowledgements for DMN 1.4 and 1.5 contributors needed

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

    Section "4.1 Acknowledgements" is missing paragraphs to acknowledge the DMN 1.4 and 1.5 contributors, especially since some people left the task force.

  • Reported: DMN 1.4b1 — Tue, 24 May 2022 17:46 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Add acknowledgements for DMN 1.4 and 1.5 contributors

    Add paragraphs to acknowledge the DMN 1.4 and 1.5 contributors to section "4.1 Acknowledgements" based on
    taskforce membership in 1.4 and 1.5

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

New Namespace URIs needed


Superfluous spaces after "1"

  • Key: DMN15-155
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    Section 10.3 contains a number of instances where a space has appeared after the numeral 1. Sometimes this makes the syntax incorrect.

  • Reported: DMN 1.4 — Tue, 14 Feb 2023 10:11 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Remove superfluous spaces after "1"

    Replace "1 " with "1".

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


Multiple empty imports using the order as a precedence is not allowed

  • Key: DMN15-153
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The specification is not clear in section 6.3.3 if multiple imports into the default namespace are allowed and how the import precedence is managed.

  • Reported: DMN 1.4b1 — Tue, 31 Jan 2023 22:18 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Allow multiple empty imports using the order as a precedence.

    As discussed for the proposal DMN15-140, allow multiple empty imports using the order as a precedence

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

Incorrect function name in example

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

    There are 2 typos in the examples

    duraion("P0DT25H") and duraion("P0Y13M"))

    Should be

    duration("P0DT25H") and duraton("P0Y13M"))

  • Reported: DMN 1.4b1 — Tue, 11 Oct 2022 08:37 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Fix spelling of the word 'duration'

    Fix spelling of the word 'duration' in two places

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

Typo in Table 66

  • Key: DMN15-118
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    With reference to DMN v1.4 dtc-21-12-01 pdf
    Table 66 list all the properties for duration FEEL value type, the property hours (plural) is inadvertently spelled with the capital H, but it should be lower case hours

  • Reported: DMN 1.4b1 — Mon, 10 Oct 2022 14:17 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Change 'Hours' to 'hours'

    Change the cell reading Hours with capital H to lowercase h
    so that all cells in the leftmost column are in lowercase.

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

Typos in meta model


Precision on Allowed Values UnaryTests

  • Key: DMN15-135
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    DMN ItemDefinitions metamodel (section 7.3.3) specifies that and ItemDefinition can restrict its typeRef by using an allowedValues attribute that is defined as a UnaryTests:

    An ItemDefinition element may restrict the values that are allowed from typeRef, using the allowedValues attribute. The allowedValues are an instance of unaryTests that specifies the allowed values or ranges of allowed values within the domain of the typeRef. The type of the allowed values SHALL be consistent with the containing ItemDefinition element. If an ItemDefinition element contains one or more allowedValues, the allowedValues specifies the complete range of values that this ItemDefinition represents. If an ItemDefinition element does not contain allowedValues, its range of allowed values is the full range of the referenced typeRef. In cases where the values that an ItemDefinition element represents are collections of values in the allowed range, the multiplicity can be projected into the attribute isCollection. The default value for this attribute is false.

    This paragraph has a few contradictions with the spec:

    • The last phrase is not clear about which attribute defaults to false, this whole paragraph talks about allowedValues and the intention must be that it refers to isCollection but that certainly confused us.
    • The attribute allowedValues is a UnaryTests but its usage is not consistent with its usage in decision tables inputEntry. A UnaryTests is defined as an expression that evaluates to a boolean with an implicit argument to be tested (from its definition in section 7.3.2). However, this is not the way it is used here. Here it defines a range/enumeration of allowedValues and not an expression that is evaluated with an implicit argument.
      Our proposal would be to align the usage of UnaryTests with decision table inputs.
      This would allow extended use cases such as:
    •  A validation of an email address domain: allowedValues => ends with(?, “@trisotech.com”) 
    •  Validation that depends on sibling variables values: allowedValues => if OrderType = “Type A” then [“a”,”b”,”c”] else [“c”, “d”, “e”] 
    •  Or something even simpler like not null: allowedValues => ? != null 
    •  Length check on strings: allowedValues => string length(?) > 10 
  • Reported: DMN 1.4b1 — Fri, 2 Dec 2022 14:13 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Align the usage of UnaryTests with decision table inputs

    Align the usage of UnaryTests with decision table inputs

    UnaryTests and FEEL have become so powerful that the projection of allowedValues onto collection elements is not required any more.

    XSD and Meta Model change on Figure 7-7: ItemDefintion class diagram, add a composition between ItemDefinition and UnaryTests with the cardinality 0..1 on both sides named typeConstraint. (same as allowedValues): https://github.com/omg-dmn-taskforce/omg-dmn-spec/pull/27/files

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

spec places unrealistic constraints on decision expressions and BKM parameter bindings

  • Key: DMN15-65
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    Section 7.1 specifies that under certain circumstances relating to BKMs a decision must have a literal expression, and BKM parameter bindings relate to decision inputs. For example:

    "If a decision element requires more than one business knowledge element, its value expression must be a literal expression that specifies how the business knowledge model elements are invoked and how their results are combined into the decision's outcome."

    So, in essence dictating that if a decision uses more than 1 BKM its expression must be a literal expression. In practice, a decision may use its BKMs in various ways - to populate a boxed context entry, or even not to invoke it at all and (say) pass the BKM to another BKMN or function accepting as function type parameter.

    This statement should be removed from the spec.

    Next: "If a decision does not require any business knowledge models, its value expression must be a literal expression or decision table that specifies the entire decision logic for deriving the output from the inputs."

    Again, whether a decision uses a BKM or not has no bearing on the type of expression a decision has. A decision with no BKM may have any expression including (say) a boxed context, or a list, or indeed may return a function definition - not just a literal expression or a decision table . The above text should be removed from the spec.

    Next: "Similarly, if a decision element requires only one business knowledge model element, but the logic of the decision elaborates on the logic of its required business knowledge model, the decision element must have a literal expression that specifies how the business knowledge model's value expression is invoked, and how its result is elaborated to provide the decision's outcome."

    The same - this text should be removed from the spec.

    Next: "In all other cases (i.e., when a decision requires exactly one business knowledge model and does not elaborate the logic), the value expression of a decision element may be a value expression of type invocation. In a value expression of type invocation, only the bindings of the business knowledge model parameters to the decisions input data need be specified: the outcome of the decision is the result returned by the business knowledge model's value expression for the values passed to its parameters."

    Again, this is unnecessarily limiting how a decision may use a BKM. For example, a decision may actually return the BKM as its value. The above text should be removed from the spec.

    Additionally, the following should be removed:

    "At the decision logic level, a decision invokes a required business knowledge model by evaluating the business knowledge model's value expression with the parameters bound to its own input value. How this may be achieved depends on how the decision logic is partitioned between the decision and business knowledge models:"

    A decision does not have to bind its input values to a BKM parameters. As a decision may have (say) contexts that evaluate in a top down manner and the binding to a BKMs parameters could be any manner of calculations in that context or results of other BKM invocations that do not strictly relate to the inputs of a decision.

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

    Remove part of section that is erroneous

    Delete part of section 7.1 that is erroneous on page 60 (PDF 66)

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

Clarification regarding equivalence of date vs date and time

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

    Section 10.3.2.3.5 date contains the following:

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

    Is not obvious when the equaivalence should be applied.

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

  • Reported: DMN 1.2 — Sun, 2 Jun 2019 13:01 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Clarify equivalence between date and date and time instances

    Clarify equivalence between date and date and time instances

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

Depiction of Input Data is not harmonized with BPMN and CMMN


It is not possible to use a range of Dates as an iteration context

  • Key: DMN15-121
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    FEEL for iteration statement context limits the iteration context (Section of 10.3.2.14 ) to integers:
    "An iteration context may either be an expression that returns a list of elements, or two expressions that return integers connected by “..”. "

    It would be useful to augment the iteration context to also allow dates.

    This will allow to create simple decision logic that validates conditions for each date in the range and allows one to write decision logic that can validate the state on each day to calculate the number of days that meet a requirement.

    An general example use case could be, how many days in the range [2021-01-01..2022-01-01] meets a certain complex logic.

    A specific example of that would be to determine if the person and its spouse were both employed and living at the same address for at least the 3 of the last 5 years given a list of Job description for both (Date From, Date To, Employer) and a list of their declared residence for both (Date From, Date To, Address).

    This can of course be calculated in a different way, but the logic of iterating on a date range and checking if the condition is true for every day and summing the number of days for which its true makes the logic a lot simpler to follow for a business user.

  • Reported: DMN 1.4b1 — Tue, 18 Oct 2022 18:39 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Add date range to iteration context

    Explicitly allow date ranges and add @”2021-01-01”..@”2022-01-01” to the list of examples in section 10.3.2.14.

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

Missing FEEL function to replace items in a list

  • Key: DMN15-143
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    There are currently FEEL functions to manipulate lists content: append, sublist, concatenate, insert before, remove, union, distinct values and flatten but it does not define a function to replace item(s) from a list.

    Our proposal is to introduce a new list replace function.

  • Reported: DMN 1.4b1 — Tue, 17 Jan 2023 02:33 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Add a new list replace FEEL function

    Introduce a new FEEL function called list replace that allows to replace one or more elements in a list with a new value based on the list position or a matching function.

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

Lists and filters section does not provide a dot accessor "." example with null

  • Key: DMN15-125
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The current para (below) does not provide an example with null which could lead to misinterpretations.

    For convenience, a selection using the "." operator with a list of contexts on its left hand side returns a list of
    selections, i.e. FEEL(e.f, c) = [ FEEL(f, c'), FEEL(f, c"), ... ] where FEEL(e) = [ e', e", ... ] and c' is c augmented with
    the context entries of e', c" is c augmented with the context entries of e", etc. For example,

    [ {x:1, y:2}, {x:2, y:3} ].y = [2,3]
    
  • Reported: DMN 1.4b1 — Fri, 21 Oct 2022 14:43 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Add an example using null to the Lists and filters section

    In section 10.3.2.5 add an example

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

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:

data equivalence with date and time

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

    Section 10.3.2.3.5 contains the following:

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

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

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

  • Reported: DMN 1.2 — Mon, 27 May 2019 08:30 GMT
  • Disposition: Duplicate or Merged — DMN 1.5
  • Disposition Summary:

    Duplicate of DMN15-44

    Duplicate of DMN15-44

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

The "schemaLocation" relative URLs are broken

  • Key: DMN15-76
  • Status: closed  
  • Source: Mayo Clinic ( Dr. Davide Sottara)
  • Summary:

    In DMNDI13.xsd:

    <?xml version="1.0" encoding="UTF-8"?>
    <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:dmndi="https://www.omg.org/spec/DMN/20191111/DMNDI/"
    xmlns:dc="http://www.omg.org/spec/DMN/20180521/DC/"
    xmlns:di="http://www.omg.org/spec/DMN/20180521/DI/"
    targetNamespace="https://www.omg.org/spec/DMN/20191111/DMNDI/"
    elementFormDefault="qualified" attributeFormDefault="unqualified">

    <xsd:import namespace="http://www.omg.org/spec/DMN/20180521/DC/"
    schemaLocation="DC.xsd"/>
    <xsd:import namespace="http://www.omg.org/spec/DMN/20180521/DI/"
    schemaLocation="DI.xsd"/>

    The schemaLocations for the DC/DI schemas that were introduced in DMN1.2 have not been upgraded to take into account the new URL for DMN 1.3
    While the relative location worked for DMN 1.2 (v20180521), the relative URLs resolve to https://www.omg.org/spec/DMN/20191111/DC.xsd (resp DI.xsd)

    This causes issues with tools such as IDEs and schema validators that try to resolve the URLs of the imports.
    The schemaLocations should be updated to use full URLs

  • Reported: DMN 1.3 — Mon, 14 Sep 2020 22:04 GMT
  • Disposition: Closed; No Change — DMN 1.5
  • Disposition Summary:

    Schema locations work when downloaded

    The DMN XML Schema files are primarily designed to work when downloaded into the same folder. We have reached out to Jürgen to also place them in appropriate folders on the OMG web server.

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

Incorrect typeRef for variables associated to BKMs

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

    The typeRef attribute in the variable attribute of Business Knowledge Models in file 'Chapter 11 Example.dmn' from the examples archive is incorrect. The values references the output type (e.g. an item definition) and not a function item (introduced in DMN 1.3).

    According to DMN 1.3 (Table 14, page 57), the semantic of variable attribute is:

    This attribute defines a variable that is bound to the
    function defined by the FunctionDefinition, allowing
    decision logic to invoke the function by name.

    Hence, the typeRef attribute has to reference a FunctionItem, Any or no type at all.

    The issue was reported initially by Daniel Thanner in the TCK group (https://github.com/dmn-tck/tck/issues/376) and lead to the introduction of FunctionItems.

    Proposal:

    There are 3 ways to address this:
    1. Remove typeRef from variables in BKMs
    2. Change value to Any
    3. Create FunctionItems for every BKM in the dmn file and reference them

  • Reported: DMN 1.3 — Mon, 14 Dec 2020 18:07 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Remove typeRef from variable of BKMs

    Remove typeRef from BKM variables but keep it on their encapsulatedLogic in 9 places

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

Wording in section above does not match the rule 35 in grammar

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

    After adding support for scientific notation (https://issues.omg.org/browse/DMN15-107), there are incorrect parts in section 10.3.2.3.1:

    1. Literals consist of base 10 digits and an optional decimal point.
    2. FEEL does not support a literal scientific notation. E.g., 1 .2e3 is not valid FEEL syntax. Use 1.2*10**3 instead.

  • Reported: DMN 1.4b1 — Tue, 11 Oct 2022 08:45 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Correct text about decimal numbers

    Correct the statements about numbers to include scientific notation.

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

DMN 1.4 updated XMI references external file DMN14.mdxml

  • Key: DMN15-98
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    The dtc/21-12-03 "DMN14.xmi updated" contains some references to a file DMN14.mdxml,

    252:        <type href="DMN14.mdxml#_17_0_5_1_a250249_1518651646564_243499_3956"/>
    655:        <type href="DMN14.mdxml#_17_0_2_3_ea50349_1435268843602_88699_2217"/>
    656:        <association href="DMN14.mdxml#_17_0_2_3_ea50349_1435269041753_841899_2676"/>
    666:        <type href="DMN14.mdxml#_17_0_2_3_ea50349_1435268832194_670602_2213"/>
    667:        <association href="DMN14.mdxml#_17_0_2_3_ea50349_1435269293045_464837_2775"/>
    677:        <type href="DMN14.mdxml#_17_0_2_3_ea50349_1435268824892_950814_2209"/>
    678:        <association href="DMN14.mdxml#_17_0_2_3_ea50349_1435269539220_831013_2875"/>
    2298:      <memberEnd href="DMN14.mdxml#_17_0_5_1_a250249_1518651855436_638563_4054"/>
    

    Please check whether those references are intended and if so, please clarify where to obtain that file.

  • Reported: DMN 1.4 — Mon, 4 Apr 2022 21:56 GMT
  • Disposition: Closed; No Change — DMN 1.5
  • Disposition Summary:

    No external references any more

    The latest XMI file does not have such references.

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

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


Misprint in

  • Key: DMN15-142
  • Status: closed  
  • Source: AMBESAS ( Thierry BIARD)
  • Summary:

    In this couple of chapters, "duration" is written "duraion" (without "t" - 2 occurrences)

  • Reported: DMN 1.4b1 — Sun, 18 Dec 2022 11:12 GMT
  • Disposition: Duplicate or Merged — DMN 1.5
  • Disposition Summary:

    Duplicate of DMN15-119

    Fixed in DMN15-128

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

Typo - "duraion"

  • Key: DMN15-149
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    Sections 10.3.2.3.7 and 10.3.2.3.8 have "duraion" instead of "duration"

  • Reported: DMN 1.4 — Wed, 18 Jan 2023 12:32 GMT
  • Disposition: Duplicate or Merged — DMN 1.5
  • Disposition Summary:

    Fixed in another issue

    Fixed already in DMN15-128

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

Clean up example xml files

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

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

  • Reported: DMN 1.2b1 — Tue, 28 May 2019 16:52 GMT
  • Disposition: Closed; No Change — DMN 1.5
  • Disposition Summary:

    The examples don't contain extensions

    The issue seems to be fixed

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

Positive unary tests lack equality operators

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

    Currently the positive unary tests support all relational operators but not the equality operators (= !=). We should support them for consistency. For example, all the above operators are supported in comparison expressions (rule 49).

    Business analysts have reported that they would like to have a consistent and more readable way to write rules and test cases with many comparison operators.

  • Reported: DMN 1.4b1 — Tue, 31 May 2022 08:40 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Extend positive unary tests with equality operators

    Extend positive unary tests with equality operators

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

UNused Requirements are considered invalid

  • Key: DMN15-88
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Executive summary: by the way the DMN specification stands, the description that Requirements SHALL (== "MUST") be referenced in the expression will nullify any CL1 DMN model and any DMN model not using FEEL, as not-conformant.

    In section 7.3.4 InformationItem metamodel we read:

    A variable representing an instance of Decision or InputData referenced by an InformationRequirement SHALL be referenced by the value expression of the decision logic in the Decision element that contains the InformationRequirement element. A parameter in an instance of BusinessKnowledgeModel SHALL be a variable in the value expression of that BusinessKnowledgeModel element.

    By side effect of this strict mandate in the specification, it is like saying an UNused requirement will fail conformance.

    Example: a decision enlist A, B, C as Requirements, but in the formula we use only A and B. According to the current spec, this makes the model failing conformance and invalid.

    Granted, it is always a best practice not only for BA but also for developers to avoid "unused requirements/variable"!
    But here is giving a strict mandate.

    Further, any DMN model which does not use FEEL "only DRG" automatically fail this constraint which is in Chapter 7.

    The DMN specification should follow best-practices of Modeling AND programming languages, where is NOT a blocking issue to have "unused requirements/variables", but of course warn when those are detected; this can be easily achieved by switching SHALL to SHOULD in the identified paragraphs in chapter 7.1 and 7.3.4 per proposal.

    This issue was detected in the TCK group (ref https://github.com/dmn-tck/tck/issues/487 )

  • Reported: DMN 1.4 — Sun, 27 Feb 2022 20:45 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Requirements SHOULD be referenced

    change text in Chapter 7.1 and 7.3.4 according to the below instructions

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

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

  • Key: DMN15-78
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

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

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

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

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

    Example

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

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

    However, Table 55, row 9, cites:

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

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

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

    Clarify edge cases and range options

    Clarify that ranges are defined based on a combination of comparison and conjunction operators and therefore the result of an comparison with a range containing a null endpoint will be either false or null but never true.

    Add text to the description of the range that mentions the possibility of using expressions.

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

No built-in function to support Range conversion

  • Key: DMN15-99
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Current DMN Specification v1.4 does not define a Built-in function to support Range conversion.

    This capability can be useful in other use-cases beyond conversion itself. For example, but not limiting to: the need to have FEEL:range as an input of the model, the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services, etc.

  • Reported: DMN 1.4 — Wed, 13 Apr 2022 13:07 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Add Built-in function to support Range conversion

    Adds a new FEEL built-in function in Chapter 10.3.4.1 Conversion functions, to support Range conversion

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

Table 62 limited to "negative numbers"

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

    In 10.3.2.15 Semantic mappings,
    Table 62: Semantics of negative numbers

    per its description is limiting to negative numbers, but by Table 59 it's possible to multiply a duration (years and months duration, days and time duration) by a number.

    Hence, it's already possible to do

    duration("PT1H")*-1
    

    but formally is not allowed to do

    -duration("PT1H")
    

    It should be easier to widen the semantic of Table 62 to negate numbers AND duration to allow the second case.

    This was identified in the TCK group, ref https://github.com/dmn-tck/tck/issues/482

  • Reported: DMN 1.4 — Sun, 27 Feb 2022 20:23 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Widen semantic of Table 62 to cover FEEL semantic

    Change of text for semantic of Table 62

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

Typo in "10.3.1.2 Grammar rules" 3rd bulletpoint in the bottom

  • Key: DMN15-94
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    With reference to DMNv1.4 dtc-21-12-01,
    section "10.3.1.2 Grammar rules",
    page 104 (PDF 120)
    the 3rd bulletpoint in the bottom is referring to the wrong grammar rule number.

    This is likely a typo originating from the need of additional grammar rules being added in previous version of the Spec.

    This can be trivially fixed editorially, with the associated proposal.

  • Reported: DMN 1.4 — Thu, 17 Mar 2022 17:22 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Fix 3rd bulletpoint rule reference in "10.3.1.2 Grammar rules"

    Update the grammar rule reference and provide more context.

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

No support for numbers in scientific notation

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

    Currently the syntax of numeric literals does not support usage of exponents. This is quite useful when dealing with large numbers.

  • Reported: DMN 1.4b1 — Tue, 31 May 2022 07:59 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Support numbers in scientific notation

    Extend grammar to support numbers in scientific notation

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

Allowed Values for collection item definitions

  • Key: DMN15-137
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    DMN ItemDefinitions metamodel (section 7.3.3) specifies that the allowedValues of a collection attribute are projected to its elements which prevents us from constraining collections.

    For example:

    • The collection size needs to be between 1-5 elements
    • The collection can’t contain duplicates

    Our proposal is to add an additional attribute to ItemDefinition named collectionAllowedValues to capture these constraints.

  • Reported: DMN 1.4b1 — Fri, 2 Dec 2022 14:23 GMT
  • Disposition: Duplicate or Merged — DMN 1.5
  • Disposition Summary:

    Proposal merged into DMN15-136

    Proposal merged into DMN15-136

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

Another False, or at least ignored statement by most vendors

  • Key: DMN15-131
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    This statement was brought to my attention via DMN TCK email:

    "If a decision element requires more than one business knowledge element, its value expression must be a literal expression that specifies how the business knowledge model elements are invoked and how their results are combined into the decision's outcome. "

    This statement is either false or ignored by most vendors

  • Reported: DMN 1.4b1 — Wed, 30 Nov 2022 17:58 GMT
  • Disposition: Duplicate or Merged — DMN 1.5
  • Disposition Summary:

    Duplicate of previous issue

    Duplicate of previous issue

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

False, or at least ignored statement by most if not all vendors

  • Key: DMN15-130
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    This statement was brought to my attention via DMN TCK email:

    "If a decision does not require any business knowledge models, its value expression must be a literal expression or decision table that specifies the entire decision logic for deriving the output from the inputs."

    This statement is either false or ignored by most vendors

  • Reported: DMN 1.4b1 — Wed, 30 Nov 2022 17:55 GMT
  • Disposition: Duplicate or Merged — DMN 1.5
  • Disposition Summary:

    Duplicate of previous issue

    Duplicate of previous issue

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

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

Business Knowledge Model can have Information Requirements

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

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

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

  • Reported: DMN 1.0 — Thu, 23 Jul 2015 23:30 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

No notation for ItemDefinition

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

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

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

  • Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

XSD: global context

  • Key: DMN15-5
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

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

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

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

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

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

  • Reported: DMN 1.0 — Thu, 3 Sep 2015 15:58 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Gaps: Range as input, mapping to JSON, evaluation of non-FEEL expression languages

  • Key: DMN15-96
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Current DMN Specification v1.4 has a few gaps in the following areas:

    1. Built-in function to support Range conversion
    2. Mapping of FEEL to JSON
    3. Evaluation of other expression language beyond FEEL

    In addition to the above gaps, during conversations in the OMG DMN RTF group, and in other communities with DMN interests, SMEs and Vendors have reported on the missing capabilities for a complete, semantically well-defined and interoperable solution, connected to the mentioned cases. For example, but not limiting to: the need to have FEEL:range as an input of the model, the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services, etc.

    The pragmatic aspects introduced in this proposal to cover the mentioned gaps above, could also be a meaningful foundational and propaedeutic work if the OMG DMN RTF group will want to pursue to eventually propose the DMN Specification to ISO, and/or the group will want to pursue to eventually refactor FEEL into its own stand-alone Specification.

    Finally, the DMN Specification already provides recommendations in the Annex(es) for integrations, in the scope of BPMN, etc., for harmonised semantic and potential improved interoperability; the DMN Spec could also offer similar recommendations in the scope of gap 3 identified above.

    This document advances pragmatic proposals that would both cover the existing gaps and provide the capabilities required to a well-defined and more interoperable solution.

  • Reported: DMN 1.4 — Fri, 25 Mar 2022 08:29 GMT
  • Disposition: Duplicate or Merged — DMN 1.5
  • Disposition Summary:

    Issue has been split up

    The relevant gaps are covered in the respective JIRAs DMN15-99 and DMN15-101

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

Typo in 6.3.7 Decision metamodel

  • Key: DMN15-83
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    In the chapter "6.3.7 Decision metamodel",
    a reference is made to the fact a Decision's Name MUST be unique in the model, but there is likely a wrong copy-paste of a sentence from other section of the spec.

    It currently reads as:

    The name of an Invocable must be different from the name of any other invocable, input data, decision, or import in the decision model.

    But a Decision is NOT an Invocable.

    In the chapter "6.3.9 Business Knowledge Model metamodel" the same pharse is used and there is valid since a BKM is indeed an Invocable.

    In the chapter "6.3.11 Input Data metamodel" the analogous phrase is correctly adapted, since it reads as:

    The name of an InputData must be different from the name of any other decision, input data, business knowledge model, decision service, or import in the decision model.

    Conclusion

    Only in chapter chapter "6.3.7 Decision metamodel" the phrase is wrong as referring to "Invocable" when in fact it should have just used the term "Decision". The proposal will address this accordingly.

  • Reported: DMN 1.4 — Wed, 19 Jan 2022 12:58 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Address typo in 6.3.7 Decision metamodel instead of Invocable use proper term: Decision

    In chapter "6.3.7 Decision metamodel", replace "Invocable" with "Decision" in the phrase:

    The name of an Invocable must be different from the name of any other invocable, input data, decision, or import in the decision model.

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

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

There are questions regarding precedence of operator between negation and exponation

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

    in FEEL -4**2 = 16
    Some may expect = -16

  • Reported: DMN 1.4 — Tue, 5 Jul 2022 17:03 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Add clarification about precedence

    Add a warning about the different precedence and suggestions to avoid ambiguities

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

Typo in 8.3.1 Decision Table metamodel "DecsionTable"

  • Key: DMN15-81
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    In the paragraph of 8.3.1 Decision Table metamodel

    DecisionTable inherits all the attributes and model associations from Expression. Table 32 presents the additional attributes and model associations of the DecsionTable element.

  • Reported: DMN 1.4 — Wed, 5 Jan 2022 08:48 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Fix typo "DecsionTable"

    Fix typo

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

Business Context links go both ways

  • Key: DMN15-1
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

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

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Incorrect reference to FEEL rule

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

    In the following bullet point:

    In rule 62, the only permitted functions are the builtins date, time, date and time, and duration.

    the correct reference is rule 60 where the date time literals are defined.

  • Reported: DMN 1.4b1 — Tue, 31 May 2022 07:56 GMT
  • Disposition: Duplicate or Merged — DMN 1.5
  • Disposition Summary:

    Duplicate of DMN15-94

    Fixed in DMN15-95

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

Typo in the DMN 1.4 XSD schema (complexType tFilter)

  • Key: DMN15-79
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Typo of spurious trailing whitespace in the name of the complexType "tFilter " (notice the extra space at the end) make XSD validators to fail to validate the XML Schema itself.

  • Reported: DMN 1.4 — Mon, 3 Jan 2022 16:30 GMT
  • Disposition: Closed; No Change — DMN 1.5
  • Disposition Summary:

    Close without change

    Issue fixed already in DMN 1.4

  • 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

Should encapsulated decisions of a decision service include output decisions?

  • Key: DMN15-10
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

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

    {Decision 1, Decision 2}

    "

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

    {Decision 1}

    ".

    Table 20 on page 56:

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

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

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

inconsistent date comparisons make unavoidavle paradoxes

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

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

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

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

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

  • Reported: DMN 1.2 — Wed, 18 Sep 2019 10:01 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

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

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

    Since DMNv1.2 the spec dropped the equivalence of:

    [a] = a
    

    because it does not apply to the statement that

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

    So the expression

    [a] = a
    

    on DMNv1.2 is expected to return false.

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

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

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

    BUT

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

    according to DMNv1.2 should be false

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

    [123] = 123
    

    on DMNv1.2 is expected to be false

  • Reported: DMN 1.2b1 — Wed, 30 Jan 2019 14:43 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Add an itemKind property to ItemDefinition

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

    SDMN, BPMN, and CMMN have a property that specifies the kind of element that is being modeled. The set of enumerations for this property include: data, conceptual, physical, etc.
    SDMN is directly referencing DMN’s ItemDefinition, but is extending the element to include this “itemKind” property.
    If this property makes sense in the DMN context and is added in DMN 1.4, then SDMN would not have to extend ItemDefinition for this property.
    SDMN extends ItemDefinition in other ways, which will be addressed by separate issues.

  • Reported: DMN 1.3b1 — Tue, 6 Apr 2021 22: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

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

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

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

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

DMN Models need a default timezone

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

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

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

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

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

  • Reported: DMN 1.2 — Wed, 18 Sep 2019 09:55 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Situational Data Model and Notation (SDMN)

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

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

  • Reported: DMN 1.2b1 — Tue, 10 Sep 2019 18:04 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

Fix interchange of links to objects in BPMN/BMM

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

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

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

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

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

    split off from DMN13-12

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

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Support for recursive calls by Business Knowledge Models

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

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

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

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

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

    The following paragraph is added:

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

  • Reported: DMN 1.2 — Sat, 6 Apr 2019 02:38 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

properly define type(e)

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

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

  • Reported: DMN 1.2 — Tue, 27 Nov 2018 22:31 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Knowledge Package Model and Notation (KPMN)

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

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

  • Reported: DMN 1.2b1 — Tue, 10 Sep 2019 17:59 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Clarification on DMN case sensitivity of timezones

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

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

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

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

  • Reported: DMN 1.2 — Sat, 16 Mar 2019 01:12 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

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

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

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

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:15 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

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

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

  • Reported: DMN 1.3 — Wed, 1 Jan 2020 00:23 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Temporal precision inconsistencies

  • Key: DMN15-43
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: DMN 1.2b1 — Tue, 16 Jul 2019 14:02 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

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

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

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

  • Reported: DMN 1.2b1 — Tue, 28 May 2019 16:40 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Friendlier handling of null values

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

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

  • Reported: DMN 1.2b1 — Tue, 21 May 2019 16:53 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Missing semantics for multiple imports

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

    The semantics of Import is not fully specified.

    In certain use cases the same DMN element (e.g. ItemDefinition or DRGElement) can be imported multiple times (e.g. transitive imports).

    Lets consider the following use case:

    • Model A contains the definition of an InputData for a Person (e.g. name, age etc)
    • Model B imports model A. Model B contains a decisions DB that uses the Person as input
    • Model C imports models A and B. Model C contains a decision DC that uses Person and DB as input

    In this situation model C imports Person twice due to transitive import.

    In order to evaluate DC the Person InputData has to be bound to a value. The question is how many values is the user going to provide, lets say in a Web form? A single value or one value for each import path (in this case 2)?

    I am inclining towards the first option - one single value per input data. Here is my rationale:

    • InputDatas / DRGElements are uniquely identified by model namespace and DRGElement.name
    • InputDatas own one single variable (see 6.3. Metamodel). The semnatics for InputData.variable is in Table 18:
      The instance of InformationItem that stores the result of this InputData.
    • Consistency with the import of other DMN Elements: it does not make any sense for ItemDefinitions, BKMs and DSs to have multiple variables / values when imported several times.
    • If we choose the second option and the model is refactored (e.g. models are merged), but the logic does not change, the user has to fill-in different input forms. It is not very user friendly.
    • I am not aware of any PL/DSL that uses the second option

    Lets discuss.

  • Reported: DMN 1.3 — Tue, 30 Mar 2021 08:28 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

DRG requirements only state am unused knowledge requirement is illegal

  • Key: DMN15-61
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    Subsection "6.2.2.2 Knowledge Requirement notation" of "6.2.2 DRD Requirements" states that knowledge requirements must be utilised in the decision/BKM knowledge requirement:

    "If e is a decision or a BKM in some DRD, and e contains a knowledge requirement on some invocable element b, then the logic of e must contain an invocation expression of b, including expressions for each of b's parameters."

    However, this section does not mandate that Information Requirements must also be utilised by the requiring DRG element in the same way that a knowledge requirement must. If a purpose of DMN is to serve as documentation and show actual relationships between decision elements then it is paramount the DRG reflects actual usage in the model, otherwise the graph is incorrect - it may show relationships that do not reflect the decision-making reality.

    I propose adding the following to section "6.2.2.1 Information Requirement notation":

    "If e is a DRG element in some DRD, and e contains an information requirement on some other DRG element b, then the logic of e MUST contain a usage of the information provided by b"

  • Reported: DMN 1.3 — Thu, 25 Mar 2021 08:10 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

Spec does not mandate that all user-defined function parameters are utilised

  • Key: DMN15-59
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    Section "10.3.2.13.2 User-defined functions" provides definition and invocation semantics for user defined functions but permits unused parameters.

    As DMN is to be 'executable documentation' I suggest that unused parameters provide documentation that does not reflect reality.

    I propose the follow additional paragraph to "10.3.2.13.2 User-defined functions" :

    "The body expression of a user-defined function SHALL utilise every formal parameter. "

  • Reported: DMN 1.3 — Thu, 25 Mar 2021 08: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

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

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

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

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

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Spec does not mandate that all formal parameters are utilised.

  • Key: DMN15-60
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    Section "10.5.3 FunctionDefinition metamodel" does not specify that formal parameters must be utilised in the function logic . As DMN is a self-documenting decision executable this leads to a situation where (documented) parameters may be defined but unnecessary.

    I propose the following paragraph is added to section "10.5.3 FunctionDefinition metamodel":

    "The body expression of a FunctionDefinition SHALL utilise every formal parameter. "

  • Reported: DMN 1.3 — Thu, 25 Mar 2021 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

No way to tell that a Decision iterates over a collection

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

    There is no visual way to show that a decision iterates over a collection at the top level.

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

    Defer to DMN 1.6

    Defer to DMN 1.6

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

P0D == P0Y in SFEEL, but it is unclear if P0D == P0Y in FEEL

  • Key: DMN15-64
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    Section 9.4 says "Comparison operators are defined only when the two operands have the same type, except for years and months duration
    and days and time duration, which can be compared for equality. Notice, however, that “with the exception of the zerolength
    duration, no instance of xs:dayTimeDuration can ever be equal to an instance of xs:yearMonthDuration.”

    Thus stating that `P0D == P0Y` despite the fact they are different types and do not comply with the type-lattice equivalency. This is as per the XPATH operation `op:duration-equal` that the spec says equality here conforms to.

    It is not crystal clear if this applies to FEEL as well as SFEEL though the same sections does say:

    > The semantics of S-FEEL expressions are defined in this section, in terms of the semantics of the XML Schema datatypes
    and the XQuery 1.0 and XPath 2.0 Data Model datatypes, and in terms of the corresponding functions and operators
    defined by XQuery 1.0 and XPath 2.0 Functions and Operators (prefixed by “op:” below). A complete stand-alone
    specification of the semantics is to be found in clause 10.3.2, as part of the definition of FEEL. Within the scope of SFEEL,
    the two definitions are equivalent and equally normative.

    So, "Within the scope of SFEEL, the two definitions are equivalent and equally normative." seems to indicate that it does hold true for FEEL.

    My recommendation is that `P0D == P0Y` does apply to FEEL because it would make sense to a business person. `1 Apple != 1 Orange`, but zero apples is really the same as zero oranges, or zero anything for that matter. And, in practice, zero days really is the same as zero years.

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 09:31 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

the operation of is() function is not well specified

  • Key: DMN15-66
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The new is() function is in a spec section called "Date and time functions" but it is unclear if it related only to date and time types. The examples only show date and time. Though it would seem reasonable that is also handled datetime type as well.

    Additionally, it references section 10.3.2.2 for descriptions of semantics and that section deals with ore than just date and time. It also deals with other 'primitive' types - so it is unclear if is() relates to these also. Additionally, that section does not deal with other types like range/context/function/list so it is not clear if is() deals with all types in that section, and indeed other types as well.

    By example, is it not evident if is({},{}) is true, false, or illegal. Similarly for is([1], [1]) or is(1,1), or is([null..2], < 2).

    Additionally, it is also unclear (to me) from the semantic description whether is(@"2021-02-19T10:10:10Z", @"2021-02-19T10:10:10@Etc/GMT") as they are both UTC forms. The spec says they are 'comparable', but does that relate to is()?

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 10: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

Allow for partial temporal values

  • Key: DMN15-69
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    It should be possible to define partial temporal values but only for trailing precisions (i.e., if you specify a day, you must also specify a year and month)
    Values of type Date, the precision unit must be one of: years, months, or Days
    e.g. date( 2019 ), date( 2019, 09 ), date( 2019, 09, 17)
    Values of type Time, the precision unit must be one of: hours, minutes, or seconds
    e.g. time( 09 ), time( 09, 55), time( 09, 55, 00)
    Values of type Date and Time, the precision unit must be one of: years, months, days, hours, minutes, or seconds
    e.g. date and time( date(2019,09,17), time(09,55) ), date and time( “2019-09-17T09:55”)

    Operations carried out on elements with different time based precision units shall be done based on the lowest common precision unit (truncating any resulting decimal portion) 

  • Reported: DMN 1.3 — Tue, 26 Jan 2021 22:17 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

FunctionItem `parameters` array attribute is plural, not singular in name

  • Key: DMN15-68
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The `parameters` attribute of the new FunctionItem introduced in DMN 1.3 is plural in name and not singular like all other array attributes described in the meta-models. This is an exception.

    This leads to an XML form where each `<parameters>` element contains one parameter.

    Recommendation. Change FunctionItem array attribute `parameters` to `parameter`. Another possibility is to deprecate `parameters` in favour of `parameter` and drop support in a future version.

  • Reported: DMN 1.3 — Tue, 2 Feb 2021 22:55 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Allow input data to be of type Interval

  • Key: DMN15-72
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In many situations, it is desirable to have a data input that is an interval. Particularly when it comes to temporal logic many situations requires one to enter the "Valid Period", the "Measurement Period", the "Disccount Period" etc
    To currently achieve this requires to create two data inputs (one for the start data/time and one for the end data/time) and then assembling them into an interval named "Period using a literal expression [start..end].

  • Reported: DMN 1.3 — Mon, 25 Jan 2021 20:17 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

Ambiguous named params for before() and after() range functions

  • Key: DMN15-67
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The `before` and `after` range functions have ambiguous invocation when using named params. Both functions have 4 variants - take `before` as an example:

    ```
    (a) before(point1, point2)
    (b) before(point, range)
    (c) before(range, point)
    (d) before(range1, range2)
    ```

    If I invoke `before(range: [1..10], point: 1)` is it for variant (b) ... or (c) ... ?

    Suggest renaming the param names or making the variants separate functions.

  • Reported: DMN 1.3 — Tue, 2 Feb 2021 23:38 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Change to the "at literal" in FEEL

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

    Currently the at literal = "@", string literal
    Rather than a string following the @ symbol we would use the ISO 8601 format.
    For date : @YYYY-MM-DD e.g. @2019-09-17
    For time : @THH:MM:SS e.g. @T09:55:00
    For date and time : @YYYY-MM-DDTHH:MM:SS e.g. @2019-09-17T09:55:00
    For duration : @P[n]Y[n]M[n]DT[n]H[n]M[n]S where [n] is a number
    e.g. @P18M, @P365D, PT48H

  • Reported: DMN 1.3 — Tue, 26 Jan 2021 22: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

Adding a new interval built-in function

  • Key: DMN15-71
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Add a new interval built-in function called: width of( Interval )
    to offer the behavior as follows:
    width of( (1..10] ) = 9
    width of( [1..10] ) = 10
    width of( (1..10) ) = 8
    width of( [ time(“09:55:00”)..time(“10:35:00”) ] ) = PT40M

  • Reported: DMN 1.3 — Tue, 26 Jan 2021 22:03 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

Links with other standards

  • Key: DMN15-75
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    A "bucket" for collecting related issues around external links

  • Reported: DMN 1.3 — Tue, 3 Nov 2020 18:17 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 Mapping of FEEL to JSON

  • Key: DMN15-101
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Current DMN Specification v1.4 does not define a mapping of FEEL to JSON, while it already provides mapping for Java, XML, PMML in chapter "10.3.2.12 Mapping between FEEL and other domains"

    This capability can be useful in other use-cases beyond mapping itself. For example, but not limiting to: the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services.

  • Reported: DMN 1.4 — Wed, 13 Apr 2022 13:22 GMT
  • Disposition: Deferred — DMN 1.5
  • Disposition Summary:

    Defer to DMN 1.6

    Defer to DMN 1.6

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

Clarification on syntax of DMNReference


Missing InformationItem Association?

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

    In other sections in the spec, InformationItem is described as storing the data through an ItemDefinition or Expression. Figure 6.16 shows that InformationItem has a /type association with ItemDefinition. Other figures show this also.
    But the table in the section on InformationItem (7.3.4) doesn't list this association and ItemDefinition is not mentioned in the section.

  • Reported: DMN 1.3 — Fri, 10 Jul 2020 21:28 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

Functions cannot invoke external services

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

    The current definition of externally-defined functions only allows Java and PMML external functions. There are clear use cases for allow an external (stateless and side-effect free) service to be used in this way.

  • Reported: DMN 1.4 — Wed, 16 Mar 2022 19:34 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

Import into default namespace is undefined

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

    The current mechanism for importing in DMN requires a name attribute to be a prefix to imported elements names.
    Importing an item definition named Person becomes import. Person when referencing it from the local model.
    This is confusing to some business users.

    We would like to allow the import into the default namespace by specifying an empty name.
    This, of course, has the potential of creating name collisions for the imported elements.
    We suggest that when a name collision occurs for one of the imported elements, the local element is kept and the imported one is discarded.

  • Reported: DMN 1.4b1 — Fri, 2 Dec 2022 14:35 GMT
  • Disposition: Resolved — DMN 1.5
  • Disposition Summary:

    Allow the import into the default namespace by specifying an empty name.

    allow the import into the default namespace by specifying an empty name.

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

Friendly enough cohersion to string

  • Key: DMN15-151
  • Status: closed  
  • Source: camunda.com ( Mr. Nico Rehwaldt [X] (Inactive))
  • Summary:

    Currently concatenating strings is not intuitive to users, as I always have to convert non string values to strings using the built-in `string` function.

    So

    ```
    "Today is " + now() = null
    ```

    In order to yield the actual string you explicitly convert `now()` to its string representation:

    ```
    "Today is " + string(now()) = "Today is 2021-12-12"
    ```

    A more user friendly behavior would be to coherse the second argument to string if the first argument is already a string. This always yields a string representation of the thing. If it is not what I desire I can use custom stringification mechanisms explicitly.

    We'd need to amend the Table 57 (page 128, https://www.omg.org/spec/DMN/1.4/Beta1/PDF) to support such cohersion.

    Additional details on this case can be found in https://github.com/dmn-tck/tck/issues/538 (DMN TCK issue on this topic).

  • Reported: DMN 1.4b1 — Thu, 19 Jan 2023 12:50 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

Importing libraries of functions is not business friendly

  • Key: DMN15-123
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    There are many different Functions that are needed to make FEEL expressive enough for tackle the logic of various contexts/industries:
    e.g Financial Functions, Healthcare Functions, etc. even advanced Mathematical functions or Matrix manipulation functions.

    Currently these functions need to be imported in, and then all functions need to be prefixed with a namespace.
    This not ideal as the business friendly name with space such as "annual interest rate" now becomes cryptic as "financial.annual interest rate"
    or "discount as percentage" becomes "financial.discount as percentage"

  • Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:27 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

Interchanging models that use external libraries of functions is complicated

  • Key: DMN15-124
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Currently if a DMN model makes use of an external library of functions, the receiving tool may be challenged in also importing this library and execute on these new functions.

    We should explore a way to make the interchanged model not only exchangeable but also executable.

  • Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19: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

Functions cannot invoke external services

  • Key: DMN16-67
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • Summary:

    The current definition of externally-defined functions only allows Java and PMML external functions. There are clear use cases for allow an external (stateless and side-effect free) service to be used in this way.

  • Reported: DMN 1.4 — Wed, 16 Mar 2022 19:34 GMT
  • Updated: Fri, 14 Apr 2023 16:54 GMT

Importing libraries of functions is not business friendly

  • Key: DMN16-69
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    There are many different Functions that are needed to make FEEL expressive enough for tackle the logic of various contexts/industries:
    e.g Financial Functions, Healthcare Functions, etc. even advanced Mathematical functions or Matrix manipulation functions.

    Currently these functions need to be imported in, and then all functions need to be prefixed with a namespace.
    This not ideal as the business friendly name with space such as "annual interest rate" now becomes cryptic as "financial.annual interest rate"
    or "discount as percentage" becomes "financial.discount as percentage"

  • Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:27 GMT
  • Updated: Wed, 12 Apr 2023 13:06 GMT

Incorrect names for parameters

  • Key: DMN16-73
  • Status: open  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    The names of the number() function in note 1 at the end of Table 72

  • Reported: DMN 1.4b1 — Tue, 31 Jan 2023 18:50 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Interchanging models that use external libraries of functions is complicated

  • Key: DMN16-70
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Currently if a DMN model makes use of an external library of functions, the receiving tool may be challenged in also importing this library and execute on these new functions.

    We should explore a way to make the interchanged model not only exchangeable but also executable.

  • Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:35 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Links with other standards

  • Key: DMN16-65
  • Status: open  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    A "bucket" for collecting related issues around external links

  • Reported: DMN 1.3 — Tue, 3 Nov 2020 18:17 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

FunctionItem `parameters` array attribute is plural, not singular in name

  • Key: DMN16-59
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The `parameters` attribute of the new FunctionItem introduced in DMN 1.3 is plural in name and not singular like all other array attributes described in the meta-models. This is an exception.

    This leads to an XML form where each `<parameters>` element contains one parameter.

    Recommendation. Change FunctionItem array attribute `parameters` to `parameter`. Another possibility is to deprecate `parameters` in favour of `parameter` and drop support in a future version.

  • Reported: DMN 1.3 — Tue, 2 Feb 2021 22:55 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Allow for partial temporal values

  • Key: DMN16-60
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    It should be possible to define partial temporal values but only for trailing precisions (i.e., if you specify a day, you must also specify a year and month)
    Values of type Date, the precision unit must be one of: years, months, or Days
    e.g. date( 2019 ), date( 2019, 09 ), date( 2019, 09, 17)
    Values of type Time, the precision unit must be one of: hours, minutes, or seconds
    e.g. time( 09 ), time( 09, 55), time( 09, 55, 00)
    Values of type Date and Time, the precision unit must be one of: years, months, days, hours, minutes, or seconds
    e.g. date and time( date(2019,09,17), time(09,55) ), date and time( “2019-09-17T09:55”)

    Operations carried out on elements with different time based precision units shall be done based on the lowest common precision unit (truncating any resulting decimal portion) 

  • Reported: DMN 1.3 — Tue, 26 Jan 2021 22:17 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Allow input data to be of type Interval

  • Key: DMN16-63
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In many situations, it is desirable to have a data input that is an interval. Particularly when it comes to temporal logic many situations requires one to enter the "Valid Period", the "Measurement Period", the "Disccount Period" etc
    To currently achieve this requires to create two data inputs (one for the start data/time and one for the end data/time) and then assembling them into an interval named "Period using a literal expression [start..end].

  • Reported: DMN 1.3 — Mon, 25 Jan 2021 20:17 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

P0D == P0Y in SFEEL, but it is unclear if P0D == P0Y in FEEL

  • Key: DMN16-56
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    Section 9.4 says "Comparison operators are defined only when the two operands have the same type, except for years and months duration
    and days and time duration, which can be compared for equality. Notice, however, that “with the exception of the zerolength
    duration, no instance of xs:dayTimeDuration can ever be equal to an instance of xs:yearMonthDuration.”

    Thus stating that `P0D == P0Y` despite the fact they are different types and do not comply with the type-lattice equivalency. This is as per the XPATH operation `op:duration-equal` that the spec says equality here conforms to.

    It is not crystal clear if this applies to FEEL as well as SFEEL though the same sections does say:

    > The semantics of S-FEEL expressions are defined in this section, in terms of the semantics of the XML Schema datatypes
    and the XQuery 1.0 and XPath 2.0 Data Model datatypes, and in terms of the corresponding functions and operators
    defined by XQuery 1.0 and XPath 2.0 Functions and Operators (prefixed by “op:” below). A complete stand-alone
    specification of the semantics is to be found in clause 10.3.2, as part of the definition of FEEL. Within the scope of SFEEL,
    the two definitions are equivalent and equally normative.

    So, "Within the scope of SFEEL, the two definitions are equivalent and equally normative." seems to indicate that it does hold true for FEEL.

    My recommendation is that `P0D == P0Y` does apply to FEEL because it would make sense to a business person. `1 Apple != 1 Orange`, but zero apples is really the same as zero oranges, or zero anything for that matter. And, in practice, zero days really is the same as zero years.

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 09:31 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

the operation of is() function is not well specified

  • Key: DMN16-57
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The new is() function is in a spec section called "Date and time functions" but it is unclear if it related only to date and time types. The examples only show date and time. Though it would seem reasonable that is also handled datetime type as well.

    Additionally, it references section 10.3.2.2 for descriptions of semantics and that section deals with ore than just date and time. It also deals with other 'primitive' types - so it is unclear if is() relates to these also. Additionally, that section does not deal with other types like range/context/function/list so it is not clear if is() deals with all types in that section, and indeed other types as well.

    By example, is it not evident if is({},{}) is true, false, or illegal. Similarly for is([1], [1]) or is(1,1), or is([null..2], < 2).

    Additionally, it is also unclear (to me) from the semantic description whether is(@"2021-02-19T10:10:10Z", @"2021-02-19T10:10:10@Etc/GMT") as they are both UTC forms. The spec says they are 'comparable', but does that relate to is()?

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 10:20 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Ambiguous named params for before() and after() range functions

  • Key: DMN16-58
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The `before` and `after` range functions have ambiguous invocation when using named params. Both functions have 4 variants - take `before` as an example:

    ```
    (a) before(point1, point2)
    (b) before(point, range)
    (c) before(range, point)
    (d) before(range1, range2)
    ```

    If I invoke `before(range: [1..10], point: 1)` is it for variant (b) ... or (c) ... ?

    Suggest renaming the param names or making the variants separate functions.

  • Reported: DMN 1.3 — Tue, 2 Feb 2021 23:38 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

DRG requirements only state am unused knowledge requirement is illegal

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

    Subsection "6.2.2.2 Knowledge Requirement notation" of "6.2.2 DRD Requirements" states that knowledge requirements must be utilised in the decision/BKM knowledge requirement:

    "If e is a decision or a BKM in some DRD, and e contains a knowledge requirement on some invocable element b, then the logic of e must contain an invocation expression of b, including expressions for each of b's parameters."

    However, this section does not mandate that Information Requirements must also be utilised by the requiring DRG element in the same way that a knowledge requirement must. If a purpose of DMN is to serve as documentation and show actual relationships between decision elements then it is paramount the DRG reflects actual usage in the model, otherwise the graph is incorrect - it may show relationships that do not reflect the decision-making reality.

    I propose adding the following to section "6.2.2.1 Information Requirement notation":

    "If e is a DRG element in some DRD, and e contains an information requirement on some other DRG element b, then the logic of e MUST contain a usage of the information provided by b"

  • Reported: DMN 1.3 — Thu, 25 Mar 2021 08:10 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Spec does not mandate that all user-defined function parameters are utilised

  • Key: DMN16-51
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    Section "10.3.2.13.2 User-defined functions" provides definition and invocation semantics for user defined functions but permits unused parameters.

    As DMN is to be 'executable documentation' I suggest that unused parameters provide documentation that does not reflect reality.

    I propose the follow additional paragraph to "10.3.2.13.2 User-defined functions" :

    "The body expression of a user-defined function SHALL utilise every formal parameter. "

  • Reported: DMN 1.3 — Thu, 25 Mar 2021 08:35 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Spec does not mandate that all formal parameters are utilised.

  • Key: DMN16-52
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    Section "10.5.3 FunctionDefinition metamodel" does not specify that formal parameters must be utilised in the function logic . As DMN is a self-documenting decision executable this leads to a situation where (documented) parameters may be defined but unnecessary.

    I propose the following paragraph is added to section "10.5.3 FunctionDefinition metamodel":

    "The body expression of a FunctionDefinition SHALL utilise every formal parameter. "

  • Reported: DMN 1.3 — Thu, 25 Mar 2021 08:25 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

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

  • Key: DMN16-54
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • Summary:

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

  • Reported: DMN 1.3 — Wed, 24 Feb 2021 05:36 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT
  • Attachments:

Add an itemKind property to ItemDefinition

  • Key: DMN16-49
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    SDMN, BPMN, and CMMN have a property that specifies the kind of element that is being modeled. The set of enumerations for this property include: data, conceptual, physical, etc.
    SDMN is directly referencing DMN’s ItemDefinition, but is extending the element to include this “itemKind” property.
    If this property makes sense in the DMN context and is added in DMN 1.4, then SDMN would not have to extend ItemDefinition for this property.
    SDMN extends ItemDefinition in other ways, which will be addressed by separate issues.

  • Reported: DMN 1.3b1 — Tue, 6 Apr 2021 22:11 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

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

  • Key: DMN16-45
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Since DMNv1.2 the spec dropped the equivalence of:

    [a] = a
    

    because it does not apply to the statement that

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

    So the expression

    [a] = a
    

    on DMNv1.2 is expected to return false.

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

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

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

    BUT

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

    according to DMNv1.2 should be false

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

    [123] = 123
    

    on DMNv1.2 is expected to be false

  • Reported: DMN 1.2b1 — Wed, 30 Jan 2019 14:43 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

properly define type(e)

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

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

  • Reported: DMN 1.2 — Tue, 27 Nov 2018 22:31 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Clarification on DMN case sensitivity of timezones

  • Key: DMN16-43
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

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

  • Reported: DMN 1.2 — Sat, 16 Mar 2019 01:12 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

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

  • Key: DMN16-46
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:15 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

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

  • Key: DMN16-47
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: DMN 1.3 — Wed, 1 Jan 2020 00:23 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Support for recursive calls by Business Knowledge Models

  • Key: DMN16-42
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

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

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

    The following paragraph is added:

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

  • Reported: DMN 1.2 — Sat, 6 Apr 2019 02:38 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

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

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

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

  • Reported: DMN 1.2b1 — Tue, 28 May 2019 16:40 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Friendlier handling of null values

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

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

  • Reported: DMN 1.2b1 — Tue, 21 May 2019 16:53 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

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

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

    split off from DMN13-12

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

Knowledge Package Model and Notation (KPMN)

  • Key: DMN16-37
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: DMN 1.2b1 — Tue, 10 Sep 2019 17:59 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT
  • Attachments:

Temporal precision inconsistencies

  • Key: DMN16-38
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: DMN 1.2b1 — Tue, 16 Jul 2019 14:02 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

need set operations and equality in FEEL

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

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

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

DMN Models need a default timezone

  • Key: DMN16-34
  • Status: open  
  • Source: fujitsu america ( keith swenson)
  • Summary:

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

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

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

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

  • Reported: DMN 1.2 — Wed, 18 Sep 2019 09:55 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Unspecified conclusion is not supported

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

Fix interchange of links to objects in BPMN/BMM

  • Key: DMN16-33
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • Summary:

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

  • Reported: DMN 1.2 — Thu, 27 Sep 2018 01:07 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Situational Data Model and Notation (SDMN)

  • Key: DMN16-36
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

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

  • Reported: DMN 1.2b1 — Tue, 10 Sep 2019 18:04 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT
  • Attachments:

inconsistent date comparisons make unavoidavle paradoxes

  • Key: DMN16-35
  • Status: open  
  • Source: fujitsu america ( keith swenson)
  • Summary:

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

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

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

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

  • Reported: DMN 1.2 — Wed, 18 Sep 2019 10:01 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Requested additional built-in functions

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

Collect decision tables

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

Metamodel constraints & validation

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

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

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

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

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

Should name declarations in same context fail or overwrite?

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

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

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

Semantic domain mapping for simple expressions

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

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

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

Add two new concrete numeric types, make number abstract

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

FEEL grammar readability

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

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

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

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

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

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

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

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

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

Should encapsulated decisions of a decision service include output decisions?

  • Key: DMN16-9
  • Status: open  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

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

    {Decision 1, Decision 2}

    "

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

    {Decision 1}

    ".

    Table 20 on page 56:

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

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

  • Reported: DMN 1.0 — Tue, 20 Mar 2018 14:49 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions

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

Improve description of built-in function string()

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

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

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

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

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

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

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

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

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

    Example

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

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

    However, Table 55, row 9, cites:

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

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

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

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

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

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

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

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

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

    Suggestions:

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

    Close as merged

    Resolved as part of DMN14-187

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

New built-in function to create a new context

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

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

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

    Suggestions:

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

    Close as merged

    Resolved as part of DMN14-187

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

No function to add an entry to a context

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

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

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

    Suggestions:

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

    Introduce 3 new built-in functions for context

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

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

New XML Namespace needed

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

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

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

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

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

    Update XML Namespaces for DMN 1.4

    Update namespace URIs with the following values:

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

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

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

Missing boxed expression for iterator expression


Missing boxed expression for filter expression

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

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

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

    Add boxed filter expression

    See attached word document and figures

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

Missing boxed expression for conditional statement


Typo Table55 row 7

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

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

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

    Fix typo

    Fix typo

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

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

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

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

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

    Also, how are the names overriden / shaded ?

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

    Clarify that names are unique within a context

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

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

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

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

    Table 40 contains the folowing row:

    date date and time False True

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

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

    Fix example about conformance of date and date and time

    Fix example and remove empty row

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

More examples of replace() function needed

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

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

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

    as already agreed on the DMN TCK.

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

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

    Add more examples of replace() function

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

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

typo - incorrect indexing

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

    Second paragraph from the bottom of page 173 contains

    have qualified names nbkmi and encapsulatedLogic bkmi.f.

    it should be

    have qualified names nbkmi and encapsulatedLogic fbkmi.

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

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

    Correct typo - incorrect indexing

    correct indexing

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

Incorrect figure reference

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

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

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

    Correct figure reference

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

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

Wrong and Incomplete FEEL grammar rule 52

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

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

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

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

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

    Proposal

    A total of 2 changes.

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

    Chapter 10.3.1.2 Grammar rules Page 121
    replace:

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

    with:

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

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

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

    insert new bullet point:

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

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

    Correct FEEL grammar rule 52

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

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

the word 'decision' is misspelt.

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

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

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

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

    Fix typo

    Fix spelling of decision

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

Missing functions for rounding

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

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

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

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

    Add extra functions for rounding

    Add extra functions for rounding

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

Sub-decisions are referenced but not defined

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

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

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

    Replace sub-decision as a term

    Replace the phrases with alternative descriptions

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

Collections are not shown on diagrams

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

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

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

    Annotate collections on DRDs

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

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

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

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

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

    Please add range<type> to the grammar.

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

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

    { ',' name ':' type }

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

    { ',' name ':' type }

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

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

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

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

    Add range to instance of

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

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

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

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

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

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

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

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

    Close without change

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

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

The result of product([]) is not defined

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

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

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

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

    Define result of product([]) to be null

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

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

DMNv1.3 fix DMN example files issues

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

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

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

    Proposal

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

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

    Fix typos in example figure and XML files

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

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

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

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

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

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

    Add functions now() and today()

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

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

Expressions cannot be used as "end points"

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

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

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

    Extend ranges to support expressions as endpoints

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

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

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

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

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

  • Reported: DMN 1.1 — Wed, 4 May 2016 08:49 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

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

    `textual expression` does not mean `Literal Expression`

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

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

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

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

Support for function types in metamodel and XSD

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

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

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

    Duplicates 13-7

    Close - already fixed

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

Spec does not clarify meaning of hex value

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

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

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

    For example "\uD83D"

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

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

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

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

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

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

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

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

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

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

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

    Hex values are already properly defined in DMN 1.3

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

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

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

Definitions of overlaps functions

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

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

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

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

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

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

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

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

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

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

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

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

Convenience documents


Typo in horizontal alignment label

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

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

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

    Fix typo

    Fix typo "labelHorizontalAlignement"

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

Wrong example for is() built-in function

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

    Executive summary

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

    Details

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

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

    Accordingly to 10.3.2.3.4 time:

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

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

    it continues with:

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

    So we can have in the FEEL semantic domain a

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

    This is consistent with 10.3.4.1 Conversion functions:

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

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

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

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

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

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

    Hence, resulting in

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

    instead.

    Proposal

    change last line example from:

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

    to

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

    Correct table 77

    change last line example from:

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

    to

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

Wrong example for distinct values() built-in function

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

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

    Proposal

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

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

    with

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

    Fix typo on distinct values() function example

    See revised text.

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

Wrong XSD for tDecisionService

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

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

    the table
    Table 17: DecisionService attributes and model associations

    reports:

    outputDecisions: Decision [1..*]

    but the XSD schema:

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

    Proposal

    change XSD from:

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

    to

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

    (minOccurs to 1)

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

    Need to allow interchange of incomplete models

    No change

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

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

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

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

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

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

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

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

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

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

    Hit policies work as designed with partial data

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

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

Extend endpoints to support expressions

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

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

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

    Proposal:

    Page 120 Section 10.3.1.2. Grammar rules

    Replace

    16. endpoint = simple value ;

    with

    16. endpoint = expression ;

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

    Close as duplicate

    Duplicate of DMN14-11

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

Clarify method signature syntax for Java Function Definition

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

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

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

    Out of date. Issue already addressed in DMN 1.3.

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

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

DMN string join built-in function proposal

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

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

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

    Assessment

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

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

    first name + " " + last name
    

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

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

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

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

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

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

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

    Add String join function

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

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

    Assessment

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

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

    first name + " " + last name
    

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

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

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

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

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

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

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

FEEL ambiguity

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

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

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

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

    Fix FEEL grammar ambiguity

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

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

Wrong character in expression for PMT function definition

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

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

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

    Fixed:

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

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

    Corrected by DMN14-97

    Duplicate issue - already corrected by DMN14-97

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

BigDecimal is not the only mapping of number to Java

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

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

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

    BigDecimal is not the only mapping of numbers in Java

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

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

DMN 1.3 Metamodel


Wrong example for 10.6.1 Context Figure 10.18: Example context

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

    This is taken from the DMN spec :

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

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

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

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

    Proposal

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

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

    with

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

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

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

    Correct Context Figure 10.6.1

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

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

    with

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

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

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

Wrong example for substring() builtin funciton

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

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

    Proposal

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

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

    with

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

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

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

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

    Remove space from substring() example

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

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

    with

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

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

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

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

Wrong example snippet in 10.3.2.9.4.1 Examples

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

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

    Proposal

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

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

    with

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

    Fix typo in XML snippet

    Replace typeref with typeRef

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

Enumerations can only be defined as strings

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

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

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

    DMN should allow for the creation and management of enumerations:

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

    These enumerations should be considered symbolic constants, not strings

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

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

  • Reported: DMN 1.1 — Thu, 26 Oct 2017 16:12 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Lexical representation of time string has ambiguous definitons

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

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

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

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

    The list of ambiguities:

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

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

  • Reported: DMN 1.1 — Mon, 13 Nov 2017 15:24 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Add two new concrete numeric types, make number abstract

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

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

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

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

    Here is my proposal:

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

    If we agree in principal all start working on it.

  • Reported: DMN 1.1 — Wed, 6 Dec 2017 13:44 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

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

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

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

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

  • Reported: DMN 1.1 — Thu, 8 Mar 2018 16:20 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Improve description of built-in function string()

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

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

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

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

    • null -> null
    • boolean -> "true" or "false"
    • string -> "This is a string"
    • number -> "-1.234"
    • date -> "2017-10-11"
    • time -> "11:00:00.123" or "11:00:00.123+02:00" or "11:00:00.123@Europe/Paris"
    • date and time -> "2017-10-11T11:00:00.123" or "2017-10-11T11:00:00.123+02:00" or "2017-10-11T11:00:00.123@Europe/Paris"
    • days and time duration -> "P2DT3H4M5.123S"
    • years and months duration -> "P2Y3M"
    • list -> "[1,2,3]"
    • context -> "{a: true, b: false}"
    • range -> "[1..100]"
    • unary test -> "> 10"
    • function -> null
  • Reported: DMN 1.1 — Wed, 11 Oct 2017 09:02 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

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

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

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

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

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

    Clarification in the specification is appreciated.

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

  • Reported: DMN 1.1 — Tue, 10 Oct 2017 14:32 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

    Table 53 should be adjusted accordingly.

  • Reported: DMN 1.1 — Tue, 10 Oct 2017 09:57 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Should encapsulated decisions of a decision service include output decisions?

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

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

    {Decision 1, Decision 2}

    "

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

    {Decision 1}

    ".

    Table 20 on page 56:

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

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

  • Reported: DMN 1.0 — Tue, 20 Mar 2018 14:49 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions

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

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

  • Reported: DMN 1.1 — Fri, 3 Aug 2018 21:19 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

    This is a suggestion for future versions of the spec:

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

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

    function ( x ) x in <unary_test>

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

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

    Invoking unary tests explicitly would be like invoking a function:

    Bob is minor : is minor( bob.age )

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

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

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

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

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Include Test Cases in Decision Model

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

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

  • Reported: DMN 1.1 — Sat, 28 May 2016 16:25 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Change depiction of Input to be harmonized with BPMN and CMMN


XSD: global context

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

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

  • Reported: DMN 1.0 — Sun, 31 May 2015 16:35 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Business Knowledge Model can have Information Requirements

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

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

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

  • Reported: DMN 1.0 — Thu, 23 Jul 2015 23:30 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

  • Reported: DMN 1.0 — Thu, 3 Sep 2015 15:58 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

No notation for ItemDefinition

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

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

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

  • Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Business Context links go both ways

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

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

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

inconsistent date comparisons make unavoidavle paradoxes

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

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

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

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

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

  • Reported: DMN 1.2 — Wed, 18 Sep 2019 10:01 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Fix interchange of links to objects in BPMN/BMM

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

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

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

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

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

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Unspecified conclusion is not supported

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

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

  • Reported: DMN 1.1 — Mon, 13 Jun 2016 21:41 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

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

  • Reported: DMN 1.1 — Sun, 26 Jun 2016 10:11 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

need set operations and equality in FEEL

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

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

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

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

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

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

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

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

  • Reported: DMN 1.1 — Thu, 11 Aug 2016 15:35 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

  • Reported: DMN 1.1 — Wed, 24 Aug 2016 16:45 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Collect decision tables

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

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

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

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

  • Reported: DMN 1.1 — Thu, 13 Oct 2016 08:25 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Metamodel constraints & validation

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

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

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

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

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

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Requested additional built-in functions

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

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

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

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

  • Reported: DMN 1.1 — Mon, 2 Jan 2017 20:43 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Semantic domain mapping for simple expressions

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

    The FEEL grammar contains simple expressions as starting terminal

    page 107 6. simple expressions = simple expression ,

    { "," , simple expression }

    ;

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

  • Reported: DMN 1.1 — Fri, 17 Mar 2017 14:42 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Improvement of Semantic Domains Specification

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

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

    • a metamodel
    • relationships between various types

    I propose adding a metamodel and the following two relationship:

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

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

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

  • Reported: DMN 1.1 — Thu, 30 Mar 2017 12:38 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

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

  • Reported: DMN 1.1 — Wed, 3 May 2017 08:58 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

  • Reported: DMN 1.1 — Wed, 3 May 2017 09:11 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

Should name declarations in same context fail or overwrite?

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

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

  • Reported: DMN 1.1 — Wed, 3 May 2017 09:25 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

    Examples:

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

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

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

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

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

  • Reported: DMN 1.1 — Wed, 3 May 2017 15:24 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

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

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

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

    Examples:

    • [1,2,3][min(3,2,1)]
    • {a:function() external {java: {class: "clazz", method signature: "method()"}}, b:[1,2,3][a()]}.b
    • {a: 1, b: a instance of number, c: [1,2,3][b] }
  • Reported: DMN 1.1 — Wed, 3 May 2017 14:56 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

  • Reported: DMN 1.1 — Mon, 15 May 2017 17:59 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

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

More Generic Ways to Define Decision Table Properties


FEEL grammar readbility

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

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

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

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

    Defer to DMN 1.5

    Defer to DMN 1.5

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

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

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

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

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

    If you apply this expression to the following two values:

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

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

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

    Addition
    which results for addition into:

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

    which is:

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

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

    Subtraction
    which results for subtraction into:

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

    which is:

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

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

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

  • Reported: DMN 1.1 — Mon, 2 Oct 2017 12:41 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Temporal precision inconsistencies

  • Key: DMN14-53
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The spec sometimes refers to the temporal precision as milliseconds and sometimes to seconds. Sections 10.3.2.3.3, 10.3.2.3.5 and 10.3.2.3.6 refer to Seconds whereas table 48 offers a semantic of Milliseconds

  • Reported: DMN 1.2b1 — Tue, 16 Jul 2019 14:02 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Clarification regarding equivalence of date vs date and time

  • Key: DMN14-54
  • Status: closed  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    Section 10.3.2.3.5 date contains the following:

    Where necessary, including the valuedt function (see 10.3.2.3.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00).

    Is not obvious when the equaivalence should be applied.

    One option is to add an implicit conversion, similar to the ones for singleton lists.

  • Reported: DMN 1.2 — Sun, 2 Jun 2019 13:01 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT
  • Attachments:

Support for recursive calls by Business Knowledge Models

  • Key: DMN14-62
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The definition of "well formed" for a BusinessKnowledgeModel excludes the notion of the encapulatedLogic of a BusinessKnowledgeModel being able to invoke itself to permit recursion. There is no means to define a 'self' relationship via knowledgeRequirements - the spec forbids it.

    However, vendors are currently supporting BusinessKnowledgeModel recursion simply by permitting a BusinessKnowledgeModel's encapulatedLogic to invoke the contained BusinessKnowledgeModel as a function using the contained BusinessKnowledgeModel's name. I propose we formalise this in the spec.

    I propose that after the definition of well-formed on page 56/57 (repeated below):

    "An instance of BusinessKnowledgeModel is said to be well-formed if and only if, either it does not have any knowledgeRequirement, or all of its knowledgeRequirement elements are well-formed. That condition
    entails, in particular, that the requirement subgraph of a BusinessKnowledgeModel element SHALL be acyclic, that is, that a BusinessKnowledgeModel element SHALL not require itself, directly or indirectly. "

    The following paragraph is added:

    "However, the encapsulatedLogic within a BusinessKnowledgeModel may invoke itself in a recursive manner by using the name of the containing BusinessKnowledgeModel as an invokable name."

  • Reported: DMN 1.2 — Sat, 6 Apr 2019 02:38 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Clarification on DMN case sensitivity of timezones

  • Key: DMN14-63
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    DMN spec refers to usage of iana timezones. iana does not specify that timezones are case-sensitive - that is up to the implementation. https://data.iana.org/time-zones/theory.html: re zone naming:

    "Do not use names that differ only in case. Although the reference implementation is case-sensitive, some other implementations are not, and they would mishandle names differing only in case."

    This issue is seeking clarification via the spec as to whether DMN's usage of time zones permits case insensitivity such that "etc/utc" is the same zone as "Etc/UTC" ... or not.

  • Reported: DMN 1.2 — Sat, 16 Mar 2019 01:12 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Lack of visual notation for processing of / iteration over lists in FEEL

  • Key: DMN14-60
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    split off from DMN13-12

  • Reported: DMN 1.2 — Tue, 20 Nov 2018 17:55 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

"instance of" not possible with some built-in functions

  • Key: DMN14-66
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    some built in functions are overloaded in that they can have multiple signatures. So, say, performing an "instance of" to compare against the function "min" is meaningless as the signature is not known unless it is invoked.

    Unless the type system is to take into account overloaded functions?

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:15 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Clean up example xml files

  • Key: DMN14-57
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Sample xml files have Trisotech extension elements. These should be removed prior to publication.

  • Reported: DMN 1.2b1 — Tue, 28 May 2019 16:52 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Provide better spec and examples for Equality, Identity, and Equivalence

  • Key: DMN14-58
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    the builtin function is() refers to this section. It should cover some pos/neg examples of equality vs. identity, and explain aggregate elements in D, e.g. list of structures.

  • Reported: DMN 1.2b1 — Tue, 28 May 2019 16:40 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

data equivalence with date and time

  • Key: DMN14-51
  • Status: closed  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    Section 10.3.2.3.5 contains the following:

    Where necessary, including the valuedt function (see 10.3.2.3.6), a date value is considered to be equivalent to a date time
    value in which the time of day is UTC midnight (00:00:00).

    It is not very clear where this equivalence is going to be applied.

    The proposal is to specify the above in a more precise manner, possibly as an implicit conversion.

  • Reported: DMN 1.2 — Mon, 27 May 2019 08:30 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Friendlier handling of null values

  • Key: DMN14-59
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    E.g. in aggregation, default for item definition, see examples in DMN-2, where filters like [item!=null] are used repeatedly

  • Reported: DMN 1.2b1 — Tue, 21 May 2019 16:53 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.

  • Key: DMN14-69
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests.
    UnaryTest should be added to the diagram.

  • Reported: DMN 1.3 — Wed, 1 Jan 2020 00:23 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression

  • Key: DMN14-70
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression. The figure should be updated.
    This is similar to the issue for Figure 6-10, which has the same problem.

  • Reported: DMN 1.3 — Wed, 1 Jan 2020 00:21 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Typos in the XMI files

  • Key: DMN14-71
  • Status: closed  
  • Source: Camunda GmbH ( Maciej Barelkowski)
  • Summary:

    I found two typos in the XMI files:
    1. In the DMNDI12.xmi, lines 510-512:

    ```
    <packagedElement xmi:type="uml:Class" xmi:id="_18_1_f7a0369_1441612964861_428140_5975"
    name="DC::Style"
    isAbstract="true"/>
    ```

    The class cannot refer to dc:Style as such class does not exist. The XSD refers to di:Style.

    2. In the DMN12.xmi, lines 956-958:

    ```
    <ownedAttribute xmi:type="uml:Property" xmi:id="_17_0_3_1_42401a5_1375643571589_681805_3414"
    name="input
    "
    visibility="public"
    ```

    Attribute name includes an encoded newline character (`\n`) which is not present in the XSD.

  • Reported: DMN 1.2 — Thu, 19 Dec 2019 13:19 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

DMN Models need a default timezone

  • Key: DMN14-47
  • Status: closed  
  • Source: fujitsu america ( keith swenson)
  • Summary:

    All date expressions, if the timezone is not explicitly mentioned, are interpreted as being in the timezone of the computer running the code. This means you can design a model that runs correctly in one timezone,a nd incorrectly in a different one.

    Imagine you have a development team in Bangalore which makes a DMN model that runs correctly and passes all the tests. Then it is installed into the company server in London, and it fails.
    Does anyone think this is a good idea?

    The solution is simple: the model should have a default timezone. All date expressions that don't mention the timezone are interpreted according to this default time zone, and NOT according the timezone of the machine you are running on. Then, models will run exactly the same way no matter where it is run. That is a good idea, right?

    See this: https://social-biz.org/2017/08/03/a-strange-feeling-about-dates/

  • Reported: DMN 1.2 — Wed, 18 Sep 2019 09:55 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

Situational Data Model and Notation (SDMN)

  • Key: DMN14-49
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Situational Data is the set of Data Items and their structures that are needed for the performance and understanding of a Knowledge Package Model.
    The details of the Data Items will usually be a subset of the “official” complexity of those items in the environment of the Knowledge Package Model.
    For example, the official definition of the Data Item for Blood Pressure (in healthcare) includes more than 50 properties. A Data Item in a Situational Data Model may need only 2 of those properties for execution of the Processes, Cases, and or Decision Services.
    Semantic References can be added to link the Data Item to the “official” details.
    Uses of the Data Items in BPM+ models that determine the scope of Situational Data include:
    Data required for DMN Decisions
    Data required for BPMN Gateways transitions
    Data required to be passed to/from services invoked by BPMN and CMMN
    Data required to trigger Sentries in CMMN
    Etc.

  • Reported: DMN 1.2b1 — Tue, 10 Sep 2019 18:04 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT
  • Attachments:

Knowledge Package Model and Notation (KPMN)

  • Key: DMN14-50
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    A Knowledge Package is mechanism for packaging and distributing a set of BPM+ models (the knowledge)
    A Knowledge Package references separate, but connected BPM+ models (BPMN Processes, CMMN Cases, and DMN Decision Services)
    KPMN is focused solely on the BMI behavioral standards
    A Knowledge Package also contains a Data Item library for the data that will be used by the BPM+ models
    A Situational Data Model and Notation (SDMN) is also being proposed as a potential BMI standard to be added to the BPM+ stack (see separate presentation on this topic)
    A Knowledge Package also contains metadata about the topic of the package to aid in understanding the content and to find appropriate Knowledge Packages
    We are still exploring the relationships between KPMN and Provenance and Pedigree
    KPMN includes a diagram to illustrate the scope of the Knowledge Package’s content (a Knowledge Model Diagram)

  • Reported: DMN 1.2b1 — Tue, 10 Sep 2019 17:59 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT
  • Attachments:

Inconsistency DMNv1.2 dropping [a]=a and get entries example

  • Key: DMN14-65
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Since DMNv1.2 the spec dropped the equivalence of:

    [a] = a
    

    because it does not apply to the statement that

    a singleton list L, when used in an expression where a list is not expected, behaves as if L[1] is written.

    So the expression

    [a] = a
    

    on DMNv1.2 is expected to return false.

    However, in section 10.3.2.6 Context of the spec, it provides the following statement for the get entries function:

    To retrieve a list of key,value pairs from a context m, the following built-in function may be used: get entries(m).
    For example, the following is true:

    get entries({key 1 : "value 1 "})[key="key 1 "].value = "value 1 "
    

    BUT

    get entries({key1 : "value1"})[key="key1"].value = "value1"
    
      by substitution:
    
    [ { key : "key1", value : "value1" } ][key="key1"].value = "value1"
    [ { key : "key1", value : "value1" } ].value = "value1"
    [ "value1" ] = "value1"
    

    according to DMNv1.2 should be false

    By the same principle that the DMNv1.2 for the following literal expression:

    [123] = 123
    

    on DMNv1.2 is expected to be false

  • Reported: DMN 1.2b1 — Wed, 30 Jan 2019 14:43 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

properly define type(e)

  • Key: DMN14-64
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In some places the spec uses type(e) and other places type(e). These are different. The former provides a type-checking function that can validate a FEEL expression e without input data values (although some kind of scope is needed for disambiguation). The latter simply returns the datatype of the semantic domain element e. The former is more useful to implementors, but more work to specify. Essentially, all the semantic mapping tables need a new column to specify the result type given the input types, for each FEEL operator and builtin. The latter is a matter of generalizing Table 39. It must cover cases such as type([0,false]). It should be clear that type(e) as a function must return the most specific type (and there must be only 1), but informally the types also include those that are conformed to, so for example, [1,2,3] has types list<number>, list<Any>, Any.

  • Reported: DMN 1.2 — Tue, 27 Nov 2018 22:31 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    Defer to DMN 1.5

    Defer to DMN 1.5

  • Updated: Thu, 31 Mar 2022 19:30 GMT

No way to show relative multiplicity of decisions and their information requirements

  • Key: DMN14-153
  • Status: closed  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • Summary:

    Item Definitions are hierarchical so the top level one in an Input Data or a Decision might not be a collection while one or more of those contained are. This means that there may be a collection to process even if the Input Data or Decision is not marked as a collection (see DMN14-123 for this separate issue). It should be possible to show both "fan in" where multiple instances of the source of the requirement are used by a single instance of a decision and "fan-out" when the source of requirement contains a collection which will be processed one at a time by the decision.

  • Reported: DMN 1.3 — Wed, 24 Feb 2021 05:36 GMT
  • Disposition: Deferred — DMN 1.4
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Wed, 15 Dec 2021 21:12 GMT
  • Attachments:

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:

Incorrect claim about the Unicode character range and EBNF character expressions

  • Key: DMN13-127
  • Status: closed  
  • Source: Fujitsu ( Keith Swenson)
  • Summary:

    This is a trivial typo, and the fix is easy.

    Lower on page 108 it says: "the character range that includes all Unicode characters is [\u0-\u10FFF]." This range specified has less than 70,000 characters.

    I don't think your intent is to limit implementations to 70K characters and in fact in places (e.g. grammar rule #30) character values larger than this are mentioned.

    "all Unicode characters" is actually the entire range of 32-bit values (minus some control codes: hundreds of millions of characters, most of which are undefined). Instead you are defining a SUBSET of this that will be allowed.

    Second, the most common implementation of Unicode uses UTF-16, and as a consequences OF THIS ENCODING, the range of representable characters is 0 through 10FFFF. Note that is six hex digits, there are four F digits. There are over a million characters in this range.

    (1) Nowhere in the spec does is say you are limiting characters to the UTF-16 range. This should be explicitly stated if that is your intent.

    (2) The phrase on page 108 should be changed to; "DMN allows the use of unicode characters in the range of [\u0-\u10FFFF]."

    (3) The specification of EBNF character expression should be changed to allow 6 hex digits, currently it says you can only use five digits max.

  • Reported: DMN 1.2b1 — Mon, 31 Dec 2018 17:00 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Allow 4 or 6 hexadecimal digits for unicode code point

    See attached word doc

  • Updated: Tue, 26 Jan 2021 20:17 GMT
  • Attachments:
    • DMN13-127-v7.docx 19 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Should add a new unicode escape syntax

  • Key: DMN13-143
  • Status: closed  
  • Source: fujitsu america ( keith swenson)
  • Summary:

    On page 110, rule #66 gives these escape sequences:

    string escape sequence = "\'" | "\"" | "
    " | "\n" | "\r" | "\t" | "\u", hex digit, hex digit, hex digit, hex digit;

    Using the hex character value notation "\uD41A" you can only four hex digits which is not enough to specify the entire Unicode character range. The spec specifically mentions that much higher values are allowed, and there should be a standard way to specify them without having to use the cryptic surrogate character pairs.

    This suggestion is to add braces to allow variable length hex values in exactly the way that JavaScript allows:

    "\u

    {1F40E}

    "

    This is character 128,014 in the unicode set. To specify this character using surrogate pairs you would have to use: "\uD83D\uDC0E" which is complicated and confusing and is currently subject to discussion on whether this is valid or not within the current spec.

    "A" = "\u

    {41}

    "

    "è" = "\u

    {E8}

    "

    "査" = "\u

    {67FB}

    "

    "" = "\u

    {1F407}

    " (Jira seems to crash if I inlcude this character)

    It is nice because you actually use the Unicode code point value, and because of the braces you can specify a variable number of hex digits so the entire Unicode set can be easily addressed. The precidence for this syntax is set by JavaScript (

    https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

    See page 218 where it defines this (slightly translated):

    UnicodeEscapeSequence ::
    \u Hex4Digits
    \u

    { CodePoint }

    This will not conflict with any existing implementation since the opening brace was not allowed in earlier implementations. The new allowed syntax could be used in DMN 1.3 and higher.

  • Reported: DMN 1.2b1 — Fri, 8 Feb 2019 19:06 GMT
  • Disposition: Duplicate or Merged — DMN 1.3
  • Disposition Summary:

    Addressed by resolution of DMN-127

    DMN-127 adds \U, 6*hex digit to address this issue as well

  • Updated: Tue, 26 Jan 2021 20:17 GMT

Ambiguty for the source/target of DMNEdge when there is multiple depictions of its source and target

  • Key: DMN13-109
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    DMN DI allows to depict element more than once. When drawing a diagram, tools need to check graphically the way points to know to which DMNShape a DMNEdge is actually connected to.

  • Reported: DMN 1.2 — Mon, 26 Nov 2018 22:50 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add sourceElement and targetElement to DMNEdge

    Add a sourceElement and targetElement to the DMNEdge class so the actual DMNShape used as source and target can be resolved without graphical deduction.

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Incorrect figure 6.10

  • Key: DMN13-244
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    Figure 6.10 has not been updated in line with issue DMN13-140.

  • Reported: DMN 1.2b1 — Tue, 3 Dec 2019 17:14 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Correct fig 6.10 and associated text

    Replace figure 6.10 & modify para 2 of section 6.3.1 so that UnaryTests is a subclass of Expression, rather than DMNElement.

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

PMML invocation output value in the case of single prediction

  • Key: DMN13-181
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The proposal targets the case of a PMML invocation having a single output prediction(s), for the result to be simply the value result of such single prediction, instead of a context with 1 only entry, name of the single output prediction, and value of that prediction.

  • Reported: DMN 1.2 — Mon, 23 Sep 2019 14:34 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Do not wrap single values returned from PMML in context

    Executive summary

    The proposal targets the case of a PMML invocation having a single output prediction(s), for the result to be simply the value result of such single prediction, instead of a context with 1 only entry, name of the single output prediction, and value of that prediction.
    This would also align expected invocation behaviour similarly to what RTF agreed on when dealing with Decision Service, ref: https://issues.omg.org/browse/DMN13-163

    Rationale and details

    By the PMML specification, a ML predictive model can produce multiple outputs, so in general a (FEEL) Context is assumed to be returned by its invocation, containing a key-value pair of prediction name and value.

    However,
    Most PMML models have a single prediction as output.
    To get an idea, can reference examples presented on PMML website: http://dmg.org/pmml/pmml_examples/index.html

    Specifically to a well-known example, Iris dataset, Tree model: http://dmg.org/pmml/pmml_examples/KNIME_PMML_4.1_Examples/single_iris_dectree.xml
    This would imply every time a Decision invokes a BKM for the PMML prediction, something like:

    { class : "Iris-versicolor" }
    

    is returned, instead of simply getting back something like a FEEL string:

    "Iris-versicolor" 
    

    So it would make very annoying for dependent decision the need to always access the single prediction output in the key-value pair:

    result.class
    

    instead of more simply:

    result
    

    and other analogous implications.

    This proposal would align the expected behaviour to what what RTF agreed on when dealing with Decision Service, ref: https://issues.omg.org/browse/DMN13-163 for coercion of the singleton value, in the case of a single PMML output prediction.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

A signature for the time() built in function is missing from table 66

  • Key: DMN13-175
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Section 10.3.2.3.4 time of the spec already says:
    [..] If no time offset is specified, the time is interpreted as a local time of day at some location, whose relationship to UTC time is dependent on time zone rules for that location, and may vary from day to day. [..]

    But table 66 show the signature time(hour, minute, second, offset) but does not show the signature time(hour, minute, second) which forces users to write time(08, 04, 32, null) when what they would want to write is simply time(08, 04, 32)

  • Reported: DMN 1.2b1 — Thu, 29 Aug 2019 12:54 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Make offset parameter optional in built-in function time()

    In Table 66 page 145 change time(hour, minute, second, offset) for time(hour, minute, second, offset?)

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Decision Logic Examples

  • Key: DMN13-2
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    DMN 1.1 should provide examples of all types of decision model allowed by the standard, both graphically (DRD and decision table, where appropriate) and XML serialization. Currently missing:
    1. decision tables with an expression (more than a name) in inputExpression and outputExpression.
    2. decision tables with inputEntry or outputEntry referencing a "name" as defined by S-FEEL, i.e. not just a literal.
    3. DRD and decision table involving what Vanthienen calls "action subtables". All existing examples are "condition subtables".
    4. Serialization of crosstab format tables.
    5. Representation of literal values vs names in serialization.
    6. Representation of PMML and FEEL in the serialization.

  • Reported: DMN 1.0 — Sun, 12 Apr 2015 15:39 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add second example to Chapter 11

    See attached word doc for spec changes. See attached zip file for additions to examples.zip.

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Disambiguation for Modulo / Remainder function

  • Key: DMN13-125
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The spec defines "modulo" FEEL built-in function as: "the remainder of the division of dividend by divisor"
    However, this might be subject to ambiguity in the case the Divisor or Dividend are negative, as also mentioned by Wikipedia page which list examples out of several programming languages and systems: https://en.wikipedia.org/wiki/Modulo_operation by saying that "When either a or n is negative, the naive definition breaks down and programming languages differ in how these values are defined".

    FEEL aims to be a Friendly Enough expression language, and especially thinking about DMN practitioners who might be used to Spreadsheet based systems might find misleading if the definition of the FEEL "modulo" gets bind to the Java (default) definition, the following table illustrate the difference:

    Dividend Divisor MOD() from Microsoft Excel, Google Sheets, LibreOffice Calc, Wolfram Alpha, etc. Java % or BigDecimal#remainder or other languages default
    10 4 2 2
    10 -4 -2 2
    -10 4 2 -2
    -10 -4 -2 -2

    or to other implementation languages where the definition of Modulo/Remainder is not explicit, or the default one is not consistent with Spreadsheet default one.

    It is proposed therefore to change the specification in 10.3.4.5 Numeric functions Table 70 for the FEEL "modulo" built-in function
    FROM: "Returns the remainder of the division of dividend by divisor."
    TO: "Returns the remainder of the division of dividend by divisor. In case either dividend or divisor is negative, the result has the same sign of the DIVISOR."

    This would avoid ambiguity by making a clear definition of what should be the sign in case either of the operands are negative.
    This should make this consistent with Spreadsheet based system result of "MOD()" expression, which should address being Friendly Enough for DMN practitioners and DM analyst.
    This would not make the result the same as the default of Java % operator or BigDecimal#remainder, but Java based implementation/Vendor can trivially address the result to be compliant with the spec.

  • Reported: DMN 1.2b1 — Fri, 4 Jan 2019 18:38 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Improve the specification of the modulo builtin function

    The existing specification does not restrict the arguments to integers, and does not clearly define the sign of the result.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Add built-in functions to support Allen's interval algebra

  • Key: DMN13-139
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Allen's interval algebra defines possible relations between two intervals.
    Namely:
    before
    meets
    overlaps
    finishes
    includes
    starts
    coincides
    after
    metBy
    overlappedBy
    finishedBy
    during
    finishes

    Some more info available here: https://en.wikipedia.org/wiki/Allen%27s_interval_algebra

  • Reported: DMN 1.2b1 — Wed, 6 Feb 2019 21:26 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add interval builtins, range objects in semantic domain, and compact date literals

    See attached word doc

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Incorrect grammar rule references and missing UnaryTests section in MM

  • Key: DMN13-140
  • Status: closed  
  • Source: Red Hat ( Edson Tirelli)
  • Summary:

    As discussed in the RTF call on Feb 5th, we need to fix:

    1.Refs to grammar rules at end of ch9 are incorrect (change 14 to 12 and check others)
    2. grammar rule 14 in ch10 is unused and should be removed
    3. UnaryTests UML class is missing from the spec (it is shown on one diagram not the defining occurrence
    Need to specify this MM class and point to the correct unary tests grammar rule that defines its syntax (this will be different for FEEL and SFEEL)

  • Reported: DMN 1.2b1 — Tue, 5 Feb 2019 17:53 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Fix grammar rule references and add UnaryTests MM

    Specification Text
    See revised text.

    Metamodel

    • In Figure 7.6, Change UnaryTests class to inherit from Expression rather than directly from DMNElement
    • See attached Fig7_6

    XML Schema

    • Correct tExpression to make the typeRef attribute optional (as shown in the metamodel of Fig 7.6)
    • make tUnaryTests extend tExpression instead of tDMNElement

    Backward Compatibility Argument

    • Expressions that do specify a typeRef will still be valid when the typeRef in the XSD is corrected to be optional
    • UnaryTests that do not specify a typeRef will still be valid because the typeRef is optional
  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Allegedly bug in Table Table 40 Examples of equivalence and conformance relations

  • Key: DMN13-141
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The DMNv1.2 spec reports these two lines examples:

    type1 type2 equivalent to conforms to
    type([{"id": 1,"name":"Peter", "age": 45}])
    
    type(Decision3)
    
    True True
    type(Decision4)
    
    type(Decision3)
    
    True True

    However concerning the first referenced line, type1

    type([{"id": 1,"name":"Peter", "age": 45}])
         ^
      by following the syntax used in table 39 takes the form of the type:
    
    list<context<"id": number,"name": string, "age": number>>
    

    and type2:

    type(Decision3)
    
      by following the syntax used in table 39 takes the form of the type:
    
    context<"id": number,"name": string, "age": number>
    

    So in the first referenced line it is asserted type1 is Equivalent to type2, but a list and a context are not Equivalent by the rule described in section 10.3.2.9.1 Type Equivalence

    Similarly for the second referenced line, type 1:

    type(Decision4)
    
      by following the syntax used in table 39 takes the form of the type:
    
    list<context<"id": number,"name": string, "age": number>>
    

    As for the ItemDefinition with the isCollection="true" which therefore obliges the definition that:

    IsCollection: Boolean Setting this flag to true indicates that the actual values defined by this ItemDefinition are collections of allowed values.

    So again by the section 10.3.2.9.1 Type Equivalence there are no "iff" rules explicited which would make a LIST Equivalent to a CONTEXT.

    Analogous issue for the reported values of Conformance.

    Can you kindly verify and clarify if needed, please?

  • Reported: DMN 1.2b1 — Fri, 1 Feb 2019 14:07 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Replace 2 rows in table 40

    See attached word doc

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

type conversions are too spread out in Ch 10

  • Key: DMN13-132
  • Status: closed  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    The spec does not contain a section where the type conversions are described, hence they end-up spread across the spec. For example, a particular case of invocation conversion is described in 10.3.2.5:

    Similarly, on a function f( p ) where the domain of the formal parameter p does not include lists, but on an invocation f( pa ) the
    actual parameter pa is a singleton list where the type of pa[1] belongs to the domain of p, then pa[1] should be used instead.

    Consolidating all of them in one paragraph will make the spec more readable and easier to change in the future (e.g. we want to apply conversions in other context). It will also help us to identify gaps in the spec.

    It's a natural step after adding the type relationships in DMN 1.2.

  • Reported: DMN 1.2b1 — Wed, 30 Jan 2019 16:34 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add extra paragraph to clarify type conversions

    see attached word doc

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Remove the limitation that the second operand of exponentiation be an integer

  • Key: DMN13-111
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Table 55: Semantics of exponentiation limits the second operand to be an integer. It allow any number.

  • Reported: DMN 1.2b1 — Tue, 27 Nov 2018 14:10 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Allow second operand of exponentiation to be a number

    The second operand of exponentiation should be allowed to be a number rather than limited to an integer

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Decision Requirement Metadata Examples

  • Key: DMN13-156
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Enhance the example in chapter 11 with more realistic metadata attached to the decisions, input data, knowledge sources, etc.

  • Reported: DMN 1.2b1 — Tue, 21 May 2019 00:52 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Enhance Chapter 11 example with additional standard metadata

    Enhance Chapter 11 example with additional standard metadata, as attached.

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Decision Service output value in the case of single output Decision

  • Key: DMN13-163
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Executive summary

    The proposal targets the case of a Decision Service having a single output decision(s), for the result to be simply the value result of such single decision, instead of a context with 1 only entry, name of the single output decision, and value of that decision

    Rationale and details

    with reference to figure from the spec Figure 11.7: Routing Decision Service, the use of the decision service in a literal expression would currently require to write something like:

    if Routing Decision Service( ..., ... ).Routing = "ACCEPT" then true else false
    

    please notice specify the .Routing would sound redundant and arguably some may say user-unfriendly in the scenario of a Decision Service with a single output decision.

    In the case of a Decision Service with a single output decision, we could more friendly have:

    if Routing Decision Service( ..., ... ) = "ACCEPT" then true else false
    

    In other words, the result of invoking the "Routing Decision Service" accordingly to this proposal would be:

    Routing Decision Service :  "ACCEPT"
    

    and not:

    Routing Decision Service :  { Routing : "ACCEPT" }
    

    as of today.

    Naturally when a Decision Service contains multiple output DecisionS, then is always the context, for instance taking example from DMN Spec Figure 11.6: Bureau Strategy Decision Service the result will continue to be:

    Bureau Strategy Decision Service :  { Strategy : ..., Bureau call type: ... }
    

    Proposal specification change

    With reference to document formal/19-01-05, chapter "10.4 Execution Semantics of Decision Services", page 151
    Replace the following:

    The execution semantics of S is FEEL(F): a function that when invoked with values from the FEEL semantic domain
    bound to the parameters representing input data and input decisions, returns a context consisting of all the output
    decisions' output values.

    with:

    The execution semantics of S is FEEL(F): a function that when invoked with values from the FEEL semantic domain
    bound to the parameters representing input data and input decisions, returns:

    • in the case of a single output decision(s), the single decision's output value.
    • in the case of multiple output decisions, a context consisting of all the output decisions' output values.
  • Reported: DMN 1.2 — Mon, 20 May 2019 15:30 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    clarify that single output decision service does not result in context but rather the single output value

    Executive summary

    The proposal targets the case of a Decision Service having a single output decision(s), for the result to be simply the value result of such single decision, instead of a context with 1 only entry, name of the single output decision, and value of that decision

    Rationale and details

    with reference to figure from the spec Figure 11.7: Routing Decision Service, the use of the decision service in a literal expression would currently require to write something like:

    if Routing Decision Service( ..., ... ).Routing = "ACCEPT" then true else false
    

    please notice specify the .Routing would sound redundant and arguably some may say user-unfriendly in the scenario of a Decision Service with a single output decision.

    In the case of a Decision Service with a single output decision, we could more friendly have:

    if Routing Decision Service( ..., ... ) = "ACCEPT" then true else false
    

    In other words, the result of invoking the "Routing Decision Service" accordingly to this proposal would be:

    Routing Decision Service :  "ACCEPT"
    

    and not:

    Routing Decision Service :  { Routing : "ACCEPT" }
    

    as of today.

    Naturally when a Decision Service contains multiple output DecisionS, then is always the context, for instance taking example from DMN Spec Figure 11.6: Bureau Strategy Decision Service the result will continue to be:

    Bureau Strategy Decision Service :  { Strategy : ..., Bureau call type: ... }
    
  • Updated: Mon, 30 Mar 2020 19:50 GMT

New FEEL URI needed

  • Key: DMN13-188
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    FEEL has changed in DMN 1.3. We need a way to know which version is used in a model, e.g. by using a new URI for expressionLanguage and typeLanguage.

    This is also important, in case FEEL is used outside DMN, because in that case the surrounding model doesn't have any reference to a DMN version.

  • Reported: DMN 1.2 — Tue, 8 Oct 2019 16:18 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Update FEEL URI

    Update the URI for FEEL to https://www.omg.org/spec/DMN/20191111/FEEL/ as defined in DMN13-187.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Functions resolution

  • Key: DMN13-178
  • Status: closed   Implementation work Blocked
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    FEEL supports function invocation described in rule 40, for example f(a, b, c)

    The specification doesn't describe in details how the function is resolved (name of function is bound to the function definition). For example:

    • what are the DMN / FEEL artifacts that the call can be bound to (e.g. DMN invocables visible in context)
    • how are the name clashes resolved (e.g. both a BKM and a buil-in function have the same signature)
    • how are the binding candidates built (e.g. apply all combinations of implicit conversions) and selected (e.g. exact match takes precedence)
  • Reported: DMN 1.2 — Wed, 18 Sep 2019 08:08 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Specify how functions are found in scope and argument types are checked

    See attached word doc

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Update the copyright section


New acknowledgments needed

  • Key: DMN13-195
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    The spec should keep track and acknowledge the work of all the people and companies involved.

  • Reported: DMN 1.2 — Tue, 15 Oct 2019 16:20 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Update acknowledgments section

    Update copyright list with all participating companies

  • Updated: Mon, 30 Mar 2020 19:50 GMT

New XML Namespace needed


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

No item definition for function definition

  • Key: DMN13-7
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    If a function definition is the value expression of an information item, then that information item should have an item definition that gives the type of the function definition. E.g., the type of a function of two numeric arguments that returns their sum should be something like function(number, number) returns number but we have no way to express such an item definition

  • Reported: DMN 1.0 — Thu, 6 Aug 2015 22:40 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    add FunctionItem to ItemDefinition MM, XSD, and spec text

    See attached word doc

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:
    • DMN12.xsd 22 kB (text/xml)
    • DMN13-7-v3.docx 86 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Need group artifact in DRD, metamodel, and XSD

  • Key: DMN13-6
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Group is an unfilled rectangle enclosing various elements in the DRD, with meaning defined by the modeler. It follows the usage defined by BPMN, an “artifact” with no operational semantics, simply an annotation of the model.

  • Reported: DMN 1.0 — Thu, 20 Aug 2015 00:13 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add Group to spec, MM, and XSD fashioned after BPMN

    See attached word doc

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

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

Disambiguation for Modulo / Remainder function

  • Key: DMN13-124
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The spec defines "modulo" FEEL built-in function as: "the remainder of the division of dividend by divisor"
    However, this might be subject to ambiguity in the case the Divisor or Dividend are negative, as also mentioned by Wikipedia page which list examples out of several programming languages and systems: https://en.wikipedia.org/wiki/Modulo_operation by saying that "When either a or n is negative, the naive definition breaks down and programming languages differ in how these values are defined".

    FEEL aims to be a Friendly Enough expression language, and especially thinking about DMN practitioners who might be used to Spreadsheet based systems might find misleading if the definition of the FEEL "modulo" gets bind to the Java (default) definition, the following table illustrate the difference:

    Dividend Divisor MOD() from Microsoft Excel, Google Sheets, LibreOffice Calc, Wolfram Alpha, etc. Java % or BigDecimal#remainder or other languages default
    10 4 2 2
    10 -4 -2 2
    -10 4 2 -2
    -10 -4 -2 -2

    or to other implementation languages where the definition of Modulo/Remainder is not explicit, or the default one is not consistent with Spreadsheet default one.

    It is proposed therefore to change the specification in 10.3.4.5 Numeric functions Table 70 for the FEEL "modulo" built-in function
    FROM: "Returns the remainder of the division of dividend by divisor."
    TO: "Returns the remainder of the division of dividend by divisor. In case either dividend or divisor is negative, the result has the same sign of the dividend."

    This would avoid ambiguity by making a clear definition of what should be the sign in case either of the operands are negative.
    This should make this consistent with Spreadsheet based system result of "MOD()" expression, which should address being Friendly Enough for DMN practitioners and DM analyst.
    This would not make the result the same as the default of Java % operator or BigDecimal#remainder, but Java based implementation/Vendor can trivially address the result to be compliant with the spec.

  • Reported: DMN 1.2b1 — Fri, 4 Jan 2019 18:34 GMT
  • Disposition: Duplicate or Merged — DMN 1.3
  • Disposition Summary:

    corrected in dmn13-125

    corrected in dmn13-125

  • Updated: Mon, 30 Mar 2020 19:50 GMT

instance of clarification

  • Key: DMN13-144
  • Status: closed  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    Table 56 describes the semantics of the instance of operator.

    It does not specify the expected result if the instance of expression is incorrect. For example, there is syntactic error, the type name cannot be found (e.g. typo or missing import) or if the type expression is incorrect (e.g. list<> or context<>).

  • Reported: DMN 1.2 — Tue, 12 Feb 2019 10:40 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Clarify type lattice L and tie 'instance of' semantics to L

    see attached word doc

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Make explicit reference to sample standard deviation

  • Key: DMN13-131
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The specification in chapter "10.3.4.4 List functions" for built-in function stddev does not explicit if it's meant to be population or sample standard deviation.
    However based on the example provided "stddev( 2, 4, 7, 5 ) = 2.0816659994661" would indicate it is meant to be the sample standard deviation --which is undefined for a single 1 sample value

    In order to be explicit, it is suggested to change the table entry as:

    Name(parameters) Parameter Domain Description Example
    stddev( list )
    stddev( n 1 , ..., n n )
    list is a list of number. n 1 ... n n are numbers. Returns the
    (sample) standard deviation of the list of numbers. If the list is empty,
    returns null. If the list contains only one number item, if n is a single number returns null.
    stddev( 2, 4, 7, 5 ) =
    2.0816659994661
    stddev( [ 47 ] ) = null
    stddev( 47 ) = null
    stddev( [ ] ) = null
  • Reported: DMN 1.2b1 — Fri, 18 Jan 2019 15:30 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Clarify the semantics of the stddev() function

    See revised text.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Wrong example in chapter "10.3.1.5"

  • Key: DMN13-133
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The specification in chapter "10.3.1.5 Contexts, Lists, Qualified Names, and Context Lists"

    presents the following example:

    [{a: [{b: 1}, {b: [2.1, 2.2]}]}, {a: [{b: 3}, {b: 4}, {b: 5}]}].a.b =
    [[{b: 1}, {b: [2.1, 2.2]}], [{b: 3}, {b: 4}, {b: 5}]].b =
    [[1, [2.1, 2.1]],[ 3, 4, 5]]
    

    However line 2 is wrong since DMNv1.2 dropped the equivalence that

    a=[a]
    

    therefore line 2 is problematic:

    [[{b: 1}, {b: [2.1, 2.2]}], [{b: 3}, {b: 4}, {b: 5}]].b =
     ^ b property is not available here
    

    as at the cursor position is not a context but two items of the root list.

    It is proposed to replace the example as follows:

    [{a: {b: 1}}, {a: {b: [2.1, 2.2]}}, {a: {b: 3}}, {a: {b: 4}}, {a: {b: 5}}].a.b =
    [{b: 1}, {b: [2.1, 2.2]}, {b: 3}, {b: 4}, {b: 5}].b =
    [1, [2.1, 2.1], 3, 4, 5]
    
  • Reported: DMN 1.2b1 — Sat, 26 Jan 2019 09:34 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Fix typo in the example on chapter 10.3.1.5

    See revised text.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Remove reference to SQL and PMML three value logic to eliminate misinterpretation

  • Key: DMN13-106
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The spec says: Three-valued logic (true, false, null) based on SQL and PMML
    This statement can lead to misinterpretation (given their understanding of the SQL and/or PMML three value logic) for nothing given that we define the semantic of the FEEL three Value logic clearly below.

  • Reported: DMN 1.2b1 — Tue, 20 Nov 2018 17:12 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Remove reference to SQL and PMML three value logic

    This reference to SQL and PMML is not needed and may lead to misinterpretation. Simply remove that reference.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Built-in functions only described in chapter "10.3.2.6 Context", and not described in the "10.3.4 Built-in functions"

  • Key: DMN13-126
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    In section "10.3.2.6 Context" two built-in functions are described: get value(), get entries().
    However these functions are not summarized later in section "10.3.4 Built-in functions"

    Describing all built-in functions in latter section "10.3.4 Built-in functions" is important to agree on the function parameters name.

    Agree on the function parameters name is important for invoking function and binding parameters by name, rather than positional.

    I propose to add a new section inside "10.3.4 Built-in functions", with the following:

    10.3.4.x Context function

    Table xx defines Context functions.

    Table xx: Semantics of Context functions

    Name(parameters) Parameter Domain Description Example
    get value(m, key) context, string select the value of the entry named key from context m
    get value({key1 : "value1"}, "key1") = "value1"
    get value({key1 : "value1"}, "unexistent-key") = null
    
    get entries(m) context produces a list of key,value pairs from a context m
    get entries({key1 : "value1"}) = [ { key : "key1", value : "value1" } ]
    get entries({key1 : "value1"})[key="key1"].value = "value1"
    
  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 15:42 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add get entries() and get value() functions to the function tables in chapter 10

    See revised text.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

"get value" and "get entries" function not in built-in functions list

  • Key: DMN13-122
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The above section mentions to two context-related functions "get value" and "get entries" that are not in the built in functions list. Are they meant to be there?

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:18 GMT
  • Disposition: Duplicate or Merged — DMN 1.3
  • Disposition Summary:

    duplicate of dmn13-126

    closed as duplicate

  • Updated: Mon, 30 Mar 2020 19:50 GMT

example shows literal inline function definition whereas grammar says function definitions only in boxed expressions.

  • Key: DMN13-121
  • Status: closed  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The spec example shows a function definition inline in a literal expression using sort(). My take on the FEEL grammar spec is that a function definition can only exist inside a boxed expression, not inside a literal expression. A function definition inside a literal expression whose body has names with spaces or additional characters makes the parsing of the entire expression before execution darn hard - we'll I haven't figured it out anyways.

    In the specific case of the sort function, the type of the 'list' parameter may only be known at execution time, and thus the types of the arguments to the 'precedes' function can only be known at execution time - that is, when actually executing the sort. And to execute a sort, you need to pass it its arguments - which means a parsed function definition. If that function definition has names with spaces, then parsing can't be done until the types are known - during the sort execution. A little bit chicken an egg.

    But, if I read the spec correctly, you should not be able to have a function definition inside a literal expression. In which case, it is parsed separately to its invoking function and the above is not an issue.

    As a note, the given example and some tests in the TCK (which I am not sure should be there) involve simple params or simple names and can be parsed. But the scenario above is not covered by the TCK.

    Happy to be guided otherwise. An all advice appreciated.

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:00 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    change grammar rule 2.h. in ch 10 to use expression instead of textual expression

    see revised text

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Minor typos in the FEEL grammar

  • Key: DMN13-120
  • Status: closed  
  • Source: Goldman Sachs ( Dr. Octavian Patrascoiu)
  • Summary:

    Typo in rule

    51. comparison =
    a.expression , ( "=" | "!=" | "<" | "<=" | ">" | ">=" ) , expression |
    b.expression , "between" , expression , "and" , expression |
    c.expression , "in" , positive unary test ;
    d.expression , "in" , " (", positive unary tests, ")" ;

    c. should have | at the end not ;

    We should replace non-terminal Boolean literal with boolean literal for consistency.

  • Reported: DMN 1.2b1 — Sat, 8 Dec 2018 19:36 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    fix minor typos in FEEL grammar rules

    see attachment

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

Example: Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses values inverted

  • Key: DMN13-98
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Fig 11.28 on page 179 of formal-19-01-05 shows a screenshot of Applicant Data.
    The values of Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses are inverted, if the end result of executing the model is for decision Routing = "ACCEPT".

    In other words; currently the PDF document display as:
    Applicant Data.Monthly.Income = 10000 (ten-thousands)
    Applicant Data.Monthly.Expenses = 100000 (a-hundred-thousands)
    but actually it should be:
    Applicant Data.Monthly.Income = 100000 (a-hundred-thousands)
    Applicant Data.Monthly.Expenses = 10000 (ten-thousands)
    if the decision Routing should evaluate to "ACCEPT".

    Also, check spelling of "Stragegy" in Fig 11.30

  • Reported: DMN 1.2b1 — Wed, 10 Oct 2018 13:13 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    *Replace erroneous figures *

    Monthly.Income and Monthly.Expenses corrected in figure 11.28
    Typo corrected in figure 11.30

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

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:

BigDecimal is not the only mapping of number to Java

  • Key: DMN13-1
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Clause 10.3.2.9 shows FEEL number values as mapped to XML decimal, integer, and double, but the only mapping to Java is to BigDecimal. The appropriate mapping to Java, like the appropriate mapping to XML, depends on the range and intent of the data element. BigDecimal is rarely used for anything but currency. Java int and double are much more likely to be appropriate for most data items. The mapping of number to Java should be just as flexible as the mapping to XML and PMML.

  • Reported: DMN 1.0 — Wed, 9 Jul 2014 21:23 GMT
  • Disposition: 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 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

italics and bold used for both typographic literal notation and FEEL semantic exposition

  • Key: DMN13-5
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    in typographic literals, italics are strings and bold italics are date literals, but in 10.3, italics are feel syntactic elements and bold are semantic elements. Better to have different notations

  • Reported: DMN 1.0 — Thu, 3 Sep 2015 15:58 GMT
  • Disposition: Deferred — DMN 1.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 notation for ItemDefinition

  • Key: DMN13-4
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The notion of a 'type' or ItemDefinition is in the metamodel (with some pending issues) and in the semantics and concepts, but little is in the notation. Thus, we have notation that allows you to execute an expression with actual arguments, but no notation to allow validation based on type information without actual values.

    We have most of the pieces, so it should not be difficult. E.g., individual values can be number, string, date and time, etc. We can allow numeric ranges using our unary tests, e.g. '>0', '[10..30)', etc. We can allow LOVs using "abc", "def", "ghi". These can be 'simple items', and we can also define structures using something similar to boxed contexts.

  • Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 GMT
  • Disposition: Deferred — DMN 1.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

Business Context links go both ways

  • Key: DMN13-3
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In XSD, business context pointers are duplicated in both directions. E.g. decisionOwner and decisionMaker point to organizationalUnit, which in turns has pointers back the other way. This duplication adds no new information, just potential for internal inconsistency. I suggest omitting one of these directions; the other one is easily extracted from the serialization by XPATH.

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
  • Disposition: Deferred — DMN 1.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

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:

XSD: global context

  • Key: DMN13-10
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    10.3.2.9.2 says "The global context is a context provided for convenience and 'pre-compilation'. Any number of expressions can be named and represented in a FEEL context m. The syntactic description m of this context can be evaluated once, that is, mapped to the FEEL domain as m, and then re-used to evaluate many expressions." For example, you might want to put a Relation used as a multi-dimensional constant in the global context. Or you might want to put a reusable function definition in the global context. Currently the xsd does not have globals. All expressions are bound to a specific drgElement, not global. The Import element probably needs to be modified to support this also.

  • Reported: DMN 1.0 — Sun, 31 May 2015 16:35 GMT
  • Disposition: Deferred — DMN 1.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

LiteralExpression and textual expression seem to mean the same thing, need to use the same term

  • Key: DMN13-9
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    literal expression is used in MM, and textual expression is used in grammar. Let's use 1 consistently, but check that they are really the same concept.

  • Reported: DMN 1.0 — Thu, 16 Jul 2015 16:30 GMT
  • Disposition: 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

Business Knowledge Model can have Information Requirements

  • Key: DMN13-8
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    FEEL function definitions are defined as lexical closures, which simply means that names in the function body must be in scope, and that scope includes the function parameters and, just like any other decision logic, it includes the information requirements and the knowledge requirements. This is very handy. For example, it allows the logic of a BKM to reference 100 Input Data items by name, without requiring that each invocation pass in 100 parameter bindings.

    In order for this to work, the BKM would model 100 Information Requirements on the 100 Input Data items, instead of modeling them as parameters. The boxed invocations would not have 100 rows of repetitive binding information. We must extend the MM and Table 2 to allow a BKM to have information requirements.

  • Reported: DMN 1.0 — Thu, 23 Jul 2015 23:30 GMT
  • Disposition: Deferred — DMN 1.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 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

Should encapsulated decisions of a decision service include output decisions?

  • Key: DMN13-22
  • Status: closed  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

    Figure 10 on page 25 with text "The encapsulated decisions are therefore

    {Decision 1, Decision 2}

    "

    Figure 11 on page 26 with text "The encapsulated decisions for this services are

    {Decision 1}

    ".

    Table 20 on page 56:

    • "outputDecisions: This attribute lists the instances of Decision required to be output by this DecisionService".
    • "encapsulatedDecisions: If present, this attribute lists the instances of Decision to be encapsulated in this DecisionService".

    For us it is unclear what decisions should be stored in the DMN model as encapsulated decisions. Must the output decisions also be included in the list of encapsulated decisions (as stated on page 25, 26)? Or does the list of encapsulated decisions only hold the decisions contained in the lower compartment of a decision service (as mentioned on 56 since encapsulatedDecisions seems to be optional)?

  • Reported: DMN 1.0 — Tue, 20 Mar 2018 14:49 GMT
  • Disposition: Deferred — DMN 1.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

Fix interchange of links to objects in BPMN/BMM

  • Key: DMN13-91
  • Status: closed  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • Summary:

    The current spec uses objects from BMM and BPMN. However it is not at all clear how links to these objects, and the objects at the end of the links, should be interchanged. Does the DMN file contain a snippet of BPMN? Should a separate BPMN file be generated and then referenced? If we are going to have these links then we need to show/explain how to interchange them both with tools that only support DMN (and so only have a few BPMN or BMM objects) and with those that support DMN/BPMN/BMM.

  • Reported: DMN 1.2 — Thu, 27 Sep 2018 01:07 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

    Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

Allow representation of black-box Decision Service

  • Key: DMN13-90
  • Status: closed  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • Summary:

    As DMN gets used to produce publicly available decision services we will need some way to represent a decision service that the modeler cannot see into. They know its a side-effect free, stateless decision service and know its signature so they can add a decision to their own model that is implemented by it but they don't know what decisions, BKMs, knowledge sources etc were used to produce it. There is currently no way to do this - a decision service can be shown collapsed but only if the model "knows" what the expanded version looks like. It feels like it would be useful to do so.

  • Reported: DMN 1.2 — Thu, 27 Sep 2018 01:04 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

    Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.

  • Updated: Mon, 30 Mar 2020 19:50 GMT

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:

add richer variety of DT examples in Ch 11

  • Key: DMN12-18
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    We lack examples of input expressions that are not simple names, input entries that reference variables, and output entries that are more than simple values.
    For example, could change fig 67, Eligibility column, from Eligibility||INELIGIBLE|ELIGIBLE to Eligibility=ELIGIBLE||false|true
    In Fig 71, add a context entry with name 'Adult' and value '18'. Change the entry <18 to <Adult.
    In Fig 83, rename to Adjusted Disposable Income. Add parameter list (Risk Category, Disposable Income). Change output entries to 0.6 * Disposable Income, 0.7 * Disposable Income, 0.8 * Disposable Income, change invocation entry in Fig 82 name to Adjusted Disposable Income and pass Disposable Income. Change Affordability calculation to 'if Adjusted Disposable Income > Required Monthly Installment'

  • Reported: DMN 1.0 — Tue, 7 Jul 2015 21:19 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    add more examples

    more suggested examples

  • Updated: Wed, 3 Oct 2018 14:17 GMT

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:

Typo error on Business Knowledge Model

  • Key: DMN12-9
  • Legacy Issue Number: 19843
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Here is a slight one (typo error) table 6.1, first row: an « e » is missing into « Knowledge ».

    N.B. It is more elegant to not cut a table on several pages, as it was done before, but it is another matter.

  • Reported: DMN 1.0 — Sun, 1 Nov 2015 04:00 GMT
  • Disposition: Closed; No Change — DMN 1.2
  • Disposition Summary:

    Unable to find the issue

    I do not see a table 6.1 in the spec, nor do I find a 'Knowledge' with missing 'e'.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

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

Add Diagram Interchange to DMN


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:

While BKMs enable re-use, the options for re-use are restricted to single pieces of decision logic


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

Useful to denote which info requirements are unconditional

  • Key: DMN12-14
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    A decision with logic: if x then y else z has an unconditional requirement on x but a conditional requirement on y and z. This is useful to represent in the notation (perhaps as a tick mark on the requirement arc in homage to BPM's unconditional gateway exit arc) and in the MM. It could prove very useful to implementors, who could use data-driven dataflow to activate the decision when x is available, but to produce y or z on demand.

  • Reported: DMN 1.0 — Thu, 13 Aug 2015 05:44 GMT
  • Disposition: Closed; No Change — DMN 1.2
  • Disposition Summary:

    withdrawn - no clear proposal or compelling use case

    withdrawn by submitter

  • 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

Consider date and time datatype in S-FEEL

  • Key: DMN12-5
  • Legacy Issue Number: 19755
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    a. In clause 9.2, para 5, first sentence, "date and time" should be in italics.
    b. Why is date and time type excluded from S-FEEL? This restriction makes XSD mapping problematic.

  • Reported: DMN 1.0 — Tue, 28 Apr 2015 04:00 GMT
  • Disposition: Closed; No Change — DMN 1.2
  • Disposition Summary:

    No SFEEL changes

    Not enough usage of SFEEL to justify change at this time.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

cannot interchange input data style

  • Key: DMN12-1
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    We have 2 notations for input data

    1. an oval shape

    2. the name of input data in the requiring decision (so-called Listed Input Data)

    As far as I see, there is nothing in the MM to distinguish these cases,

    so there is no way to interchange the intended notation.

    Proposed: add a new attribute to Decision named listedInputData of type boolean.

  • Reported: DMN 1.0b1 — Sat, 9 Nov 2013 00:33 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    DI supports interchange of listed input data on diagrams

    this issue subsumed and resolved by diagram interchange (DMN12-20)

  • 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

definition of expression in glossary omits CL3 expressions

  • Key: DMN12-12
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The glossary is not only for CL2. CL3 adds contexts, relations, functions, etc. to the repertoire of boxed expressions

  • Reported: DMN 1.0 — Fri, 21 Aug 2015 19:56 GMT
  • Disposition: Resolved — DMN 1.2
  • Disposition Summary:

    enumerate all the expressions

    see revised text.

  • 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

alternative indication of reusable logic in DRD

  • Key: DMN12-6
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In the metamodel/XSD, decision logic is contained in a decision element, hence not reusable. To reference reusable decision logic, decision invokes BKM, which is reusable. The semantics are clear, but representation of the decision and BKM as separate graphical elements in DRD is visually inefficient. It creates unnecessary clutter in the DRD (Fig 63 is a prime example). BPMN solved this problem in a better way, and I suggest DMN should allow the same. In BPMN a subprocess definition is embedded in the parent process so to reference reusable subprocess, it uses a call activity. The call activity shape is same as subprocess except it has a thick border style. The diagram does not contain both subprocess and call activity, just one or the other. I would like to propose that a decision shape in DRD with a thick border be used to mean the decision invokes a BKM (with name generated from the decision name). No metamodel or schema changes required; this is merely alternative graphical notation. In a DMN tool, typically clicking on the decision will hyperlink to the decision logic (DT or literal expression), whether that logic is embedded in the decision or reusable. This distinction is mostly important to programmers, not modelers, so should not unnecessarily complicate the diagram.

  • Reported: DMN 1.0 — Tue, 5 May 2015 17:58 GMT
  • Disposition: Duplicate or Merged — DMN 1.2
  • Disposition Summary:

    subsumed by invocable decision service

    no longer an issue after invocable decision service feature added.

  • 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

Wrong DecisionTable class diagram (metamodel)

  • Key: DMN12-8
  • Legacy Issue Number: 19844
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The figure 8.18 is NOT the figure of the DecisionTable class diagram (i.e. metamodel).
    This diagram was good into the previous beta versions of DMN specification.
    This "wrong" diagram was already used as figure 6.8 on page 32 (Decision class diagram i.e. metamodel).

  • Reported: DMN 1.0 — Sun, 1 Nov 2015 04:00 GMT
  • Disposition: Closed; No Change — DMN 1.2
  • Disposition Summary:

    The issue does not exist in the current specification

    The MM, now Figure 51, seems fine in OMG formal/2016-06-01

  • Updated: Wed, 3 Oct 2018 14:17 GMT

DMN XSD 1.0 invalid path

  • Key: DMN12-22
  • Status: closed   Implementation work Blocked
  • Source: UNESP Sao Paulo State University Brazil ( Fernando Nogueira)
  • Summary:

    I am developing an application that imports DMN files generated by http://demo.bpmn.io/dmn, in order to get some information about the descision tables.

    But, when I try to use the XSD schema to validate the DMN file, I get some errors, for example:

    unexpected element (uri:"http://www.omg.org/spec/DMN/20151101/dmn11.xsd", local:"definitions")

    Apparently, the path is no longer available. Instead, the OMG site is using http://www.omg.org/spec/DMN/20141115/dmn.xsd

  • Reported: DMN 1.0 — Wed, 20 Jan 2016 16:26 GMT
  • Disposition: Closed; No Change — DMN 1.2
  • Disposition Summary:

    this appears to be a tool issue. The spec is correct.

    see further details in the issue.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Business Knowledge Model can have Information Requirements

  • Key: DMN12-16
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    FEEL function definitions are defined as lexical closures, which simply means that names in the function body must be in scope, and that scope includes the function parameters and, just like any other decision logic, it includes the information requirements and the knowledge requirements. This is very handy. For example, it allows the logic of a BKM to reference 100 Input Data items by name, without requiring that each invocation pass in 100 parameter bindings.

    In order for this to work, the BKM would model 100 Information Requirements on the 100 Input Data items, instead of modeling them as parameters. The boxed invocations would not have 100 rows of repetitive binding information. We must extend the MM and Table 2 to allow a BKM to have information requirements.

  • Reported: DMN 1.0 — Thu, 23 Jul 2015 23:30 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    No agreement about whether this is a good or bad idea

    Defer until we can agree to resolve or close.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

No item definition for function definition

  • Key: DMN12-15
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    If a function definition is the value expression of an information item, then that information item should have an item definition that gives the type of the function definition. E.g., the type of a function of two numeric arguments that returns their sum should be something like function(number, number) returns number but we have no way to express such an item definition

  • Reported: DMN 1.0 — Thu, 6 Aug 2015 22:40 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    needed, but out of time

    Should enhance item definition so it can model function types because that is the type of a BKM's logic

  • Updated: Wed, 3 Oct 2018 14:17 GMT

LiteralExpression and textual expression seem to mean the same thing, need to use the same term

  • Key: DMN12-17
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    literal expression is used in MM, and textual expression is used in grammar. Let's use 1 consistently, but check that they are really the same concept.

  • Reported: DMN 1.0 — Thu, 16 Jul 2015 16:30 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    no proposal but possibly still an issue, defer.

    Literal expression v. textual expression may be a distinction without a difference.

  • 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

Business Context links go both ways

  • Key: DMN12-4
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In XSD, business context pointers are duplicated in both directions. E.g. decisionOwner and decisionMaker point to organizationalUnit, which in turns has pointers back the other way. This duplication adds no new information, just potential for internal inconsistency. I suggest omitting one of these directions; the other one is easily extracted from the serialization by XPATH.

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    cannot change schema for compatibility reasons

    reconsider in 2.0?

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Examples

  • Key: DMN12-3
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    DMN 1.1 should provide examples of all types of decision model allowed by the standard, both graphically (DRD and decision table, where appropriate) and XML serialization. Currently missing:
    1. decision tables with an expression (more than a name) in inputExpression and outputExpression.
    2. decision tables with inputEntry or outputEntry referencing a "name" as defined by S-FEEL, i.e. not just a literal.
    3. DRD and decision table involving what Vanthienen calls "action subtables". All existing examples are "condition subtables".
    4. Serialization of crosstab format tables.
    5. Representation of literal values vs names in serialization.
    6. Representation of PMML and FEEL in the serialization.

  • Reported: DMN 1.0 — Sun, 12 Apr 2015 15:39 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    Need comprehensive set of examples, defer.

    Perhaps the next task force can extract some examples from some test cases and add them to the spec.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

BigDecimal is not the only mapping of number to Java

  • Key: DMN12-2
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Clause 10.3.2.9 shows FEEL number values as mapped to XML decimal, integer, and double, but the only mapping to Java is to BigDecimal. The appropriate mapping to Java, like the appropriate mapping to XML, depends on the range and intent of the data element. BigDecimal is rarely used for anything but currency. Java int and double are much more likely to be appropriate for most data items. The mapping of number to Java should be just as flexible as the mapping to XML and PMML.

  • Reported: DMN 1.0 — Wed, 9 Jul 2014 21:23 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    still no proposals in 4 years, defer.

    FEEL chose the simplicity of a single numeric type. Possibly some vendors have extensions, but none has volunteered to make a detailed proposal. There are many numeric builtins and operators; a complete proposal would be somewhat tedious.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

Need group artifact in DRD, metamodel, and XSD

  • Key: DMN12-13
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Group is an unfilled rectangle enclosing various elements in the DRD, with meaning defined by the modeler. It follows the usage defined by BPMN, an “artifact” with no operational semantics, simply an annotation of the model.

  • Reported: DMN 1.0 — Thu, 20 Aug 2015 00:13 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    Under discussion but no proposal, defer.

    See issue comments.

  • Updated: Wed, 3 Oct 2018 14:17 GMT
  • Attachments:

No notation for ItemDefinition

  • Key: DMN12-7
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The notion of a 'type' or ItemDefinition is in the metamodel (with some pending issues) and in the semantics and concepts, but little is in the notation. Thus, we have notation that allows you to execute an expression with actual arguments, but no notation to allow validation based on type information without actual values.

    We have most of the pieces, so it should not be difficult. E.g., individual values can be number, string, date and time, etc. We can allow numeric ranges using our unary tests, e.g. '>0', '[10..30)', etc. We can allow LOVs using "abc", "def", "ghi". These can be 'simple items', and we can also define structures using something similar to boxed contexts.

  • Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    no proposal for this missing feature, defer

    Still seems useful.

  • Updated: Wed, 3 Oct 2018 14:17 GMT

italics and bold used for both typographic literal notation and FEEL semantic exposition

  • Key: DMN12-11
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    in typographic literals, italics are strings and bold italics are date literals, but in 10.3, italics are feel syntactic elements and bold are semantic elements. Better to have different notations

  • Reported: DMN 1.0 — Thu, 3 Sep 2015 15:58 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    editorial only, can defer

    we should identify some typographical conventions and use them consistently.

  • 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

XSD: global context

  • Key: DMN12-19
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    10.3.2.9.2 says "The global context is a context provided for convenience and 'pre-compilation'. Any number of expressions can be named and represented in a FEEL context m. The syntactic description m of this context can be evaluated once, that is, mapped to the FEEL domain as m, and then re-used to evaluate many expressions." For example, you might want to put a Relation used as a multi-dimensional constant in the global context. Or you might want to put a reusable function definition in the global context. Currently the xsd does not have globals. All expressions are bound to a specific drgElement, not global. The Import element probably needs to be modified to support this also.

  • Reported: DMN 1.0 — Sun, 31 May 2015 16:35 GMT
  • Disposition: Deferred — DMN 1.2
  • Disposition Summary:

    did not write proposal to remove global context, defer.

    Probably global context can/should be removed, but we did not work out the details.

  • 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


extra level of indirection in decision table serialization is undesirable

  • Key: DMN11-81
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The input and output entries in a decision table are expressions. The expressions are serialized as part of the rule 'clause', with an ID. In the rules, the expressions are represented by IDREF. This level of indirection is undesirable for many reasons:
    1. the expressions are small text strings, typically no bigger than an ID
    2. copy/paste of rules across decision tables won't work (IDs are different)
    3. diff of decision tables is complicated, due to indirection
    4. there is no level of indirection in the notation - the rules appear to contain the expressions, not a reference to them.
    5. complicates JSON serialization
    Proposed: In Figure 44, move Expression ownership from Clause to DecisionRule, and follow logical implications in text and xsd.

  • Reported: DMN 1.0 — Thu, 25 Jun 2015 06:23 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    remove indirection, split Expression into LiteralExpression and UnaryTests

    DecisionRules are ordered in a DecisionTable. By also ordering the inputs and the outputs (requires splitting Clause into InputClause and OutputClause, we can move the inputEntries and outputEntries under DecisionRule and avoid all IDREFs within a decision table, significantly simplifying serialization. Also, we combine a proposal for DMN11-84, which is merged with this issue.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Define decision service

  • Key: DMN11-45
  • Legacy Issue Number: 19754
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    Allow DMN to specify and interchange definitions of decision services, along the lines proposed in Annex B.

  • Reported: DMN 1.0 — Tue, 28 Apr 2015 04:00 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Definition, notation and examples for Decision Service

    Complete proposal in the attached document

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

DecisionService has no defined execution semantics, and decision model semantics in 10.4 is hard to understand

  • Key: DMN11-176
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Now that we have decision services, this is a much better and simpler feature for which to define execution semantics. We can simplify and improve the usefulness of 10.4.

  • Reported: DMN 1.0 — Fri, 30 Oct 2015 16:20 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    replace 10.4 with Execution Semantics of Decision Services

    This proposal depends on adoption of DMN11-143. I think we should specify the execution semantics of decision services. This can replace 10.4, which is the execution semantics of DRGs, which is problematic because the InputData doesn't have much meaning except as the parameter of a decision service. No MM or XSD changes.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

use refs in XSD only to substitution groups

  • Key: DMN11-164
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    use <element name=xx, type=tYY/> instead of <element ref=zz/>
    This will more consistently name subelements as MM attributed names, not as MM class names. This is a stylistic issue only.

  • Reported: DMN 1.0 — Tue, 27 Oct 2015 17:21 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Consistently use MM names in XSD

    Change XSD to use attribute names as defined in meta model aggregations.
    Remove references to global elements where no polymorphism is needed.

    In particular the changes are:

    1. remove unneeded global elements and refs
    2. Revert back to ref="Import" due to polymorphism with ImportedValues
    3. Remove unused element text
    4. Use attribute names from meta model
    5. Consistently prefix type names with t
    (This is only XSD cosmetics and does not affect the actual element names in instance documents)
    6. Consistently name elements with MM class name with lower-case first letter
    (This last change might be a little controversial, as it affects many element names. However, the previous changes result in a mixture of upper and lower case element name, which certainly will be confusing for tool vendors. Especially, since we see in the OMG BPMN Model Interchange Working Group, that many tool vendors are not performing schema validations, we might end up with subtle differences in import/export that prevent interchange. Also when developing tools to analyse or transform DMN files using XSLT or XPath, predictable element names will safe a lot of hassle.)
    7. imported values can only be used in literal expression.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

DMN needs to provide a standard way for vendors to serialize extensions (Vendor Extensions)

  • Key: DMN11-155
  • Status: closed  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    DMN nees to provide a standard way for vendors to serialize extensions (Vendor Extensions). It is proposed that a schema resembling what was done in BPMN and CMMN be used.

    Why DMN should be extensible

    The extension mechanism allows adding Custom Metadata to models in a way that it MAY be interchanged between vendors. Concretely this means that it is possible to add custom attributes and elements in a custom namespace to the XML interchange format.

    Example of a custom attribute

    <DecisionTable id="table1" custom:audit="true" xmlns:custom="http://custom.org/auditing" ...>
    

    Example of a custom element

    <DecisionTable id="table1" ...>
      ...
      <extensionElements>
      <custom:audit xmlns:custom="http://custom.org/auditing">
        <custom:audit-level>full</custom:audit-level>
        <custom:retention>unlimited</custom:retention-level>
      </custom:audit>
      </extensionElements>
      ...
    </DecisionTable ...>
    

    Vendors need to be able to add custom Metadata

    Vendors need to be able to decorate the model with additional metadata. Vendors may implement additional usecases which the standard as such does not address like historization, reporting, fine-grained editing authorizations amd restrictions, ...
    Having the possibility to put this directly into the interchange format allows vendors to roundtrip models. If all vendors participating in the roundtrip re-export the other vendor's extensions than they are not lost during roundtrip which leads to a better inter-operatbility experience for the user.

    Users need to be able to add custom Metadata

    The possibility to extend the model with custom metadata has also proven to be vital to camunda users and customers in the past.
    Many users extend the model with their custom attributes and elements to be able to implement custom extensions.
    Some have custom metadata for their execution environment others for auditing and reporting.
    It is very important at users are able to put custom metadata into the xml file.

    FAQ

    Is BPMN's extension mechanism perfect?

    Probably not. At the XML level it works extremely well. At the Meta Model level it could certainly be improved.
    But the question is whether the practical advantages of a "slightly better approach" would outweigh the advantages of consistency among these standards.

    Does that mean that Vendors can just ignore the Standard?

    No. In order to be compliant, vendors need to implement the standard in the way mandated by the standard.
    If they use custom extensions for realizing non-compliant behavior then they are non-compliant.

    Do tools need to understand the extensions created by other vendors?

    No. Tools do not need to understand extensions created by other vendors. What's more, the specification text explicitly states that tools do not event need to round-trip extension elements by other vendors while still being compliant. There is also no compliance level at which a tool is required to support this. A tool is fully compliant if it is not able to round-trip extension elements.

    Has this actually been successful in BPMN?

    Yes. Extension mechanisms are heavily used and there is ample empiric evidence of this being a successful concept. To see it in action have a look at the demos and test cases of the BPMN Model Interchange Working Group (MIWG) at the OMG.

    For comparison see also the CMMN 1.1 proposal CR-20.

  • Reported: DMN 1.0 — Thu, 22 Oct 2015 13:33 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Add new extension capability to DMN as per that of BPMN and CMMN

    Based on the extension capabilities of BPMN and CMMN the following changes need to be done:

    1. Add two rows to table 3
    2. Add a new figure of the metamodel showing the relation between DMNElement and the extension mechanism in section 6.3
    3. Figure 15 - DMNElement class diagram needs to be updated with ExtensionElements and ExtensionAttribute depiction.
    4. A complete new section 6.3.14 Extensibility needs to be added. This will have a ripple effect on table and figure numbering. Figure of the metamodel should be inserted after the first paragraph of section 6.3.14, in the metamodel we need to add the two classes described
    5. Some changes needed to DMN.xsd, which already contains this mechanism
  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

DMN XSD, MM, Attribute/Association Tables, and spec text are not consistent

  • Key: DMN11-146
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    XSD must use names derived in a consistent way from MM names. XSD types should be used everywhere. Spec text descriptions must agree in name and concept with the MM. XSD must use containment and references in the same way as the MM. For example, DMN11-81 removes references and uses containment for the entries in a DT. But XSD still has lingering ID/IDREFs that must be removed and aligned with current MM.

  • Reported: DMN 1.0 — Thu, 8 Oct 2015 16:10 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Align XSD, MM and spec text as described

    Make following changes to XSD:
    1. Relation.column in XSD should have type tInformationItem, not tContextEntry
    2. Invocation.calledFunction is missing in the XSD
    3. KnowledgeSource.type: change anyType to string
    4. tInvocation/@calledFunction is of type="xsd:string", but in MM it aggregates an Expression => Change XSD to reference abstract element Expression.

    Make following changes to MM:
    1. MM ImportedValues does not contain importedElement, but XSD does. Add attribute to MM
    2. Collapse the classes that are not essential in each diagram, e.g. DMNElement and NamedElement should show attributes only in the DMN Element diagram
    3. Use xsd types (instead of String) for ID, anyURI, QName
    4. rename OrganisationalUnit into OrganizationUnit in MM and spec text.
    5. name association from Decision to InformationRequirement "informationRequirement"
    6. add attribute importedElement : String[1] to ImportedValues in MM
    7. remove attribute "name" from InformationItem in MM
    8. Make NamedElement abstract in MM and XSD

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

8.3.3. still speaks of condition and conclusion - supposedly removed by DMN11-81

  • Key: DMN11-145
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Need to reword to use new MM associations

  • Reported: DMN 1.0 — Thu, 8 Oct 2015 15:59 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    spec text update to decision rule MM in 8.3.3

    This issue describes the changes to Decision Rule meta-model from referencing conditions and conclusions to embedding them.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

DMN 1.1 Beta documents

  • Key: DMN11-122
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    We are required to vote on the beta 1.1 documents, submitted with this report. See "Deliverables" section of this report.

  • Reported: DMN 1.0 — Thu, 27 Aug 2015 00:16 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    submit attached beta documents to OMG

    OMG requires a vote on beta documents.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Reference to BMM::Objective, BPMN::Process and BPMN::Task in XMI

  • Key: DMN11-12
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    The reference to classes BMM::Objective, BPMN::Process and BPMN::Task does not seem to work in the metamodel XMI file

  • Reported: DMN 1.0 — Tue, 29 Jul 2014 12:51 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    unable to find more information about this issue

    Did not hear back from Pete and nobody on RTF is an XMI expert. Not even sure if this still applies.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

dmn.xsd and dmn3.xsd should be merged and list of machine readable files corrected

  • Key: DMN11-91
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    issue 60 has identified 2 critical but easy to fix problems with the beta2 xsds. An even simpler fix is to combine the 2 xsds. Separate xsds invites the problems, and it has been reported that popular XML tools don't like the 2 xsds because it is the included xsd that has the document root. Also, DMN11-89 proposes to use FunctionDefinition (now in dmn3) to consistently serialize all BKM logic.

  • Reported: DMN 1.0 — Mon, 6 Jul 2015 20:55 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Merge contents of dmn3.xsd into dmn.xsd

    Merge contents of dmn3.xsd into dmn.xsd and delete dmn3.xsd.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Remove parameters from BKM MM - these belong at logic level

  • Key: DMN11-89
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The BKM MM defines parameters but has no notation for them. Meanwhile, the FunctionDefinition also defines parameters that duplicate the BKMs. Also, 10.2.1.7 says a BKM's logic must be a FunctionDefinition or a DT, but Table 11 syas a BKM's logic msut be the BODY of the function it defines. To straighten out thsi mess, I propose
    1. remove params from BKM MM
    2. require BKM to contain a FunctionDefiniition, so that the params will always be defined, and always at the decision logic level
    3. allow FunctionDefinition whose body is a DT with simple inputExpressions that reference all parameters, and only parameters, in order, to be denoted using the DT only

  • Reported: DMN 1.0 — Thu, 2 Jul 2015 18:48 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    BKM value expression is a function definition

    change BKM metamodel and XSD to associate BKM to FunctionDefinition instead of separate parameters and body

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

'In DMN 1.0' now not only tedious but wrong

  • Key: DMN11-64
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    There are many occurrences of the phrase 'In DMN 1.0'. Now that we are writing DMN 1.1, this phrase is no longer simply tedious and redundant, but now it is also wrong. All occurrences should simply be deleted. And, all occurrences of 'In DMN' should be deleted. They are redundant. This is the DMN specification! Everything described is by default 'in DMN'!

  • Reported: DMN 1.0 — Thu, 4 Jun 2015 05:18 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Remove superfluous refs to DMN and all refs to DMN 1.0

    Remove all unnecessary use of "In DMN..."
    All remaining refs to DMN 1.0 shoul dbe updated to 1.1

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Add association connector (artifact) with text label to represent conditional decision

  • Key: DMN11-47
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In the chapter 11 example, Fig 63 contains an information requirement connector linking Adjudication to Routing. But in reality Routing is not an input to Adjudication. What is meant is that Adjudication is only performed if Routing has certain output value. That relationship is what Vanthienen calls an action subtable, whereas information requirement reflects a condition subtable relationship. Still it is useful to depict such relationships in DRD. I suggest adding a new connector type, association - an artifact as meant by BPMN, i.e. no operational semantics just annotation - to reflect it. A text label could indicate a particular output value that enables the dependent decision.

  • Reported: DMN 1.0 — Tue, 28 Apr 2015 21:20 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    Close - no change required

    Consensus is not to add new type of information requirement connector.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Need for annotations and comments in DRD


Need to clarify which DMNElements must and must not have names

  • Key: DMN11-92
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In the MM, Fig 15, all classes inherit the optional name attribute. Thus, any DMNElement may or may not have a name. What is closer to the truth, is that some DMNElements MUST have a name, and others MUST NOT. Attached is proposed MM that splits the elements into the named and unnamed. There will be numerous text changes, especially to explain that decision tables, being expressions, do not have names. The apparent 'names' of expressions like DTs are really the name of the Information Item that has said expression as its valueExpression. It is dangerous (misleading) to supply a name for an expression, because it may appear that one could refer to the named expression's value by that name. But you cannot. You can only refer to an Information Item by name in an expression.

  • Reported: DMN 1.0 — Tue, 7 Jul 2015 20:01 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    define NamedElement subclass of DMNElement

    Revised text, MM figures, and XSD (github links)

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

XSD: modify Import in tLiteralExpression

  • Key: DMN11-73
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In XSD, top-level element Import is used to make top-level elements in external DMN, XSD, and possibly other types of files visible to the decision model. Import also is part of tLiteralExpression as a way to import value expressions, but it needs additional information. Propose to give this element a different name and type:
    In tLiteralExpression, replace Import with importedValues, type tImportedValues. Add tImportedValues as follows:
    <xsd:complexType name="tImportedValues">
    <xsd:complexContent>
    <xsd:extension base="tImport">
    <xsd:sequence>
    <xsd:element name="importedElement">
    <xsd:complexType>
    <xsd:simpleContent>
    <xsd:extension base="xsd:string">
    <xsd:attribute name="expressionLanguage" type="xsd:anyURI"/>
    </xsd:extension>
    </xsd:simpleContent>
    </xsd:complexType>
    </xsd:element>
    </xsd:sequence>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>

  • Reported: DMN 1.0 — Thu, 11 Jun 2015 18:20 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    replace Import in tLiteralExpression with importedValues, new type

    Revise spec, MM Fig 26, and XSD as directed.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

inputVariable and itemDefinition are redundant in Expression metamodel

  • Key: DMN11-69
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    These are redundant. InputVariable is a pointer to a variable definition, but any expression MUST only reference a variable with unique name in scope, so the pointer is redundant. An expression referencing a name not defined uniquely in scope is an error.

    Similarly, in tExpression, itemDefinition (a pointer to ItemDefinition representing the expression's output datatype) is redundant. The Decision or BKM element also has OutputDefinition, pointer to ItemDefinition that defines the datatype of the output expression. Any variable referenced by an any literal expression also already has a datatype defined by InformationItem.

  • Reported: DMN 1.0 — Thu, 11 Jun 2015 17:42 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    move inputVariable and itemDefinition from Expression metamodel to InputData and Decision (and correct XSD and explanatory text)

    Revise spec, MM, and XSD as indicated.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Decision table default output

  • Key: DMN11-58
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    This issue also relates to isComplete.
    Level 3 decision tables may specify a default output entry to be selected if no rules match. I dont believe this is allowed for level 2. In any case, the default output entry is missing from both boxed expression and xsd for decision table, possibly missing from metamodel also.

  • Reported: DMN 1.0 — Sun, 17 May 2015 16:14 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Add decision table default output

    Add attribute defaultOutputEntry of type tLiteralExpression

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

XSD itemDefinition/typeRef and typeDefinition are underspecified and incorrect

  • Key: DMN11-54
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    itemDefinition is referenced to a base type defined by either a typeDefinition or typeRef. 7.3.2 says typeDefinition is "a String that defines the data structure", but it simply names a built-in type, does not define a structure. It also says typeRef is "a String that references a built-in data type... or a data structure defined at the top level in an external document", but those statements are incorrect as well. Built-in types are named by typeDefinition, typeRef is not String. Structured types are defined by itemComponent and referenced by typeRef, usually NOT in an external document. So this text is completely wrong. This issue also affects how external references are defined, via namespace prefix or filename, via ID or element name. Referenced typed by DMNElementReference are ambiguous and inadequate to cover the range of external references required.

  • Reported: DMN 1.0 — Fri, 15 May 2015 16:23 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    simplify and correct MM and XSD for ItemDefinition

    Proposal is to Merge and close DMN11-25, 56, 57, 71.

    The latest MM diagram (attached) shows ItemDefinition containing itemComponents, which are also tItemDefinition. It also shows ItemDefinition has attribute typeRef and typeDefinition. It is better to have a consistent referencing scheme via typeRef, so typeDefinition should be removed from the MM. Otherwise, the MM is correct, but the XSD is not consistent with this.

    The corrected XSD deletes tItemComponent and defines itemComponent as tItemDefinition. This makes ItemComponent recursive, which resolves and closes DMN11-56 and DMN11-71.

    Also, to make ItemDefinition consistent with DMN11-67, allowedValue is renamed allowedValues, type tUnaryTests, maxOccurs=1.

    It is important that types be referenced consistently via typeRef or itemDefinition, whether the type is:

    (1) a base type (without restriction) in the ItemDefinition's typeLanguage; (2) a custom type (including base types with allowed values) defined in the current Definitions; (3) a custom type defined in an imported DMN model; or (4) a type defined in an imported XSD (or WSDL or other type language). Normally types have names unique in their namespace, and outside of DMN they do not have ids. Therefore tDMNElementReference, a pointer to id, will not work; the best way to reference types is by standard QName. This also resolves 11-25, since now Definitions/@namespace has a purpose.

    A base type in the specified typeLanguage should not require ItemDefinition, nor should an imported type. ItemDefinition is required only for custom types defined in the current document.

    QName is namespace-prefixed pointer to either ItemDefinition/@name (or, for imported XSD type, to xsd:simpleType/@name or xsd:complexType/@name). The prefix must be declared in DMN via xsd:schema/@xmlns:[prefix]="[namespace URI]". This means references to FEEL base types must use prefix for the FEEL namespace, just as references to XSD base types must use prefix for the XSD namespace. For imported DMN documents, the prefix must reference the Definitions/@namespace attribute of the import.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

XSD; modify tItemDefinition by changing tItemComponent

  • Key: DMN11-56
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    ItemDefinition defines the datatype of each variable used in DMN expression. As currently defined, it "works" for FEEL base types, although inefficiently (since it has both @name and typeDefinition, two strings that both name the type). It "sort of works" for imported XSD complex types, as long as you ensure the FEEL elements have valid XML element names (e.g. no spaces, etc.) In that case ItemDefinition/@name names the FEEL type and typeRef is a QName pointer to complexType defined in imported XSD. In the general case, for FEEL complex types defined inside the DMN model, it doesn't work very well.

    It is clumsy for defining data structures more than 2 levels deep. ItemDefinition may contain a list of itemComponents, each with a name and pointer to another ItemDefinition. So to define a type that is 3 levels deep, you would have to define one or more 2-level ItemDefinitions, and then the top-level ItemDefinition would use those as itemComponents and point to their ItemDefinitions. Also, the current schema is missing cardinality information (in xsd, @minOccurs and @maxOccurs), important in the definition of a complex type:

    I propose a change to tItemDefinition by changing tItemComponent. Child itemComponents are now contained in a parent itemComponent, not referenced, just like a complexType in XSD. I would like to make ItemDefinition/@name a required attribute, since it names the type, but am unable to do this without making it required for all tDMNElement. So the spec should just say, even though optional in schema, ItemDefinition/@name is required.

    See attached doc with diagram. I will provide also revised dmn.xsd.

  • Reported: DMN 1.0 — Sat, 16 May 2015 17:56 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    no longer relevant

    no longer relevant

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Question on boxed invocation format

  • Key: DMN11-50
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In Chapter 11 examples, most boxed invocations - Fig 76, 78, 80, 81 - have format in which the "tab" names the invoking element and the top line of the box, above the parameter list, names the invoked element. Fig 82 is different. The tab names the invoking element, the top line of the box lists the parameters of the invoking element, then the parameter list, and the bottom row names the invoked element.

    That seems inconsistent and a mistake.

  • Reported: DMN 1.0 — Mon, 4 May 2015 21:41 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    issue seeking clarification only

    issue was clarified in comments

  • Updated: Tue, 29 Mar 2016 15:07 GMT

typos for DMN 1.1 RTF final report

  • Key: DMN11-175
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    All reviewers, please log minor typos here.

  • Reported: DMN 1.0 — Thu, 29 Oct 2015 17:26 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    errata found in review of V4 of clean spec

    see revised text. Some of these are clearly more than typos, more like omission of some editing instructions.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Information item name on DTs not correct in some figures

  • Key: DMN11-166
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    The top box of a DT should display the Information Item determined by the table, i.e. the name of the decision or BKM for which the DT is the logic.

    In Figs 32, 34 and 36, "table name" should read "information item".

    We should also clarify by adding to the first bullet point in 8.1 "Usually this will be the name of the Decision or Business Knowledge Model for which the Decision Table provides the decision logic."

  • Reported: DMN 1.0 — Thu, 29 Oct 2015 08:57 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Correct figs 29, 31 & 33 and clarify DT information item

    Correct figs 29, 31 & 33 (32, 34 & 36 in v3) by replacing "table name" with "information item name"

    Clarify the typical use of this box in the Introduction to Decision Tables (8.1)

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Decision table MM and xsd need output label attribute

  • Key: DMN11-139
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Decision table notation has an output name (renamed output label by DMN11-43) but there is no place in the MM for this label. Cannot use output clause name because this is the name of the component in a multiple component output.

  • Reported: DMN 1.0 — Wed, 30 Sep 2015 23:43 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    add outputLabel attribute to DecisionTable MM (and xsd)

    see attached MM

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Need InformationItem for the FunctionDefinition of a BKM

  • Key: DMN11-137
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    At the decision logic level, one does not 'invoke' a BKM; rather, one invokes the FunctionDefinition that is contained in the BKM. How does one refer to the FunctionDefinition by name? Logic refers to InformationItems by name, it does not refer to the DRGElements directly by name. Therefore, a BKM should contain an InformationItem of the same name whose value expression is the FunctionDefinition contained in the BKM.

  • Reported: DMN 1.0 — Thu, 24 Sep 2015 21:58 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Add InformationItem child to BKM

    see attached MM figure. Need git pointer to XSD.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

would like to annotate Expression with typeRef

  • Key: DMN11-127
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    when we removed the redundant variable references from Expression, we also removed the redundant InformationItem (now typeRef) reference. The result type of an expression is redundant because you can always compute the result type from the input types, and a good tool will have to perform this computation anyway in order to verify that the redundant value is correct. However, simple tools may benefit from a declaration of the expected type of an expression, and the benefit may outweigh the drawbacks of redundancy, hence the issue.

  • Reported: DMN 1.0 — Fri, 28 Aug 2015 23:33 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    add typeRef attribute to Expression, and derived association to ItemDefinition

    Affects MM, XSD, and spec text

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Decision, InputData, and other containers of InformationItem do not ref ItemDefinition directly

  • Key: DMN11-123
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The InformationItem has a typeRef, which may ref ItemDefinition (derived association)

  • Reported: DMN 1.0 — Thu, 27 Aug 2015 15:51 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    replace associations to InformationItem with typeRef (datatype) and derived associations

    This corrects DMN11-86, which is already on ballot 6. Also, replace attached figures, relevant changes highlighted.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Knowledge Source metamodel diagram missing

  • Key: DMN11-120
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    section 6.3.10 describes the KnowledgeSource metamodel but has no diagram. KnowledgeSource and AuthorityRequirement is shown in figs 17,19 in a confusing manner and need correction.

  • Reported: DMN 1.0 — Mon, 24 Aug 2015 22:50 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Add Knowledge Source diagram and clean up KnowledgeSource in Figs 17 and 19

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Definitions/@namespace has no purpose

  • Key: DMN11-25
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    p38 says "An instance of Definitions has a namespace, which is a String. The namespace identifies the default target namespace for the elements in the Definitions and follows the convention established by XML Schema." I think this is mistaken. The convention established by XML Schema relates to schema/@targetNamespace in the XSD. Definitions/@namespace "follows" (or did in the beta version) the convention established by BPMN 2.0, which is specifically for identifying external references as a variant of QName, using the prefix of the declared target namespace and the ID of the element in that namespace. DMN FTF no longer uses that convention, so Definitions/@namespace has no purpose, although it is a required attribute. I would like to see a return to the beta format of external references (making Definitions/@namespace relevant), since there are explicit pointers from DMN to BPMN processes and tasks, and it makes no sense for DMN to use a different referencing mechanism (based on filename not namespace) than the one BPMN uses to reference other BPMN models.

  • Reported: DMN 1.0 — Mon, 9 Mar 2015 19:30 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    treat namespace as part of the qualified name for imported elements

    presumably if a decision D requires an imported decision E from namespace S, then D's logic can refer to S.E (but where do we say that?)

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Constraints on Decision Table elements unclear

  • Key: DMN11-24
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    The S-FEEL and FEEL grammars of chapters 9 and 10 suggest a much wider range of allowed syntax in decision tables than are illustrated in any examples of the spec. For example, input entries and output entries may reference one or more "names" - presumably variables - but in the examples they reference only literal values. Also, all examples of input expressions are simply variable names, not expressions. Additional text is needed to explain what is allowed and not allowed in decision table elements.

  • Reported: DMN 1.0 — Mon, 9 Mar 2015 19:00 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Text to explain constraints on decision table elements

    These edits reflect grammar rule changes consistent with what is allowed in decision table elements under DMN11-49, resolving ambiguity of the terms "name", "expression", and other inconsistencies. This proposal was reviewed and agreed by Jan Vanthienen and myself and is ready for consideration by RTF.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

DecisionRule, InputClause & OutputClause should have ID and label for referencing in execution logs


Expression defined as resulting in single value, but Decision may have multiple values

  • Key: DMN11-22
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    This is related to DMN11-9. Expression class is defined in 7.3 and 7.3.1 as "return a single value when interpreted", but Decision (e.g. DecisionTable, concrete subclass of Expression) may return multiple values, in two ways. Compound output tables, and multi-hit Collect tables. I suggest removing the "single value" comment from definition of Expression, or applying it only to a different class than the superclass of DecisionTable.

  • Reported: DMN 1.0 — Mon, 9 Mar 2015 18:44 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Revise text to clarify Expression as "single value".

  • Updated: Tue, 29 Mar 2016 15:07 GMT

input expression example 'age<25' is not legal in SFEEL grammar

  • Key: DMN11-21
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    8.2.3 says "Input expressions are usually simple, for example, a name (e.g. CustomerStatus) or a test (e.g. Age<25)." However, under the S-FEEL grammar of 9.1, Age<25 is not a simple expression.

  • Reported: DMN 1.0 — Mon, 9 Mar 2015 17:51 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Revise SFEEL grammar to allow comparison in input expression

    The revisions to S-FEEL grammar allow comparison in CL2 input expression. Attachments for discussion only and not part of proposal.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

In metamodel, 'variable' should move from Information Requirement to Decision / Input Data

  • Key: DMN11-65
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In 6.3.11 it says the notation for an information requirement is a plain arrow (from a required decision or input data). Arrows have no labels. Yet, table 14 shows a 'variable'. Presumably, this variable must be the same as the required decision or input data. Therefore, the variable should be removed from the InformationRequirement class, and the Decision class and InputData class should extend the InformationItem class. Variables are of type InformationItem.

    Proposed: remove 'variable' from table 14. Make DRGElement extend InformationItem (figures 15, 17, 19, 20 and supporting text). Remove 'informationRequirement' and 'valueExpression' from table 20. Define the qualified name of an imported DRGElement to be of the form prefix . localPart where prefix must be distinct for each import element.

  • Reported: DMN 1.0 — Thu, 4 Jun 2015 05:31 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    text changes to support move of InformationItem in MM/xsd

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Decision table completeness undefined, Complete code conflicts with Collect

  • Key: DMN11-32
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    All figures showing decision tables need to be reviewed for correct hit policy and completeness codes. Many examples of UC and HC, which are not allowed in FTF version.

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 18:45 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Remove completeness info from model and notation

    we can define completeness of decision table rules, so that tools behave consistently, but there seems to be no clear need to model or notate completeness as a separate flag.

    Many DT figures have a 'C' meaning Complete - these must all be removed.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

Dangling reference

  • Key: DMN11-35
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    FEEL datatypes are listed in 10.3.2.2. There is no such list. They are described below, in numbered sections, but not in a list.

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 20:39 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    replace ref to 10.3.2.2

    rewording in revised text

  • Updated: Tue, 29 Mar 2016 15:07 GMT

extraneous asterisks (*)

  • Key: DMN11-34
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    No idea what the asterisks mean:
    FEEL([1+1, 2+2]) *is [2, 4]*.
    Proposed: replace with bold text between asterisks and remove asterisks.

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 20:36 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Remove extraneous asterisks in 10.3.2.1

    In clause 10.3.2.1, the example
    FEEL([1+1, 2+2]) is [2, 4]
    should not contain the asterisks, which are the result of a copy-paste error from JIRA.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Beta2 XSDs are broken

  • Key: DMN11-60
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Both dmn.xsd and dmn3.xsd at http://www.omg.org/spec/DMN/1.0/Beta2/ have problems. Two small issues prevent any use of dmn3.xsd. Four occurrences of type="tExpression" must be changed to type="tLiteralExpression" in dmn.xsd before it can be used to serialize decision tables and enumerations.

  • Reported: DMN 1.0 — Fri, 22 May 2015 17:54 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    correct 2 issues in dmn3.xsd and 1 issue (4 occurrences) in dmn.xsd

    Note that previous issue DMN11-91 has combined dmn3.xsd into dmn.xsd
    2 occurrences of type="tExpression" to type="tLiteralExpression" made by this issue, and
    2 occurrences of type="tExpression" to type="tUnaryTests" made for issue DMN11-81.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

authorityRequirement in XSD

  • Key: DMN11-52
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    tAuthorityRequirement is incorrect. This element is contained in a decision, BKM, or KnowledgeSource. It should reference a KnowledgeSource, but in XSD it is a choice between requiredDecisionRef, requiredInputRef, and requiredAuthorityRef. Propose replace that choice with requiredAuthorityRef, pointer to the KnowledgeSource.

  • Reported: DMN 1.0 — Thu, 7 May 2015 18:47 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    issues seeking clarification

    issue clarified

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Remove attribute DecisionTable/@isConsistent

  • Key: DMN11-44
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    I think this attribute is inappropriate. It reflects a model validation condition, not a design-time property. Moreover, it has default value "false", suggesting that any model that omits this attribute is intentionally inconsistent, which makes no sense to me.

    This is a bit different from isComplete, where false could possibly be intentional at design time.

  • Reported: DMN 1.0 — Thu, 23 Apr 2015 22:32 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    *Remove consistency info from model *

    we could define the concept of consistency, so that tools will behave consistently, but it does not seem to belong in the model. Rules are either consistent or not, regardless of what some flag might say.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

change "output expression" to "output name"

  • Key: DMN11-43
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In decision table, Fig 27, 28, and third bullet on p66 refer to output expression. The other figures and the metamodel/schema refer to output name. I don't believe the output column heading can be an expression, just a name. Suggest replace "output expression" with "output name".

  • Reported: DMN 1.0 — Thu, 23 Apr 2015 22:02 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    correct callouts in Figs 27&28, create additional figures for multiple outputs

    attached figures to be replaced/inserted, with indicated revised neighboring text. No MM or XSD change.

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:
    • Fig27-30Prop118.docx 753 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

add Definitions optional attributes exporter, exporterVersion

  • Key: DMN11-30
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    For model interchange, BPMN has shown these attributes useful for identifying the tool name and version used to create the serialization. The importing tool may have special mappings for certain exporters.

  • Reported: DMN 1.0 — Sun, 12 Apr 2015 16:03 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    add Definitions/@exporter, @exporterVersion

    optional string attributes used to identify the tool that created the serialization, to aid in model interchange

  • Updated: Tue, 29 Mar 2016 15:07 GMT
  • Attachments:

DMN 1.1 RTF Issue: Negative numerics in decision tables

  • Key: DMN11-13
  • Legacy Issue Number: 19731
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    The syntaxes defined in 9.1 (S-FEEL grammar) and 10.3.1.2 (FEEL grammar) do not permit decision table input entries to contain negative numeric values.

    9.4.3: An input entry is a simple unary tests, defined using:

    14: simple unary tests

    13: simple positive unary tests

    7: simple positive unary test

    8: interval

    18: endpoint

    19: simple value

    33: simple literal

    36: numeric literal: [0-9] & “.”

    I suggest a numeric literal should be allowed to start with a minus sign.

  • Reported: DMN 1.0 — Mon, 2 Mar 2015 05:00 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    allow numeric literal to start with minus sign

    according to the current grammar, numeric literals cannot have a minus sign, so neither can range endpoints, which are not arbitrary expressions.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Nested ItemDefinition doesn't work

  • Key: DMN11-147
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The intent of ItemDefinition and itemComponent was to allow nested structures, such as Order contains a list of items, each item having an ID, Description, and Quantity. This isn't possible without having to create intermediate ItemDefitions and refs.

  • Reported: DMN 1.0 — Fri, 9 Oct 2015 18:21 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    close as duplicate

    close as duplicate

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Clarify defaults for decision table outputs

  • Key: DMN11-130
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    The spec states (8.2.12) "Incomplete tables may specify a default output. The default value is underlined in the list of output values." This needs two points of clarification:

    (a) When a default is specified, a decision table is ipso facto complete. I propose we drop the word "incomplete".
    (b) The spec does not say how to use defaults when the output is compound. Can we specify defaults for some output columns and not for others? If so, what value would the output take on default, for the columns where no default was specified? If not, we should say that defaults must be specified for all output columns or none.

  • Reported: DMN 1.0 — Wed, 2 Sep 2015 14:14 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    close, addressed by other proposals

    closed, no longer relevant

  • Updated: Tue, 29 Mar 2016 15:07 GMT

DMN issue: date syntax in table 29

  • Key: DMN11-7
  • Legacy Issue Number: 19691
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36

    On page 116, in clause 10.2.2.1, the Beta 2 document introduces Table 29, “String, date, time and duration comparisons, which shows one FEEL Expression: “2012-12-31 in (2012-12-25..2013-02-14)”. The example is invalid because FEEL has no literal syntax for dates. This example should use the date() built-in function.

    Also, this table should be combined with Table 28, immediately above since they both give examples of the same kind.

  • Reported: DMN 1.0 — Wed, 17 Dec 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Combine tables 28 & 29 and change formatting

    revise text as indicated

  • Updated: Tue, 29 Mar 2016 15:07 GMT

DMN Issue: typo in 3rd well-formed requirement of KnowledgeRequirement

  • Key: DMN11-6
  • Legacy Issue Number: 19690
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Reference the DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG document number dtc/14-11-36

    On page 61, clause 6.3.12 describes the “Knowledge Requirement metamodel”. In the section on well-formed KnowledgeRequirements, the third bullet beginning “if the InformationRequirement element …” should instead read “if the KnowledgeRequirement element ….”

  • Reported: DMN 1.0 — Tue, 16 Dec 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Correct typo in 3rd well-formed requirement of KnowledgeRequirement

    On page 51, clause 6.3.12 describes the “Knowledge Requirement metamodel”. In the section on well-formed KnowledgeRequirements, the third bullet beginning “if the InformationRequirement element...” should instead read “if the KnowledgeRequirement element.…..”

  • Updated: Tue, 29 Mar 2016 15:07 GMT

DMN issue: typo in introduction of "Relating Logic to Decision Requirements"

  • Key: DMN11-4
  • Legacy Issue Number: 19688
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36

    The bullet at the top of page 64, in clause 7.1, contains the following garbled sentence: “The variables that are used in the body of the function defined by a business knowledge model element in the DRG must be bound to the information sources each of the requiring decision.”

  • Reported: DMN 1.0 — Tue, 16 Dec 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    correct the typo

    see revised text

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XSD internally inconsistent, does not match the spec

  • Key: DMN11-9
  • Legacy Issue Number: 19724
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    I believe the XSDs are seriously messed up. On the surface, this would be apparent to anyone who tried to open the level 3 xsd in an XML editor, since the “include” fails right off the bat and the tool goes ding ding ding. Not only does it point to the wrong filename, but the namespace is different, not allowed with include. You can fix those things by making the namespaces match and fixing the filespec. Actually I don’t care that much about the level 3. I am more concerned with the 14-08-19.xsd, the Level 1 and 2.

    That one has an element named ItemDefinition and another one named itemDefinition with different datatype, which is confusing. I believe that the latter is a pointer to the former. If so, you will have a lot less confusion by renaming the latter itemDefinitionRef.

    But the problem with the XSD goes a lot deeper. Maybe it is my lack of understanding of the spec, I don’t know. I think the central problem is that tExpression (the datatype for inputExpression, inputEntry, outputEntry, range of allowed values, and many other elements) is just a list of inputVariables and possibly a single itemDefinition(Ref). It is NOT an expression, in natural language, S-FEEL, or anything else. Maybe the intent was to allow literal expressions, but the XSD does not reference tLiteralExpression, just tExpression. Or maybe the intent was to do like BPMN and make tExpression a mixed-content type, where the expression string is the direct content of the element, but the XSD does not say that, either. Or maybe the intent is to put the expression in the any ##other element or attribute? That would work but be very weird. Anyway, without that I think it would be an impossible challenge to serialize even the simplest decision table per the XSD. And maybe that is why there are no serialization examples in the spec.

  • Reported: DMN 1.0 — Tue, 17 Feb 2015 05:00 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    overall, early list of possible xsd issues subsumed by more focussed issues

    All the substantive have been addressed by other issues. This can be closed.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XMI issues from Pete Rivett

  • Key: DMN11-3
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    There are some issues with the XMI:

    • The top level element should be a uml:Package not a uml:Model
    • There is a proprietary namespace at the top of the file which should just be deleted: there is no longer any need for such a profile and it should be removed from the original MagicDraw model xmlns:cmof_Profile="http://www.magicdraw.com/schemas/cmof_Profile.xmi">
    • Likewise you don’t need the UML StandardProfileL3.
    • On the other hand you do need a MOF tag to declare the namespace prefix
    • The default value which is an enumeration should have a “type” property referencing the enumeration

    Attached is the updated file.

  • Reported: DMN 1.0b1 — Tue, 19 Aug 2014 07:15 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    these are issues with 1.0 - will try to incorporate into 1.1

    these are issues with the XMI produced for 1.0. We are not changing 1.0.
    I have tried to avoid these issues in 1.1

  • Updated: Tue, 29 Mar 2016 15:07 GMT

S-FEEL "expression" undefined

  • Key: DMN11-23
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    The S-FEEL grammar in 9.1 references "expression" in rules 21-26, but "expression" is undefined in S-FEEL. Probably "expression" in those rules should be replaced by "simple expression", which is defined.

  • Reported: DMN 1.0 — Mon, 9 Mar 2015 18:47 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    duplicates issue 24

    duplicates issue 24

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: DecisionTable/rule/condition should be IDREF not IDREFS

  • Key: DMN11-27
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    This element is a pointer to one inputEntry (and implicitly to its clause) so it should be IDREF, not a list. The element is unbounded, so references to other inputEntry elements are contained in other condition elements of the same rule.

  • Reported: DMN 1.0 — Mon, 9 Mar 2015 19:42 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    merge with issue 81 to remove the level of indirectlion

    we think that intra-decision table references are a significant complication with no useful purpose. Thus, merge with 81.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

need to add UnaryTests to MM and XSD

  • Key: DMN11-109
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    This is to complete the proposal begin by issue DMN11-24 proposal DMN11-67

  • Reported: DMN 1.0 — Thu, 6 Aug 2015 16:31 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    solved as part of DMN11-81

    The necessary changes have been done in DMN11-81.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: change type of LiteralExpression/text, ItemDefinition/typeDefinition, and (new) textAnnotation/text to xsd:string

  • Key: DMN11-102
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    Currently these are mixed content type in which the direct content is untyped, and any additional child elements must be in a different namespace. they should simply be string.

  • Reported: DMN 1.0 — Tue, 21 Jul 2015 17:22 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    change mixed content elements to string

    xsd change only

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Decision Table metamodel and XSD should restrict input entries, input values, and output values to unary tests, and LiteralExpression for input expressions and output entries

  • Key: DMN11-84
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Current MM allows any expression for input entries. The spec restricts these to text strings with syntax of unary tests (or simple unary tests). Also, unary tests are not expressions and are not literal expressions.

  • Reported: DMN 1.0 — Fri, 26 Jun 2015 23:26 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    *merge with 81 - removing indirection from decision table *

    So that all the decision table MM and XSD changes can be done together, we combine these issues.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

8.2.10 calls crosstab tables "rules as columns"

  • Key: DMN11-88
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    Figure 41 and 42 are crosstab (columns and rows are input values) but called vertical/rules-as-columns. Surrounding text in 8.2.10 also incorrect.

  • Reported: DMN 1.0 — Mon, 29 Jun 2015 23:12 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    OK as is

    I agree with comments, withdraw the issue.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: make @id optional in tExpression

  • Key: DMN11-80
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    Except for DT rule conditions and conclusions, id pointers to expressions are rare (maybe none?). Propose change @id in tExpression from required to optional.

  • Reported: DMN 1.0 — Fri, 19 Jun 2015 16:14 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Change tExpression/@id to use="optional"

    Change value of attribute 'use' from 'required' to 'optional'.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

FEEL/S-FEEL names

  • Key: DMN11-62
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    S-FEEL grammar rules 30-32 list characters that can be part of names. I do not see space (\u20) as one of the allowed characters or "additional symbols". There are lots of Unicode characters and symbols that probably should not be allowed.

  • Reported: DMN 1.0 — Sat, 30 May 2015 22:25 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    name symbols mostly copied from xml, but we do add the space!

    can open new issue in 1.2 if spaces are really a problem for implementations

  • Updated: Tue, 29 Mar 2016 15:07 GMT

list variables in decision tables

  • Key: DMN11-33
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    Is it correct to say that a list is not allowed as an input expression in S-FEEL? That would mean that a supporting decision with Collect hit policy could not provide input to a dependent decision table. If it is allowed, I don't think S-FEEL input entry can distinguish "every member of the list is in [literal list]" from "any member of the list is in [literal list]". I believe it would be allowed in full FEEL... but unclear if decision table can use this.

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 19:16 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    no change required for input expression

    If an input variable is a list, then input expression can reference it.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: Relation and List

  • Key: DMN11-76
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    Relation is a particular boxed expression format for a list of similar contexts. It is a two-dimensional grid. Each row (unlabeled) represents a context, and each column a context entry. dmn3.xsd does not properly represent this. Also, Gary suggested organizing the grid in the xsd by rows (contexts) rather than by columns, as it is now in dmn3.xsd.

  • Reported: DMN 1.0 — Thu, 11 Jun 2015 19:04 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    Modify tList and tRelation in dmn3.xsd

    Withdrawn.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Xsd typeRef and itemDefinitionRef

  • Key: DMN11-57
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In xsd, ItemDefinition links the type either to a base type via typeDefinition or some other type via typeRef. If the other type is defined externally in imported xsd, typeRef should be QName, pointer to a name, which it is. But to reuse a type defined in another ItemDenition, it should be itemDefinitionRef, pointer to an id. Propose that itemDefinitionRef be added to the choice in ItemDefinition.

  • Reported: DMN 1.0 — Sun, 17 May 2015 16:09 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    Resolved in DMN11-54

    Resolved in DMN11-54

  • Updated: Tue, 29 Mar 2016 15:07 GMT

XSD: add optional @name to inputVariable

  • Key: DMN11-55
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In a decision logic expression, inputVariable is an ID reference to an InformationItem, which provides the variable's name. The expression (e.g. binding expression or literal expression) then references the variable by name. This works operationally, but the logic of the XML would be much easier to follow and debug if the inputVariable allowed an optional name attribute to hold the variable's name.

  • Reported: DMN 1.0 — Fri, 15 May 2015 20:07 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    Merged with and Resolved by DMN11-69

    I submitted this issue but now I think better approach is to remove id references like inputVariable in tExpression and use names instead. This issue is thus merged with DMN11-69 and resolved by that proposal.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

FEEL concatenate function

  • Key: DMN11-53
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In Table 58, concatenate and append are essentially the same list function in FEEL. There is no concatenate string function in Table 57. Propose concatenate be moved to Table 57 as a string function (where it is most needed).

  • Reported: DMN 1.0 — Tue, 12 May 2015 00:03 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    string concatenation uses the "+" operator rather than a builtin function

    string concatenation is defined in Table 42

  • Updated: Tue, 29 Mar 2016 15:07 GMT

dmn3.xsd

  • Key: DMN11-48
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    This issue separates the dmn3.xsd issues from DMN11-9, which otherwise concerns dmn.xsd.
    There are a number of serious problems with dmn3.xsd:
    1. Syntactically incorrect. The include of dmn.xsd points to the wrong filename. The only reason why include is needed (syntactically) is to reference tExpression.
    2. tExpression is not the right datatype for the elements. See DMN11-9 for why.
    3. dmn3.xsd does not represent what 12.2.2 says it does. It is not an interchange format for Level 3 decision models! It is just a schema for a context. And it is not even the right schema for a context. Serialization of a context does not use elements named ContextEntry, List, Relation, etc. You can see that from 10.3.3.3.1 and 10.3.3.3.2. I think it is meant to clarify the semantics of context, but it would never be used in serialization.

    For these reasons I propose that 12.2 is modified and dmn3.xsd is removed from the specification. If a separate schema is needed to serialize Level 3, it must contain the whole thing, starting from Definitions. I don't think a separate schema is needed, but we should check if the existing element for output variable, InformationItem, can describe a context.

  • Reported: DMN 1.0 — Thu, 30 Apr 2015 15:14 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    close and merge with dmn11-91

    The issues with dmn3.xsd are addressed by dmn11-61, dmn11-94 and others.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

output data symbol & comment symbol missing in DRDs

  • Key: DMN11-42
  • Legacy Issue Number: 19746
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Please add an optional output data symbol and a comment symbol, which I both urgently miss, as discussed in the LinkedIn DMN group at
    https://www.linkedin.com/groups/Why-no-output-data-symbol-4225568.S.5976658175284244483

    Summary: Why is there no output data symbol in DMN 1.0's DRDs?
    Decisions have results, which may be complex, and currently their output data may only be indicated by the decision's name (e.g. "determine X": output is X; "check X": result is Boolean). That is not very clear.

    An optional output data symbol would make decision output graphically explicit, and provides for symmetry.

    DMN also lacks a comment symbol which could otherwise be used for this on DRDs.

  • Reported: DMN 1.0 — Fri, 17 Apr 2015 04:00 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    add text annotations in DMN11-99 but decline to add output symbol

    output symbol seems redundant with existing decision symbol (an decision has always exactly one output) and we don't want to clutter a large DRD

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Clarify Decision/outputDefinition, DecisionTable/clause/outputDefinition, DecisionTable/@name, clause/@name

  • Key: DMN11-39
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    The issue is illustrated by Fig 36 on p71. The resolution should be clarified in the text.
    8.2.5 says (I think) that Decision/@name = DecisionTable/@name = label in output column header in the decision table.
    For a single-output DT, Decision/outputDefinition* and DecisonTable/clause/outputDefinition* both point to an itemDefinition defining the data type of the output.
    For a compound-output DT, the compound output name is DecisionTable/@name. Decision/outputDefinition is a pointer to an itemDefinition for the compound output, but the spec does not describe how such a compound output should be constructed. Each individual output name is given by DecisionTable/clause/@name (for an output clause), and the clause/outputDefinition is a pointer to its datatype.

    • renamed outputDefinitionRef in proposed revision to dmn.xsd, see DMN11-9. In any case, these elements should be given different names.
  • Reported: DMN 1.0 — Thu, 16 Apr 2015 19:30 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    Merge with DMN11-43

    Some of this is resolved by other MM changes to decision table. The issue of output names and clause names is the focus of DMN11-43.

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Examples

  • Key: DMN11-29
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    DMN 1.1 should provide examples of all types of decision model allowed by the standard, both graphically (DRD and decision table, where appropriate) and XML serialization. Currently missing:
    1. decision tables with an expression (more than a name) in inputExpression and outputExpression.
    2. decision tables with inputEntry or outputEntry referencing a "name" as defined by S-FEEL, i.e. not just a literal.
    3. DRD and decision table involving what Vanthienen calls "action subtables". All existing examples are "condition subtables".
    4. Serialization of crosstab format tables.
    5. Representation of literal values vs names in serialization.
    6. Representation of PMML and FEEL in the serialization.

  • Reported: DMN 1.0 — Sun, 12 Apr 2015 15:39 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    no volunteers, no time for 1.1

    agreed to be important for 1.2

  • Updated: Tue, 29 Mar 2016 15:07 GMT

not all references in DMN are by ID

  • Key: DMN11-152
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    new typeRef is by name, not ID, as claimed in beta2 spec 12.3.2

  • Reported: DMN 1.0 — Wed, 21 Oct 2015 01:38 GMT
  • Disposition: Resolved — DMN 1.1
  • Disposition Summary:

    Correct text for XSD references (12.3.2)

    see revised text

  • Updated: Tue, 29 Mar 2016 15:07 GMT

DMN Issue: Boxed context example of XML data is wrong

  • Key: DMN11-8
  • Legacy Issue Number: 19692
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36

    Clause 10.3.3.3.3 on page 144 shows a boxed context that is supposed to be the equivalent of the XML example shown in clauses 10.3.3.3.1 and 10.3.3.3.2. This boxed content is missing a horizontal line immediately below the row that contains “tns$Employee”.

  • Reported: DMN 1.0 — Wed, 17 Dec 2014 05:00 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    the line is there in the 'real' spec

    line was missing in a version used by reviewer

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Change Tracking Document

  • Key: DMN11-1
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Map all DMNFTF issues to editing instructions expressed as
    change <snippet from beta 1> to <snippet from change bar document>
    Cover all changes in the cbar document, and comment on changes resulting from multiple issues.

  • Reported: DMN 1.0b1 — Tue, 21 Oct 2014 06:32 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    transferred automatically from FTF

    transferred automatically from FTF

  • Updated: Tue, 29 Mar 2016 15:07 GMT

DMN issue: InformationItem is not a specialization of Expression

  • Key: DMN11-5
  • Legacy Issue Number: 19689
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    reference DMN FTF 1.0 Beta 2 with Change Bars.pdf document, OMG Document number dtc/14-11-36

    On page 75, in clause 7.3.4, the 6th paragraph starts “As a concrete specialization of Expression, an InformationItem element ….” However, none of the UML diagrams show a generalization relationship between InformationItem and Expression.

  • Reported: DMN 1.0 — Tue, 16 Dec 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DMN 1.1
  • Disposition Summary:

    merge with issue to clarify relationship of Information Item and Expression

    proposal for issue 65 resolves this issue as well

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Incorporate AB feedback into the FTF Report, the marked-up specification, and the clean specification

  • Key: DMN11-2
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In the FTF Report,
    for DMNFTF-6 and DMNFTF-17, use the format Replace <old text> with <new text>,
    for DMNFTF-93, also use Replace/with, and identify the old text as all occurrences of invokes in 11.3, and
    for DMNFTF-221, describe the change as a restoration of the relative text positions that were unintentionally changed by a prior edit.

    In the specification,
    make changes to mark-up and comments as described in the subtask (issue 246).

  • Reported: DMN 1.0b1 — Sat, 13 Sep 2014 20:37 GMT
  • Disposition: Closed; No Change — DMN 1.1
  • Disposition Summary:

    automatically transferred from FTF

    nothing to do in RTF

  • Updated: Tue, 29 Mar 2016 15:07 GMT

BigDecimal is not the only mapping of number to Java

  • Key: DMN11-11
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Clause 10.3.2.9 shows FEEL number values as mapped to XML decimal, integer, and double, but the only mapping to Java is to BigDecimal. The appropriate mapping to Java, like the appropriate mapping to XML, depends on the range and intent of the data element. BigDecimal is rarely used for anything but currency. Java int and double are much more likely to be appropriate for most data items. The mapping of number to Java should be just as flexible as the mapping to XML and PMML.

  • Reported: DMN 1.0 — Wed, 9 Jul 2014 21:23 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    no one volunteered, we'll try again in 1.2

    roll forward to 1.2

  • Updated: Tue, 29 Mar 2016 15:07 GMT

cannot interchange input data style

  • Key: DMN11-10
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    We have 2 notations for input data

    1. an oval shape

    2. the name of input data in the requiring decision (so-called Listed Input Data)

    As far as I see, there is nothing in the MM to distinguish these cases,

    so there is no way to interchange the intended notation.

    Proposed: add a new attribute to Decision named listedInputData of type boolean.

  • Reported: DMN 1.0b1 — Sat, 9 Nov 2013 00:33 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    defer to 1.2

    no proposal submitted for 1.1

  • Updated: Tue, 29 Mar 2016 15:07 GMT

No notation for ItemDefinition

  • Key: DMN11-66
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The notion of a 'type' or ItemDefinition is in the metamodel (with some pending issues) and in the semantics and concepts, but little is in the notation. Thus, we have notation that allows you to execute an expression with actual arguments, but no notation to allow validation based on type information without actual values.

    We have most of the pieces, so it should not be difficult. E.g., individual values can be number, string, date and time, etc. We can allow numeric ranges using our unary tests, e.g. '>0', '[10..30)', etc. We can allow LOVs using "abc", "def", "ghi". These can be 'simple items', and we can also define structures using something similar to boxed contexts.

  • Reported: DMN 1.0 — Thu, 4 Jun 2015 06:28 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    carry over to 1.2

    carry over to 1.2

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Consider date and time datatype in S-FEEL

  • Key: DMN11-46
  • Legacy Issue Number: 19755
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    a. In clause 9.2, para 5, first sentence, "date and time" should be in italics.
    b. Why is date and time type excluded from S-FEEL? This restriction makes XSD mapping problematic.

  • Reported: DMN 1.0 — Tue, 28 Apr 2015 04:00 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    defer to 1.2

    No proposal was submitted for 1.1

  • Updated: Tue, 29 Mar 2016 15:07 GMT

alternative indication of reusable logic in DRD

  • Key: DMN11-51
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In the metamodel/XSD, decision logic is contained in a decision element, hence not reusable. To reference reusable decision logic, decision invokes BKM, which is reusable. The semantics are clear, but representation of the decision and BKM as separate graphical elements in DRD is visually inefficient. It creates unnecessary clutter in the DRD (Fig 63 is a prime example). BPMN solved this problem in a better way, and I suggest DMN should allow the same. In BPMN a subprocess definition is embedded in the parent process so to reference reusable subprocess, it uses a call activity. The call activity shape is same as subprocess except it has a thick border style. The diagram does not contain both subprocess and call activity, just one or the other. I would like to propose that a decision shape in DRD with a thick border be used to mean the decision invokes a BKM (with name generated from the decision name). No metamodel or schema changes required; this is merely alternative graphical notation. In a DMN tool, typically clicking on the decision will hyperlink to the decision logic (DT or literal expression), whether that logic is embedded in the decision or reusable. This distinction is mostly important to programmers, not modelers, so should not unnecessarily complicate the diagram.

  • Reported: DMN 1.0 — Tue, 5 May 2015 17:58 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    no time in 1.2

    defer to 1.2

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Business Context links go both ways

  • Key: DMN11-31
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    In XSD, business context pointers are duplicated in both directions. E.g. decisionOwner and decisionMaker point to organizationalUnit, which in turns has pointers back the other way. This duplication adds no new information, just potential for internal inconsistency. I suggest omitting one of these directions; the other one is easily extracted from the serialization by XPATH.

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    defer to 1.2

    minor issue, no strong advocate to change in 1.1

  • Updated: Tue, 29 Mar 2016 15:07 GMT

Need group artifact in DRD, metamodel, and XSD

  • Key: DMN11-116
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Group is an unfilled rectangle enclosing various elements in the DRD, with meaning defined by the modeler. It follows the usage defined by BPMN, an “artifact” with no operational semantics, simply an annotation of the model.

  • Reported: DMN 1.0 — Thu, 20 Aug 2015 00:13 GMT
  • Disposition: Deferred — DMN 1.1
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 22 Dec 2015 15:43 GMT
  • Attachments:

missing aggregation: BuiltinAggregator attribute type on figure

  • Key: DMNFTF-149
  • Legacy Issue Number: 19469
  • Status: closed  
  • Source: gmail.com ( Remigiusz Wasilewski)
  • Summary:

    Figure 37 DecissionTable class diagram

    Class DecissionTable
    Attribute aggregation
    missing
    DataType - BuiltinAggregator
    Default - COLLECT.

  • Reported: DMN 1.0b1 — Fri, 13 Jun 2014 04:00 GMT
  • Disposition: Duplicate or Merged — DMN 1.0
  • Disposition Summary:

    small DT MM change combined w/ other issue

  • Updated: Tue, 21 Apr 2015 01:19 GMT

In the metamodel XMI file I found the following with the help of the NIST Validator

  • Key: DMNFTF-2
  • Legacy Issue Number: 18967
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There is the unsatisfied href to 08-11-13.xmi. If you really want to extend BMM it should use the proper OMG URI for Objective within BMM. This is just completing BMM 1.2

    • DecisionTable::aggregation has no datatype: I assume it should be BuiltInAggregator
    • DecisionTable::aggregation property’s default value of COLLECT is not validly specified. Easy once you set the type
    • The default value of DecisionTable::hitPolicy of UNIQUE is differently but also not validly specified. In MD I was easily able to delete the Opaque Expression by right-clicking the default value; and then it gave me the correct list from the enumeration
    • The association outputClause2outputEntry has an owned constraint with body of “ordered”. Ordering should be specified at the property level (which is what you have done) so the constraint should just be deleted. BTW by convention association names should start with a capital.
    • The association DecisionTable2rule has an owned constraint with body of “ordered”. Ordering should be specified at the property level (which is what you have done) so the constraint should just be deleted. BTW by convention association names should start with a capital.
    • There is an association end property on class Import of type Definitions that is not named
    • There should be a MOF Tag for the namespace Prefix (and optionally the nsURI)
  • Reported: DMN 1.0b1 — Mon, 23 Sep 2013 04:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    XMI has been corrected of the errors listed in the issue, and modified to account for the resolutions of other issues when relevant. The final XMI document passes NIST validator (except for the references to the BMM and BPMN metamodels, wihch ar enot loaded in the validator).

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

13-08-03.xsd file:

  • Key: DMNFTF-1
  • Legacy Issue Number: 18966
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There is inconsistency in the values for BuiltInAggregator – the model (and section 7.2.13 of the spec) includes AVERAGE, the XSD instead has ANY.

    • The following attributes are inconsistent: they declare a type of anyURI but then provide a default value that is not a URI:
    • <xsd:attribute name="expressionLanguage" type="xsd:anyURI" use="optional" default="FEEL" />
      <xsd:attribute name="typeLanguage" type="xsd:anyURI" use="optional" default="FEEL" />
    • I’m concerned about the many definitions which use xsd:qName as the type of elements. I don’t like the very non-standard use of qNames described in 11.3.2 of the spec: I don’t see why normal hrefs cannot be used for external files
    • <xsd:element name="drgElement" type="xsd:QName" minOccurs="0" maxOccurs="unbounded" />
  • Reported: DMN 1.0b1 — Mon, 23 Sep 2013 04:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    1. There is inconsistency in the values for BuiltInAggregator – the model (and section 7.2.13 of the spec) includes AVERAGE, the XSD instead has ANY

    --> corrected in bmi-13-08-03 (corrected issue 1).xsd (also replacing FIRST with COUNT) [attached]

    2. The following attributes are inconsistent: they declare a type of anyURI but then provide a default value that is not a URI:
    a. <xsd:attribute name="expressionLanguage" type="xsd:anyURI" use="optional" default="FEEL" />
    b. <xsd:attribute name="typeLanguage" type="xsd:anyURI" use="optional" default="FEEL" />

    --> Change target namespace for level 3 (FEEL) XSD to http://www.omg.org/spec/FEEL/20140401 and use that URI for FEEL. No URI specific to Simple FEEL. Corrected in bmi-13-08-03 (corrected for issue 1).xsd [attached]

    3. I’m concerned about the many definitions which use xsd:qName as the type of elements. I don’t like the very non-standard use of qNames described in 11.3.2 of the spec: I don’t see why normal hrefs cannot be used for external files: <xsd:element name="drgElement" type="xsd:QName" minOccurs="0" maxOccurs="unbounded" />

    --> move to new issue DMNFTF-99

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Stick with own definition of terms in all cases

  • Key: DMNFTF-4
  • Legacy Issue Number: 19098
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    Since DMN is a standard (and in particular claims to be a business standard), then it must stick with its own definition of terms in all cases. Otherwise, in what sense is it a standard (especially a business standard)?

    In defining “decision” DMN had two fundamental choices (from Merriam-Webster Unabridged dictionary):

    1. a : the act of deciding; specifically : the act of settling or terminating (as a contest or controversy) by giving judgment

    1. b : a determination arrived at after consideration : SETTLEMENT, CONCLUSION

    DMN explicitly chose the first meaning. I strongly prefer the second, but then I’m a big fan of all things declarative. So in BRS TableSpeak an outcome by definition is a decision.

    Since DMN explicitly chose the first meaning, however, an outcome (conclusion) is by definition not a decision. A decision is an act, never the result of the act.

    If DMN somehow allows ‘overloading’ of the term “decision” – the central term in the standard – all bets are off. For example I have read elsewhere that the 'output' of a decision can be treated as a decision in DMN.

    A term that you can use any way you want when it happens to suit you is a term that has not been standardized at all.

  • Reported: DMN 1.0b1 — Tue, 19 Nov 2013 05:00 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    This comment appears to have been made against an earlier draft.
    After review of the current beta draft, the task force believes the definition of decision as an act of choosing among possible options is the correct definition, and is consistent with the current text. This captures the notion of applying decision logic in the making of a decision.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Authority Requirement

  • Key: DMNFTF-3
  • Legacy Issue Number: 19067
  • Status: closed  
  • Source: Trisotech ( Mr. Ron Ross)
  • Summary:

    In the glossary (p. 166), the definition of "Authority Requirement" reads "The dependency of a decision or business knowledge model on a knowledge source which provides a source of authority for the decision logic.".

    Figure 13, however, shows two Authority Requirement dependencies in which knowledge source is the dependent item. So Input Data and Decision can provide a source of authority for the knowledge source. This seems confirmed by the text under "b" at the bottom of p. 34.

    Point 1. The definition appears to need revision.

    Point 2. To say "Input Data and Decisions can provide sources of authority for analytic models." seems to me to be really stretching the English language. I've never heard anyone in either business or IT say something like that. Perhaps this is aimed at some Community I'm not familiar with? It seems like over reduction, or over abstraction, or over something, to me.

  • Reported: DMN 1.0b1 — Tue, 5 Nov 2013 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    I have proposed a number of edits to resolve this issue and create a consistent definition that handles the various uses.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

We need a beta 2 spec to consolidate Ballots 1-4

  • Key: DMNFTF-144
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    We need a beta 2 spec to consolidate Ballots 1-4, making it easier to propose further document changes that incorporate agreed-upon changes.

  • Reported: DMN 1.0b1 — Fri, 23 May 2014 19:45 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Consolidate resolutions from Ballots 1-4 into a beta 2 specification.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

use round brackets instead of square for IN

  • Key: DMNFTF-143
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    change maritalStatus in ["M","S"] to maritalStatus in ("M","S")

  • Reported: DMN 1.0b1 — Fri, 23 May 2014 18:28 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    change in ["M","S"] to in ("M","S")

  • Updated: Tue, 21 Apr 2015 01:19 GMT

metamodel for structured ItemDefinitions doesn't work

  • Key: DMNFTF-15
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Consider an ItemDefinition (ID) for an Invoice that contains 2 sub-items, shippingAddress and billingAddress, both of type Address, containing sub-items street and city, both strings, etc.

    Clearly, Invoice, Address, and string are all IDs. But shippingAddress, billingAddress, street, and city are not IDs. Rather, they are InformationItems. The MM in Figure 26 of the spec has an itemComponentRef from ID to ID. This is an attempt to model a compound ID like Invoice as a collection of sub-IDs. This incorrect. Invoice is a collection of 2 sub-InformationItems, shippingAddress and billingAddress. Both these IIs refer to the Address ID. The Address ID in turn is a collection of IIs for street, city, etc. These have an ID of string.

    Proposal: replace itemComponentRef (in Figure 26) with a composition from ID to II named itemComponent.

    The ID (e.g. Invoice) owns its itemComponents (e.g. shippingAddress and billingAddress).

  • Reported: DMN 1.0b1 — Tue, 12 Nov 2013 19:47 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Removed the ItemComponentRef attribute and added an ItemComponent class

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Improve FEEL specification of decision tables in Chapter 10

  • Key: DMNFTF-14
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    section 10.3.2.7 should be removed, and 10.3.4.5 should refer to figures in section 8.2, and the formal semantics should be aligned with the informal semantics. Replace all refs to 'rule test (cell)' with 'input entry'.

  • Reported: DMN 1.0b1 — Wed, 20 Nov 2013 17:55 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    replace clauses 10.3.2.7 and 10.3.4.5 with the attached

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:
    • DT.doc 47 kB (application/msword)

boxed (tabular) expressions should be encouraged

  • Key: DMNFTF-13
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    last paragraph of 6.1 of the alpha spec says:

    Using a value expression of type invocation is never required, even when possible: FEEL specifies its own invocation mechanism for more complex usages, and a FEEL literal expression can always be used instead of a value expression of type invocation.

    I would like this to say instead:

    A boxed invocation SHOULD be used instead of a literal FEEL invocation when possible. In general, a boxed expression SHOULD be used instead of a literal FEEL expression when possible. Note that Conformance Level 3 specifies additional boxed expressions.

    Because 'boxed expression' isn't defined until 6.2, the rewritten para should be moved to the end of 6.2 (or even 6.3)

    Also, I notice that 6.1 defines a decision table to be a tabular representation of decision logic. Would it be a good idea to do a global replace of 'boxed expression' with 'tabular expression'?

  • Reported: DMN 1.0b1 — Wed, 7 Aug 2013 22:36 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Define boxed expressions available at each conformance level, and recommend their use over equivalent literal expressions.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

boxed function examples lack mandatory parameter lists

  • Key: DMNFTF-6
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    According to alpha version section 9.2.1.7, a boxed function (decision logic for a BKM) must have a parameters box and a body box.
    Figure 8 is misleading or wrong, the boxed expression for Business knowledge 1 should be a boxed function (have a parameters box and body box instead of 'value expression' box.
    All these examples - Figures 59, 61, 63, 65, 67, 69, 71, 74, 75, 77, need a parameters box beneath the name box. That is because these examples must be boxed functions, because they are invoked by the boxed invocations in Figures 58, 60, etc.

    The consistency of the invocation logic, e.g. Figures 58, 60, etc. may be misleading. The actual parameters and formal parameters just happen to always be the same identifier. This is not required, and in fact is why it is important to list the formal parameters in the boxed function, so that the actual parameters can be substituted properly. For example, valid alternatives to Figure 66 include the following expression text in a box:

    Application risk score model (Applicant Data . Age, Applicant Data . Marital Status, Applicant Data . Employment Status)

    or the following:

    Application risk score model (Marital Status: Applicant Data . Marital Status, Employment Status: Applicant Data . Employment Status, Age: Applicant Data . Age)

    Note that Figures 74 and 77 desperately need parameter lists in order to know how to match actuals to formals in invocations.

    One last example - a decision table dt1 with input x-y and some rules. There would be at least 2 ways to invoke dt1. E.g. dt1(x: 1, y: 2) and dt1(x-y: -1).The different invocations would result in different parses of the target function. In the first, x-y is a subtraction whereas in the second, x-y is a name. To avoid this problem,
    you need a context, independent from any invocation, to indicate whether x-y is a name, or whether x and y are the names. Explicit parameter names attached to the boxed function definition provides such a context. Thus, the decision table needs to be the body in a boxed function definition, which is to say, there needs to be both the DT and the parameter list. The parameter list is a box containing (x,y) or (x-y). These are the parameters for all invocations.

  • Reported: DMN 1.0b1 — Fri, 24 May 2013 19:12 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Allow decision table notation to serve as a boxed function, i.e., not require parameter lists, if the input expressions are simple and can be interpreted as parameter names.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Figure 67 is ambiguous

  • Key: DMNFTF-5
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The Figure can be interpreted as a boxed context, with 2 entries. First entry is the DT named partial score, and the second entry is the unnamed result, containing 'Aggregate = sum', which looks like valid FEEL, but is not intended to be. BTW, the valid FEEL is 'sum(partial score)'. Isn't this as clear as 'Aggregate = sum' ?

  • Reported: DMN 1.0b1 — Sat, 25 May 2013 05:27 GMT
  • Disposition: Duplicate or Merged — DMN 1.0
  • Disposition Summary:

    This is a duplicate of the Aggregation issue.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

some examples of null handling in section 10.3.4.4. are wrong

  • Key: DMNFTF-17
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    and(true,null,true) should be null.

    A better example is

    and(false,null,true) = false

    Also,

    and(0)=or(0)=and(null)=or(null)=null

    We get to define the truth values of and([]), or([]) (0-ary and/or). RIF says and()=true and or()=false, so we'll go with that.

  • Reported: DMN 1.0b1 — Mon, 28 Oct 2013 23:01 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Revise examples as indicated.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Extend Priority hit policy to multiple-output tables

  • Key: DMNFTF-16
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    Priority and Output order hit policies are not supported for compound output tables.

    Jacob Feldman commented in the LinkedIn DMN group:

    "Building real-world decision models, practitioners always face complex issues related to diagnostic and resolution of rule conflicts. Some systems can effectively verify decision model consistency and diagnose rule conflicts. But until recently there were no practically used BR products that claim that they may automatically resolve rule conflicts.

    "While we did not had an update about the current state of the DMN for a while, it does not seem that the first version will include any means to define superiority relations among contradictory rules. I believe at some point DMN may and should be extended in this direction."

    (This was functionality I originally wanted, too, but for some reason we did not cover it in v1.)

    The example he provides could be handled by a very simple extension to DMN (see attached file). I propose we extend the Priority and Output order hit policies to compound output decision tables, by making the first output column the Priority marker regardless of how many columns there are.

  • Reported: DMN 1.0b1 — Mon, 4 Nov 2013 14:47 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    In clause 8.2.11, replace:

    "To reduce complexity, decision tables with compound outputs support only the following hit policies: Unique, Any, First, Rule order and Collect without operator, because the priority schema or collect operator over multiple outputs are undefined."

    with the attached.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Need floor and ceiling builtins

  • Key: DMNFTF-19
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    FEEL has but one kind of number. There is no integer type.

    Sometimes, it is required to convert a number such as 1.7 to the number 1.

    This is not easy with the existing set of builtins. Note that decimal(1.7, 0) = 2.

    Proposed:

    floor(1.7) = 1

    ceiling(1.1) = 2

    x[i] = x[floor(i)]

  • Reported: DMN 1.0b1 — Mon, 28 Oct 2013 22:32 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Add floor and ceiling builtins

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Add extended timezone specification, as forshadowed in 10.3.4.1

  • Key: DMNFTF-18
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    At the end of 10.3.4.1, we have the text:

    Issues:

    1. Extended time zone, e.g. 23:59:00@America/Los_Angeles

    As the SBVR date/time spec notes, the timezone offset from XML date-times (referenced by FEEL)
    is insufficient for most business uses, because it does not handle daylight savings time well.
    Unfortunately, the SBVR spec gives a complex metamodel but no usable syntax.

    I propose that we make the minor extension suggested by the current spec text. Wherever a timezone offset (i.e. +/-HH:MM) can appear in the lexical space of a date/time, an 'extended timezone' can be used. E.g.
    2014-02-06T23:59:00@America/Los_Angeles instead of 2014-02-06T23:59:00-08:00.

    The timezone IDs and associated time zone offsets (which change due to DST and other legal decrees) are maintained at http://www.iana.org/time-zones

  • Reported: DMN 1.0b1 — Mon, 28 Oct 2013 22:58 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Because the IANA tz form is commonly used in Java, Python and other implementation languages, implementers consider it desirable to support it, even though it extends the XML Schema standard forms in a way that has no formal designation. The specification of FEEL conversion operators in clause 10.3.4 is therefore modified to support the IANA form as a valid alternative.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Propose to change OrganizationalUnit to OrganizationUnit

  • Key: DMNFTF-12
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    The BMM metamodel has an OrganizationUnit class, that is referenced from BMM::BMM::Objective, which is itself associated with DMN::Decision

    The DMN metamodel has an OrganizationalUnit placeholder class. Although the two classes do not play the same role in BMM and DMN, obviously, it might be a good idea, from an adoption and implementation viewpoint, as well as from the future evolution viewpoint, to give them the same name...

  • Reported: DMN 1.0b1 — Tue, 6 Aug 2013 17:27 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    Changing the name will not help much if future versions of DMN need to share the same class as is used in BMM to represent organisational units. On the other hand, using the class BMM::OrganisationUnit in DMN would require extending it (i.a. to make it a subclass of BusinesContextElement, and thus of DMNElement),which does not make much sense, since BMM;;OrganisationUnit, like DMN::OrganisationalUnit, is a placeholder, "anticipating a defnition to be adopted from other OMG meta-models, such as OMG OSM when it is further developed".
    So that neither change is worth the effort.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

No way to write a date/time literal in simple FEEL

  • Key: DMNFTF-11
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    one must write something like date("2001-09-11") but this is technically an invocation of a builtin (not a BKM) which is not allowed at level 2

  • Reported: DMN 1.0b1 — Thu, 1 Aug 2013 16:37 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    We need to allow an invocation with a string literal argument to be a simple literal. This will allow typographical date/time literals to be used in S-FEEL and in FEEL range expressions.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

locationURI, in Import MUST be in URI format

  • Key: DMNFTF-8
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    Update 10 says only that it is a string.

  • Reported: DMN 1.0b1 — Thu, 1 Aug 2013 14:30 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    already applied to alpha/beta specs

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Figure 2 is misleading

  • Key: DMNFTF-7
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The figure shows 3 levels:
    1. DRD
    2. boxed expressions
    3. FEEL

    and groups 1&2 as notation.

    The problem is, FEEL is both notation and semantics.

    The figure shows the FEEL semantic function, and thus is highlighting the semantic aspect of FEEL. The fact that the cells in the boxed expressions contain FEEL syntax is not highlighted.

    The figure could be improved in one of 2 ways:
    1. rename the callout from 'Expression Language (FEEL)' to 'Execution Semantics'. This more accurately describes the FEEL(...) in the dotted ovals, or
    2. delete the FEEL(...) in the dotted ovals. Instead, callout some FEEL expressions from above, e.g., Application.Date - Application . Applicant Date of Birth, not(UK), <18, etc.

  • Reported: DMN 1.0b1 — Sun, 7 Jul 2013 22:16 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Implement improvement 2 from the description.

    Also, there is a problem in the boxed invocation. The cell with

    Application.Date - Application.Applicant Date of birth

    does not result in a numeric age (it results in a days and time duration).

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Propose to remove "type" from KnowledgeSource

  • Key: DMNFTF-10
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    KnowledgeSource has a"type" attribute that is not explained or documented anywhere, only mentioned in table 13.

    I propose that we remove it from DMN 1.0: KnowledgeSources may have a description, anyway, since they are DMNElements.

  • Reported: DMN 1.0b1 — Thu, 1 Aug 2013 14:38 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Explain the intent of type.

  • Updated: Tue, 21 Apr 2015 01:19 GMT


8.3.2 accidentally mandates horizontal orientation

  • Key: DMNFTF-239
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In clause 8.3.2, as revised by Issue 54 resolution, the last paragraph before Table 24 reads:
    "In a tabular representation of the containing instance of DecisionTable, the representation of an instance of Clause depends on the orientation of the decision table. For instance, if the decision table is represented horizontally (rules as row, see section 7.2.2), instances of Clause are represented as columns, ... All the instances of Clause made of a set of inputEntry (that is, the input clauses), MUSTSHALL be represented on the right left of any instance of Clause made of a set of outputEntry (or output clauses)."
    This "For instance" suddenly becomes a rule, and it is only true when the table is represented horizontally. When the table is represented vertically (which is a different "for instance"), the inputs must be ABOVE the outputs, not to the LEFT of them.
    The text should be corrected to give both rules, or neither.

  • Reported: DMN 1.0b1 — Wed, 6 Aug 2014 15:58 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    separate inputs and outputs

    inputs before outputs in horizontal tables - not explicit

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Editorial corrections followup to Issue 99

  • Key: DMNFTF-238
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    I attach proposed editorial corrections to the replacement text adopted as the resolution to Issue 99.

  • Reported: DMN 1.0b1 — Wed, 6 Aug 2014 15:48 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    minor wording change

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Minor issues

  • Key: DMNFTF-233
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    Lists minor issues and edits in comments, for application in the beta 5

  • Reported: DMN 1.0b1 — Thu, 31 Jul 2014 16:37 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    correct minor typos as indicated in issue attachment and comment

    correct minor typos

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Beta 5 with attachments


Decision Table Clause metamodel needs clarification

  • Key: DMNFTF-54
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    I am having trouble mapping the specified decision table notation and semantics in 8.2 to the metamodel in 8.3. Let me just interject some comments in red on some beta1 spec text:
    8.3.2 Decision Table Clause metamodel
    In a decision table, a clause
    clause is a new term that is not used in the definition of the notation or semantics in 8.2. I am neutral about whether or not this is a useful concept/name (some old DT literature calls these 'stubs'). As suggested below, this should really be an abstract superclass of what we are elsewhere calling inputs and outputs (if needed at all) specifies a subject this italicized term implies it should be defined somewhere, or used in the MM, but it is not, which is defined by an input expression good, input expression is defined and used extensively and I think consistently throughout the spec or an output domain this is an undefined term. I think output values may be intended, and the finite set of the sub-domains of the subject’s domain that are relevant for the piece of decision logic that is described by the decision table the italics are mine, this time. I think input values are intended here.
    In DMN 1.0, the class Clause is used to model a decision table clause.
    An instance of Clause is made of an optional inputExpression and of a set of inputEntry, or of an optional name and a set of outputEntry, which are instances of Expression. A Clause element MUST have a set of inputEntry if it has an inputExpression, it MUST have a set of outputEntry if it does not have an inputExpression. A Clause element MUST NOT have both inputEntry and outputEntry
    An instance of Clause may have a name, which is a String, and it may reference an outputDefinition, which is an ItemDefinition element. An instance of Clause that does not have an inputExpression MUST reference an outputDefinition. An instance of Clause that contains an inputExpression MUST NOT reference an outputDefinition. If a Clause element that references an outputDefinition does not have a name, its default name is the name of the referenced ItemDefinition element.
    .It seems this could be represented more succinctly as 2 disjoint subclasses, Input(Clause) and Output(Clause). I think the outputDefinition is required iff output values are present in the decision table
    The valueDefinition of an inputEntry element MUST be Boolean an example inputEntry is [21..35[ and this certainly is not Boolean and it MAY be omitted. The inputEntry elements MUST test the value of its containing clause’s inputExpression, possibly implicitly. The inputExpression is something like age and the inputEntry is something like [21..35[. The execution semantics are defined by mapping to FEEL age in [21..35[. But this FEEL in expression is not stored explicitly in the MM!
    ...
    In a tabular representation of the containing instance of DecisionTable, the representation of an instance of Clause depends on the orientation of the decision table. For instance, if the decision table is represented horizontally (rules as row, see clause 8.2.2), instances of Clause are represented as columns, with the inputExpression or the name of the Clause element represented in the top cell, its domain of value optionally listed in the cell below, and each of the cells below representing one of the inputEntry or outputEntry in the Clause. All the instances of Clause made of a set of inputEntry, MUST be represented on the right of any instance of Clause made of a set of outputEntry.The above paragraph is concerned with linking the notation and the MM. This is made more difficult due to the introduction here of a new concept Clause, which is not defined where the other notation elements of input expression, input entry, etc. are defined in 8.2. Also, not all of the notation elements from 8.2 are accounted for here by name (e.g. input values, output values, and compound (multiple) output. We should not re-specify the notation here using different terminology from 8.2. We should use the same terminology to make the linkage between MM and notation simple, obvious, and complete

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 22:58 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Proposed edits in the text of the Clause and DecisionRule metamodel descriptions (sections 8.3.2 and 8.3.3) to better align the terminology with section 8.1 and 8.2.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Shorthand notation for vertical tables needs clarification/correction

  • Key: DMNFTF-53
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    This section raises a few related issues, listed below:

    1. In Fig 35, the labels 'output entry a', 'output entry b', 'output entry c' should instead be 'output value 1a', 'output value 1b', 'output value 1c'
    2. It is misleading that the column with optional input/output values in Fig 36 is dropped in Fig 35. This column is optional independent of whether or not the 'shorthand' is employed. I think it should be possible to use the shorthand and also display the allowed values for the inputs (e.g. input value 1a, ...), but this might look ugly. Either way, we need to specify this clearly.
    3. Why call this format a 'shorthand'? It is really limited-entry outputs. Whether or not it is 'shorter' depends on application values. It is curious that we previously (in 8.2.8) dismiss limited-entry inputs as not interesting. It seems no more or less interesting than limited-entry outputs.
    4. The metamodel has no attributes that distinguish whether or not to use the shorthand. So whereas we interchange a DT's orientation, we do not interchange whether to use 'shorthand' output entries or not.
    5. Because the metamodel uses a Clause for both inputs and outputs, we could add a boolean 'limitedEntry' attribute to Clause and thereby support limited entry inputs and outputs. There is something appealing about supporting limited entry for both inputs and outputs, or for neither.
    6. Limited entry seems to work for both horizontal and vertical orientation. Why limit to vertical?
    7. There is nothing that states that every rule must have exactly 1 'X' in its limited output entry cells. I think we must say that, in Fig 35, 'output entry 1a' is the column of 3 cells containing, from top to bottom, 'X', '-', '-'. The constraint is that exactly 1 of the output entry's cells must contain an 'X', and the others must contain a '-'.
    8. Why use '-' instead of a blank cell? '-' means something different in input entries.
  • Reported: DMN 1.0b1 — Tue, 11 Feb 2014 23:36 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Clarify shorthand notation for vertical tables with revised text and figures.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Decision Table input and output values not labeled consistently and should not be italicized

  • Key: DMNFTF-55
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In figs 31, 32, 33, 34, we have 'input value 1a', 'output value 1a' etc whereas in figs 27, 28, 36 we only have 'value 1a', etc for both input values and output values.
    Also, we should not use italics to represent an optional cell because italics are used to represent a typographical string literal.

    In addition, the revised text corrects many related decision table issues and includes many editorial improvements.

  • Reported: DMN 1.0b1 — Thu, 13 Feb 2014 19:56 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Input and output entries labeled consistently.
    Cells indicated in inverse are optional.
    Numerous related decision table issues are resolved.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

7.1 contains mistaken reference to 8.3

  • Key: DMNFTF-58
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    should this be 10.2.1.7?

  • Reported: DMN 1.0b1 — Wed, 19 Feb 2014 22:41 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Revise reference.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

The tables in 10.3.4.2 - 10.3.4.4 need heading row as in 10.3.4.1

  • Key: DMNFTF-56
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The heading row, with column heads Name(parameters), Parameter Domain, Description, Example should be present in all 4 tables.

  • Reported: DMN 1.0b1 — Wed, 19 Feb 2014 21:10 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Copy the header from the table in 10.3.4.1 onto the tables in 10.3.4.2, 10.3.4.3 and 10.3.4.4.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Semantics of equality should be clarified

  • Key: DMNFTF-25
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In the semantic domain, we use boldface '=' to mean identity. But in FEEL syntax, italic '=' is specified in 9.3.2.11, primarily in table entries for grammar rule 51.a.

    (side comment: all the tables in 9.3.2.11 need table numbers.)

    Also confusingly, the semantic mapping table entry for 51.a where FEEL Syntax is 'e1 < e2' also applies to 'e1 = e2'. This must be clarified.

    To avoid doubt about whether '=' means equals or identical, we should write identical(a,b) (or 'a is b') instead of a=b when inquiring whether or not 2 elements of the semantic domain are identical. For example,

    identical("1", 1) is false

    "1" = 1 is null

    We should clarify the existing rules that imply that

    1/0 = null is true

    1/0 = 1/0 is null

    1/0 != 1/0 is null

    1/0 != null is false

    1/0 in (0, null) is true

    By symmetry, we should also have

    null = 1/0 is true

    null != 1/0 is false

    The semantic rules don't explicitly cover the symmetry.

    Semantics of if/then/else must be clarified as 'if identical(test, true) then ... else ...' A true test result will return the interpreted then part. A false or null (or anything other than true) test result will return the interpreted else part. Similarly, a list filter retains list items where the test is true and omits items where the test evaluates to anything other than true.

  • Reported: DMN 1.0b1 — Thu, 2 Jan 2014 23:42 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Revise FEEL semantics in clause 10.3 as indicated.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

No builtin or operator for string concatenation.

  • Key: DMNFTF-24
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    I think the intent was to overload '+', so that

    1 + 1 = 2

    "1" + "1" = "11"

    "1" + 1 = null (incompatible input types)

    If so, then we need to add a row in the table on pg 119 of the revised submission to account for the string case.

  • Reported: DMN 1.0b1 — Thu, 2 Jan 2014 23:12 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Overload '+' for string concatenation

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Definition of Authority Requirement

  • Key: DMNFTF-27
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    From Ron Ross:

    In the glossary (p. 166), the definition of "Authority Requirement" reads "The dependency of a decision or business knowledge model on a knowledge source which provides a source of authority for the decision logic.".

    Figure 13, however, shows two Authority Requirement dependencies in which knowledge source is the dependent item. So Input Data and Decision can provide a source of authority for the knowledge source. This seems confirmed by the text under "b" at the bottom of p. 34.

    Point 1. The definition appears to need revision.

    Point 2. To say "Input Data and Decisions can provide sources of authority for analytic models." seems to me to be really stretching the English language. I've never heard anyone in either business or IT say something like that. Perhaps this is aimed at some Community I'm not familiar with? It seems like over reduction, or over abstraction, or over something, to me.

    Thx,

    Ron

  • Reported: DMN 1.0b1 — Wed, 6 Nov 2013 14:50 GMT
  • Disposition: Duplicate or Merged — DMN 1.0
  • Disposition Summary:

    We agreed it is a duplicate of the other issue

  • Updated: Tue, 21 Apr 2015 01:19 GMT

MM in figure 26 does not share InformationItems for shared InputData and Decisions

  • Key: DMNFTF-26
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Consider a DRD with 10 decisions that all require the same InputData I. The DRD will have 10 InformationRequirement arrows, and the MM will have 10 InformationRequirement instances. Because, according to Fig 26, the InformationRequirement owns the InformationItem, then there will be 10 (hopefully) identical copies of the InformationItem for I. Why is this a good idea? What happens if the 10 copies diverge in value?

    Proposal: InputData and Decision should own the InformationItem that denotes their output.

  • Reported: DMN 1.0b1 — Tue, 12 Nov 2013 20:56 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    The revised text does not completely resolve the issue, but it reflects agreement that imported DRD elements may need to be referenced by something more than a simple Name.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

variable should be optional in InformationRequirement

  • Key: DMNFTF-34
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    According to the beta, the "variable" attribute is mandatory in the definition of an InformationRequirement.

    However, it is useful only if the decisionLogic of the requesting Decision element is defined AND that decisionLogic uses the corresponding InformationItem.

    It is not blocking to have to create and carry around the InfoItem anyway, but it is inconvenient. There is a risk that validating implementations will reject models where the unused variables are not defined.

  • Reported: DMN 1.0b1 — Tue, 21 Jan 2014 15:50 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Propose to make variable optional in InformationRequirement (so you do not have to create and interchange it, e.g. when no decision logic is specified that uses it)

  • Updated: Tue, 21 Apr 2015 01:19 GMT

inconsistent use of term 'average' and 'mean'

  • Key: DMNFTF-36
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The FEEL builtin is called 'mean' but when aggregation is defined, and in the MM, 'average' is used.

  • Reported: DMN 1.0b1 — Thu, 23 Jan 2014 19:54 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Replace "average" with "mean"

  • Updated: Tue, 21 Apr 2015 01:19 GMT

No way to associate to a Decision the ItemDefinition of its outcome without defining decisionLogic

  • Key: DMNFTF-35
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    Whereas the items from InputData can be defined by associating an ItemDefinition to the InputData element, the only way to define the outcome of a decision is by associating a decisionLogic to the Decision, and an ItemDefinition to the decisionLogic.

    Proposal: Add an outcomeDefinition association that is an ItemDefinition to Decision, and make the itemDefinition of a decisionLogic a derived attribute (or otherwise constrain the itemDefinition of the decisionLogic to be the same as the outcomeDefinition of the owning Decision).

  • Reported: DMN 1.0b1 — Tue, 21 Jan 2014 16:02 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Proposed resolution to add an optional outputDefinition attribute to the Decision element, and to require that the output definition of a decision be the same as the item definition of its decision logic, if they are all specified.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

FEEL filter should not result in singleton list

  • Key: DMNFTF-29
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    given a list L = [10, 20, 30]

    L[1] = 10

    L[item = 10] = [10]

    L[item = 10][1] = 10

    Proposed:

    L[item = 10] = 10

    Note that because a non-null non-list element is treated as a singleton list when used in a list context, the following still holds:
    L[item = 10][1] = 10

  • Reported: DMN 1.0b1 — Mon, 28 Oct 2013 22:40 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Singleton list is equal to its content

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Tools may support only a subset of hit policies

  • Key: DMNFTF-28
  • Status: closed  
  • Source: K.U. Leuven ( Mr. Jan Vanthienen)
  • Summary:

    7.2.11 Hit policy

    p. 74

    "Tools may support only a subset of hit policies, but the table type must be clear and therefore the hit policy indication is mandatory."

    The empty subset is not considered valid.

  • Reported: DMN 1.0b1 — Tue, 5 Nov 2013 00:12 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Require unique hit policy to be supported.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

cannot interchange input data style

  • Key: DMNFTF-31
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    We have 2 notations for input data

    1. an oval shape

    2. the name of input data in the requiring decision (so-called Listed Input Data)

    As far as I see, there is nothing in the MM to distinguish these cases,

    so there is no way to interchange the intended notation.

    Proposed: add a new attribute to Decision named listedInputData of type boolean.

  • Reported: DMN 1.0b1 — Sat, 9 Nov 2013 00:33 GMT
  • Disposition: Deferred — DMN 1.0
  • Disposition Summary:

    Defer the issue. Everything else related to interchanging the notation and layout as been deferred (except decision table orientation).

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Beta 1 specification

  • Key: DMNFTF-32
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Convert the 'alpha' DMN submission into an OMG specification. Only boilerplate and formatting may change. There will be no changes to technical material. This will give a more appropriate baseline for subsequent change proposal.

  • Reported: DMN 1.0b1 — Mon, 20 Jan 2014 18:10 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Change from submission to OMG spec boilerplate.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Unary builtins with a list argument (e.g. minimum) should be n-ary.

  • Key: DMNFTF-30
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    For example, in addition to minumum([1,2]) FEEL should accept minimum(1,2). In both cases, the result is 1.

  • Reported: DMN 1.0b1 — Mon, 28 Oct 2013 22:21 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    make the following builtins n-ary: min, max, sum, mean, and, or

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

RFC-2119 language

  • Key: DMNFTF-61
  • Legacy Issue Number: 19212
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Congratulations on using RFC-2119 language pretty consistently ("must", "should" etc). However, if the spec ever gets sent to ISO, it would have to switch to ISO language. The main difference is that ISO insists on "shall" instead of "must". Fortunately, "shall" is also in RFC-2119, so by switching all instances of "must" to "shall", you can comply with both. See: http://isotc.iso.org/livelink/livelink?func=ll&objId=4230456

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Replace all occurrences of "MUST" with "SHALL", many occurrences of "should" with "SHOULD".

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Normative References section incomplete

  • Key: DMNFTF-60
  • Legacy Issue Number: 19211
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    The Normative References section is very incomplete. The specification includes parts of JSON, PMML and Java by reference, so we need references to their defining documents. There are probably others too.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    The Normative References list is modified to reflect all specifications that are normatively referenced in the body of the DMN specification. Some references in the body of the specification are corrected to refer to the names of the normative references introduced in Clause 3.

    The reference to IETF RFC 2119 is deleted, because the requirements keywords have been changed to those mandated by ISO Directives.

    The sole reference to RIF, in Annex A, is not normative, and apparently refers to the RIF-PRD specification as a relative of OMG PRR.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

FEEL grammar should define precedence of boxed expressions

  • Key: DMNFTF-49
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    It is unclear whether the following is syntactically correct

    {x:1}.x=1

    or whether the following must be used:

    ({x:1}).x=1

    The intent is that both are correct.

  • Reported: DMN 1.0b1 — Sun, 9 Feb 2014 19:22 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Split grammar rule 1 into 1a and 1b and note in the 'Additional Syntax Rules':

    Operator precedence is given by the order of the alternatives in grammar rules 1, 2 and 4. E.g., (boxed) invocation has higher precedence than multiplication, multiplication has higher precedence than addition, and addition has higher precedence than comparison. Addition and subtraction have equal precedence, and like all FEEL infix binary operators, are left associative.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

unary test is not a legal standalone FEEL expression

  • Key: DMNFTF-52
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Grammar rule 2i shows:

    i. literal | unary test | name | "(" , textual expression , ")" ;

    A unary test such as "-" or "not(1,3)" can only be used as notation within a decision table condition cell and do not directly map to the semantic domain. For example, the following is not valid:

    not(1)=0

    Proposal: replace grammar rule 2i with

    i. literal | simple positive unary test | name | "(" , textual expression , ")" ;

    Note: make corresponding change in simple feel and review the mappings of "-" and "not" to ensure they map to FEEL that does have valid syntax and semantics.

  • Reported: DMN 1.0b1 — Sun, 9 Feb 2014 19:57 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    change grammar rule 2i in clause 10.3.1.2

  • Updated: Tue, 21 Apr 2015 01:19 GMT

remove "smartquotes" from grammar rule 17 b,c

  • Key: DMNFTF-51
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    grammar rules have msword artifacts by mistake.

  • Reported: DMN 1.0b1 — Sun, 9 Feb 2014 19:44 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    replace 'smartquotes' with regular quotes

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Grammar rule 51c should require parentheses around multiple tests

  • Key: DMNFTF-50
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Correct syntax should be

    color in (red, green, blue)

    not

    color in red, green, blue

  • Reported: DMN 1.0b1 — Sun, 9 Feb 2014 19:39 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    change grammar rule 51c and add 51d as proposed

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Does DMN support DRDs, Decision Tables, and Expressions independently or in combination?

  • Key: DMNFTF-40
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The paragraph is:
    Again, although Figure 2 depicts these decision modeling constructs as interlinked, it is possible to use them independently or in any combination. For example, it is possible to use DMN only to draw DRDs, or only to define decision tables, or only to write FEEL expressions.

    However, the reality is that It is not possible to interchange a DT or an expression in a standard way without a containing DRG. The DT and expression MM is in Figure 26 of the alpha/beta 1 spec. To interchange a DT or expression directly, it would need to be immediately contained in a Definitions. By the MM in Figure 16, this isn't allowed.

    Given that we do not support independent interchange, I think this paragraph in the spec is misleading. From an interchange point of view, you cannot have a 'standalone' decision table or expression. Semantically, 'standalone' expressions are usually not very interesting. Usually, expressions are interpreted in a context (which comes from the DRG, containing boxed context, formal parameters, etc.). The context must also be interchanged.

  • Reported: DMN 1.0b1 — Thu, 23 Jan 2014 23:21 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Delete the offending paragraph.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

All tables and figures should be numbered

  • Key: DMNFTF-37
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Many tables in chapter 10 are not numbered. This makes it difficult to reference these tables. They should be numbered even if they are not referenced in the spec text. Also, it seems that many tables that are numbered have their caption on top, whereas the figures have their caption on bottom. Is this intentional?

  • Reported: DMN 1.0b1 — Thu, 23 Jan 2014 20:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Number all tables in Clause 10.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

cannot parse date/time/duration ranges

  • Key: DMNFTF-41
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    A date range can be written (using typographical literals) as, e.g., [2012-01-01Z..2013-01-01Z)
    This is defined to be [date("2012-01-01Z")..date("2013-01-01Z")). The grammar rules do not permit range endpoints to be invocations. We need to slightly generalize the syntax to support typographical literals without allowing arbitrary expressions (which causes difficulty because '[ expr' also looks like the start of a list).

  • Reported: DMN 1.0b1 — Thu, 23 Jan 2014 23:58 GMT
  • Disposition: Duplicate or Merged — DMN 1.0
  • Disposition Summary:

    adding 'date time literal' resolves both issues

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Revise Level 1 Conformance

  • Key: DMNFTF-21
  • Status: closed  
  • Source: International Business Machines ( Mr. Dave Ings)
  • Summary:

    Opening on behalf of Barb and Larry:

    Larry and I would like to raise an issue allowing for Rule Families to be compliant for Level 1 DMN Conformance. I believe, this has always been our intent and would not be comfortable if we couldn't be Level 1 conforming.

    The good news is that I believe I have a very simple edit-change to the document that should be acceptable to all:

    Current text (page 16): An implementation claiming conformance to Conformance Level 1 shall comply with all of the specifications set forth in sections 5 (Decision Requirements), 6 (Decision Logic) and 7 (Decision Table) of this document.

    Revised text (page 16): An implementation claiming conformance to Conformance Level 1 shall comply with all of the specifications set forth in sections 5 (Decision Requirements), 6 (Decision Logic) and, if using decision tables, 7 (Decision Table) of this document.

    So, this revision preserves the decision table formats for compliance but also allows for other representations that work.

  • Reported: DMN 1.0b1 — Mon, 30 Sep 2013 15:57 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    conformance levels have been extensively discussed and level 1 shall include both DRDs and decision tables with 'uninterpreted' expressions

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

lexical structure of FEEL is underspecified

  • Key: DMNFTF-20
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    the language 'alphabet' is not directly specified. E.g. 'and' is a keyword, so is 'ham and eggs' a legal name? What about 'return date'?

  • Reported: DMN 1.0b1 — Mon, 28 Oct 2013 22:18 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    The grammar rules are fine but we need a 4th and 5th 'additional syntax rule' at the end of 10.3.1.2

  • Updated: Tue, 21 Apr 2015 01:19 GMT

give execution semantics to InputData

  • Key: DMNFTF-23
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The table in 10.4 shows that InputData is associated with a 'sample data' boxed expression. There is no such association in the metamodel. The intent is that the input data values come from 'somewhere' and are mapped to the FEEL domain AS IF the input data was given by a literal FEEL expression. For example, if the input data is XML, then the mapping is described in 10.3.3. This needs to be explained here.

  • Reported: DMN 1.0b1 — Mon, 25 Nov 2013 23:18 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    define notion of binding case data to InputData, and that the case data can be notated as a boxed expression

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:
    • FeelDMSemantics.docx 16 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

in the DMN Example in 11.3, Application Risk Score is poorly named and pre/post bureau risk category logic is implausible

  • Key: DMNFTF-22
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The problem is that higher risk scores mean lower risk. This is not intuitive, and indeed the risk category decision tables require existing customers to have lower risk (higher scores) than new customers, which is likely not the intent.

  • Reported: DMN 1.0b1 — Thu, 29 Aug 2013 05:37 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Exchange "true" and "false" in the Existing Customer column.

  • Updated: Tue, 21 Apr 2015 01:19 GMT


All Decisions have BKMs though this is not necessary

  • Key: DMNFTF-88
  • Status: closed  
  • Source: Decision Management Solutions ( James Taylor [X] (Inactive))
  • Summary:

    In the example every decision is linked to a BKM and decision tables/decision logic are specified only for the BKMs. The notation does not require a BKM for each decision and this is a common point of confusion. Those decisions that do not use reusable logic should be linked directly to decision tables instead leaving the reused logic (affordability for instance) as a BKM.

  • Reported: DMN 1.0b1 — Thu, 20 Mar 2014 21:09 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Replace figures 1 and 2.
    Changes to clause 11 (Example) are described in 193 (subtask to issue 101).

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Overlapping input entries

  • Key: DMNFTF-74
  • Legacy Issue Number: 19225
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "Decision tables with the Unique hit policy do not contain rules with overlapping input entries" should be "Decision tables with the Unique hit policy SHALL NOT contain rules with overlapping input entries". You should also specify absolutely precisely what "overlapping" means. All through this section 8.2.11, please substitute ISO/RFC 2119 language (e.g. "A single hit table returns the output of one rule only" -> "A single hit table SHALL return the output of one rule only").

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Define overlapping and disjoint rules and inputs.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Hit policy summarised in one character

  • Key: DMNFTF-73
  • Legacy Issue Number: 19224
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "the hit policy is summarized using a single character in a particular decision table cell." Please expand this sentence by saying precisely which character (i.e. the initial letter of Unique, Any, Priority, First) and which cell.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Specify precise hit policy codes and locations.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

"Evaluation of the expressions in a decision table does not produce side-effects."

  • Key: DMNFTF-72
  • Legacy Issue Number: 19223
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "Evaluation of the expressions in a decision table does not produce side-effects." Since those expressions can include calls to external Java code, this Ain't Necessarily So. Better to put this outside the scope of conforming implementations by saying something like: "Where expressions in a decision table are are expressed solely in FEEL, with no externally-defined functions, their evaluation does not produce side-effects. The behaviour of decision tables that call externally-defined functions with side-effects is undefined."

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Expand on the definition and rationale for no side-effects. We say elsewhere that externally defined functions should not have side-effects - this is true in general and is not specific to decision tables.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

preferedOrientation behaviour

  • Key: DMNFTF-78
  • Legacy Issue Number: 19229
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "An instance of DecisionTable SHOULD BE represented as specified by its preferedOrientation, as defined in clause 8.2.2." You're saying that a conforming implementation is allowed to read a Decision Model written by another tool but display it with a different orientation. This is will greatly upset users, who get very attached to graphical elements being displayed exactly as they drew them. I suggest changing this to "An instance of DecisionTable SHALL be represented as specified by its preferedOrientation, as defined in clause 8.2.2."

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    The preferred orientation is preferred and this preference is something that vendors must maintain. However it is a PREFERRED orientation so there is not requirement that it be used to display the table.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Aggregation

  • Key: DMNFTF-77
  • Legacy Issue Number: 19228
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    For "count", you need to specify carefully whether the result is the number of rules that match or the number of distinct outputs (they're different if two or more rules return equal outputs). Specify how aggregation is specified in the written decision table (I only found out from the example on a later page).

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    aggregation replaced by collect operator

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Interval rules

  • Key: DMNFTF-82
  • Legacy Issue Number: 19233
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    is in the interval [e1..e2] also noted [e1..e2], if and only if o ≥ e1 and o ≤ e1". This "also noted" subclause is redundant. The follow bullet has a typo: "is in the interval [e1..e2] also noted [e1..e2[" should be "is in the interval [e1..e2) also noted [e1..e2[" (See what I mean about those backwards brackets being confusing? .

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Revise text as indicated.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Exponentiation rule

  • Key: DMNFTF-81
  • Legacy Issue Number: 19232
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "Arthmetic exponentiation (grammar rule 4c) is defined as the multiplication of the first operand by itself as many time as indicated by the second operand. It is defined only when the first operand is a number and the second operand is an integer." Given the context, "integer" should presumably read "positive integer". But why the constraint? 1.2**3.6 is perfectly well-defined. Is there a good reason to outlaw it? Also, "Arithmetic" is misspelled.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    don't restrict the exponent to be an integer.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Output priorities

  • Key: DMNFTF-76
  • Legacy Issue Number: 19227
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "Output priorities are specified in an ordered list of values, for example, the list of expected output values." I don't understand how this is different from the "First" single hit policy, or how/where this list of output priorities is specified (other than in the rule order). Please clarify.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Clarify that the output priority is given by the order of output values.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Meaning of "same"

  • Key: DMNFTF-75
  • Legacy Issue Number: 19226
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "all of the matching rules show the same output". Please precisely specify what "same" means here (presumably all output entries are equal using the equal operator defined for their type). What happens if a table specifies "Any", but a pair of matching rules return non-equal outputs? Presumably the behaviour is undefined.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Define that 'same' means equal, and that if the hit policy is Any and two matched rules do not have equal output entries, the result is undefined.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Only comparing named dates - why?

  • Key: DMNFTF-84
  • Legacy Issue Number: 19235
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "Dates, times, and durations may be compared, but only if they have been given names" Why? Given that there is a syntax for specifying anonymous dates (e.g. date("2012-12-25")), why force dates to be named before they can be compared?

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Allow typographical date/time/durations to be compared, and use underline in Table 27 to callout the unary tests so as not to conflict with typographical styles (italic and bold italic)

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Grammar rule 9 reference

  • Key: DMNFTF-83
  • Legacy Issue Number: 19234
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "An expression to be tested satisfies an instance of simple unitary tests (grammar rule 9) ..." That "9" should be "14".

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Revise reference to grammar rule.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Sum weights of recent credit history example

  • Key: DMNFTF-85
  • Legacy Issue Number: 19236
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Are you sure this example is syntactically valid? It contains an anonymous date, which section 10.2.2.1 says is illegal (see previous issue report), and a use of [ ] that doesn't seem to have anything to do with intervals.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Add descriptions to FEEL examples in clause 10.6

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

"as many time" Typo

  • Key: DMNFTF-80
  • Legacy Issue Number: 19231
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Typo: "as many time" -> "as many times".

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Correct the typo.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

S-FEEL open interval syntax

  • Key: DMNFTF-79
  • Legacy Issue Number: 19230
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    guarantee that the syntax for open intervals that potentially involves brackets facing the wrong way will drive users crazy (e.g. "[1..5["). The alternative syntax that uses unmatched bracket types (e.g, "(1..5]") is almost as bad. There must be a better way!

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    See for example http://en.wikipedia.org/wiki/Interval_(mathematics)
    There's even an ISO standard: http://en.wikipedia.org/wiki/ISO_31-11

  • Updated: Tue, 21 Apr 2015 01:19 GMT

"Should not conflict with FEEL Syntax"

  • Key: DMNFTF-71
  • Legacy Issue Number: 19222
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Table entries "SHOULD NOT conflict with FEEL syntax" (4 places). OK, I know why you're saying this, but that "SHOULD NOT" is such a weak statement as to be useless. I suggest making it part of the conformance criteria: "At Conformance level 1, there is no restriction on table entries, which are not interpreted. However, at conformance levels 2 or 3, table entries SHALL comply with FEEL syntax".

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Add an expression language URI to indicate that expressions are not meant to be machine interpreted; edit text to introduce the URI and clarify its recommended usage.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

"HC" meaning


Rule numbering

  • Key: DMNFTF-69
  • Legacy Issue Number: 19220
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "The ordering is represented by the explicit numbering of the rules in the diagrammatic representation of the DecisionTable." This seems to be the only place that rule numbering is mentioned. Please introduce it (even if only with one sentence) in section 8.2. Specify exactly how rules are numbered (integers? Natural numbers? Any sequence with a total ordering? Is numbering mandatory? Must the numbers be sequential? Can I "number" my three-rule table "A" "B" and "M"?).

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Define rule numbers as consecutive natural numbers starting with 1.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Decision table example figures

  • Key: DMNFTF-68
  • Legacy Issue Number: 19219
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Fig 27, 28, 30, 31, 32 ... In several of these figures the "value 1a", "output entry 1a" etc labels are the same or different across rows and columns for no apparent reason. If there's no reason for them to match, please make them all different (e.g. I'm pretty sure there's no reason for putting "value 1a" in both the input and output columns in Figure 27). Otherwise it's confusing.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Split each figure into two: a schematic layout and an example, to better explain the decision table cell contents.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Decision table introduction

  • Key: DMNFTF-67
  • Legacy Issue Number: 19218
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "IF input expression 1 matches x AND ..." The word "matches" is a bit vague - I think "satisfies" would be better - and perhaps supply a couple of extra sentences saying what this means for S-FEEL and non-S-FEEL Decision Tables.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Issues 55, 66-70, and 74 all affect clauses 8.1-8.2.2. Combined revised text is attached

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Decision table examples

  • Key: DMNFTF-66
  • Legacy Issue Number: 19217
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Decision tables (section 8, p 70 onwards). Almost all the decision table examples and explanations have two input expressions. It would be worth making clearer that all decision tables (other than crosstab tables) can have 1, 3, 4 ... input expressions.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    examples with 3 inputs added

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Section 5.2 & 5.3 order

  • Key: DMNFTF-62
  • Legacy Issue Number: 19213
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    IMO sections 5.3 "Scope and uses of DMN" and section 5.2 "Basic concepts" should be in the other order. To have read section 5.3 would be useful background when first reading 5.2.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Swap sections 5.2 (Basic Concepts) and 5.3 (Scope and Uses of DMN)

  • Updated: Tue, 21 Apr 2015 01:19 GMT

"value expression of type invocation" point unclear

  • Key: DMNFTF-65
  • Legacy Issue Number: 19216
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "Using a value expression of type invocation is never required, even when possible: FEEL specifies its own invocation mechanism for more complex usages, and a FEEL literal expression can always be used instead of a value expression of type invocation." I'm not clear what point is being made here.

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DMN 1.0
  • Disposition Summary:

    The resolution of DMNFTF-13 removes the paragraph that is at issue. Nothing further to do.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

"HIGH DECLINE" example

  • Key: DMNFTF-64
  • Legacy Issue Number: 19215
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    'To avoid having to discerning whether HIGH, DECLINE is "HIGH" "DECLINE" or "HIGH, DECLINE", typographical string literals should be free of "," characters.' Why not "SHALL be free of" commas? Also, broken grammar: "having to discerning".

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Ban commas from typographical string literals and correct grammar.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Dottedness of dotted lines

  • Key: DMNFTF-63
  • Legacy Issue Number: 19214
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    fig 22 - The dotted line style used in this figure, and throughout the specification is indistinguishable from a solid line on my printer. Make the "dottedness" more apparent?

  • Reported: DMN 1.0b1 — Wed, 12 Feb 2014 05:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Dotted lines are too hard to distinguish in some renderings. Use solid lines instead.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Reference to DMN elements in XML files may be ambiguous

  • Key: DMNFTF-99
  • Status: closed  
  • Source: International Business Machines ( Mr. Christian De Sainte Marie)
  • Summary:

    DMN elements are referenced by their ID with the same file, and by a QName built from a prefix and their ID, where the prefix in the QName must be assigned to the namespace of the Definitions element that contains the referenced element.

    However, two different definitions in two different XML files may be in the same namespace: since ID are unique only within their XML file, two different DMN elements can, therefore, have the same reference.

    One way to repair that would be by using a bare name XPointer as the value of an XLink href attribute instead, for referencing DMN elements, where the XPointer would consist of the URL of the file containing the Definitions suffixed with the element's ID (separated by #).

  • Reported: DMN 1.0b1 — Tue, 1 Apr 2014 14:50 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Replacement for 12.3.2: Proposes to use href attribute w/o XLink with bare Xpointers to reference DMN elements that may need be referenced across Definitions elements (and thus across XML files).

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Decisions are said to have "inputs" and "outputs", however only the "inputs" are shown in the diagrams

  • Key: DMNFTF-102
  • Legacy Issue Number: 19331
  • Status: closed  
  • Source: MITRE ( Mihail Popov)
  • Summary:

    The definition of "Decision" on page 23, section 5.2.1 defines "Decision" as an activity ("act"). It mentions a Decision has an "output" value, however, an "output" shape coming out from the decision activity is not shown in the diagrams.

    It may be useful to draw and show an output shape coming out from the Decision box. That could be named "Decision output".

    This suggestion applies to Figures 1, 2, 3, 4, 5 and other similar diagrams. While the value of the decision output may not need to be explicitly depicted on all BPMN process diagrams and on other diagrams, at least the initial few diagrams where the concepts are defined it should be depicted explicitly.

    On Figure 1, in the Decision Model area, the dotted line connecting this area to the BPMN model should have a label such as "Routing Decision Output" (which the BPMN diagram implicitly assumes has a value of "ACCEPT" or "DECLINE". Similarly, diagrams 2, 3, 4, and 5 could have an "Decision Output" coming out of the Decision box and connected to it with an arrow pointing from the Decision shape to the Decision Output shape.

  • Reported: DMN 1.0b1 — Tue, 8 Apr 2014 04:00 GMT
  • Disposition: Closed; No Change — DMN 1.0
  • Disposition Summary:

    We do not want every decision (including sub-decisions) to have both a decision symbol (rectangle) and some symbol for the output. This would add clutter for no reason, because every decision has exactly 1 output. We discussed the possibility of having only the 'top' decision(s) show an output, but again, this is not needed and it is possible to discern the top decisions - those that are not required by any other decision.
    Finally, we note that decisions have much metadata that can be used to link decisions to BPM activities, provide business motivation, etc. There is no standard notation for much of this metadata, so as not to over-constrain tools.

  • Updated: Tue, 21 Apr 2015 01:19 GMT

DMN Example should not be limited to automated decisions

  • Key: DMNFTF-101
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    The overall process is (up to) 3 top-level decisions:
    1. decide strategy
    2. decide routing
    3. review application and decide to Accept or Decline
    Why do we not model the 3rd decision (to some level of detail) and associate it with the human task just like other decisions are associated with the business rule tasks?

  • Reported: DMN 1.0b1 — Tue, 8 Apr 2014 19:11 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Update DMN Example with human decisions (and decisions without BKMs)

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Clarify Authority Requirement notation

  • Key: DMNFTF-92
  • Legacy Issue Number: 19290
  • Status: closed  
  • Source: Knowledge Partners, Inc. ( Paul Vincent)
  • Summary:

    It is unclear (i.e. unspecified) what are the use cases for connecting Knowledge Sources to Decisions versus Knowledge Sources to Business Knowledge (models) in the cases where the Knowledge Source is the Authority for the Decision or Business Knowledge (model). The text does not make the case for either scenario in DRDs containing all 3 entities.

    Example: Customers may connect a Knowledge Source as the authority to either or both the Decision or its related Business Knowledge (model).

    Suggested resolution: A table defining the use cases for connecting a Knowledge Source to a Decision, Business Knowledge (model)

  • Reported: DMN 1.0b1 — Wed, 19 Mar 2014 04:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Replace the text of clause 6.2.3 as follows:

  • Updated: Tue, 21 Apr 2015 01:19 GMT

DRD connection rules have no graphical key

  • Key: DMNFTF-91
  • Legacy Issue Number: 19289
  • Status: closed  
  • Source: Knowledge Partners, Inc. ( Paul Vincent)
  • Summary:

    Confusion over the notation has been propagated even before the DMN spec is finalised. For example see http://www.slideshare.net/alcedocoenen/intro-dmn-10 slide 19 which was a conference presentation on DMN gives incorrection notation interpretation. Another example was a customer version of a DMN DRD that demonstrated confusion over the shape and connector meanings.

    Suggested resolution:
    Add a graphical notation to the text of the cells in table in chapter 6.2.3 pg 35 showing shape-connector-shape to avoid any possible misinterpretation

  • Reported: DMN 1.0b1 — Wed, 19 Mar 2014 04:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Add graphical notation to the text in the table in 6.2.3

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Data Input notation specification and useage

  • Key: DMNFTF-94
  • Legacy Issue Number: 19292
  • Status: closed  
  • Source: Knowledge Partners, Inc. ( Paul Vincent)
  • Summary:

    Input Data entity definition appears to be quite sparse versus the data specification requirements likely to be needed in decision modelling. Also not well represented in the ch 11 DMN Example where it is used there for input samples rather than input specifications.

    Example: an end user defined a DRD and labelled the Input Data in their DRD with the name of the XSD of the data source. They then questioned how to annotate an Input Data with a specific named XSD - especially is the input data is constrained to a 3rd party format (such as an industry standard that is specified as an XSD), which they considered (as a tag) a business level concept, even if the details of the XSD might not be.

    Suggestion: Input Data should be more vigorously defined e.g. as a specification of input data / source (message, invocation, etc) associated with Boxed Invocation, maybe renamed Source of Data. Sample Data could be specified as a Knowledge Source for Input Data. Specifications of the format (e.g. industry XSDs) of Input Data could also be Knowledge Sources

  • Reported: DMN 1.0b1 — Wed, 19 Mar 2014 04:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    Distinguish input data from case data.

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Boxed Invocation has sparse references after definition

  • Key: DMNFTF-93
  • Legacy Issue Number: 19291
  • Status: closed  
  • Source: Knowledge Partners, Inc. ( Paul Vincent)
  • Summary:

    Boxed Invocation is defined in Ch7.2.3. In Ch8 Decision Table "builds on" Ch7 but has no reference to Boxed Invocation (e.g. while one might expect a reference with regard to invocation of Decision Tables). Likewise Annex B refers to Decision services but has no reference to Boxed Invocations.

    Example: an end-user defined a DRD and associated Decision Tables (to reflect BKMs) expected to have to define Boxed Invocations to represent the interface to Decision Tables.

    Suggested solutions:
    1. Either add an explanation that Boxed Invocations are conceptual and only relevant to FEEL, or add how they are represented when defining Decision Tables (Ch8) and in the DMN Example (Ch11) and Annex on Decision Services (Ann B).

    2. Show the DMN XMI model for the DMN example relating the example to the metamodel concepts in preceding chapters including Boxed Invocations.

  • Reported: DMN 1.0b1 — Wed, 19 Mar 2014 04:00 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    In order to make it more explicit which figures in clause 11 are boxed invocations, in 11.3, change 'invokes' to 'is a boxed invocation of'

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Can decision tables have zero inputs?

  • Key: DMNFTF-95
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    It is not clear from the spec whether it is valid to have a decision tables with no inputs. In such a table all rows would always be true (i.e. facts, rather than rules). This would be useful on occasions, e.g. for generating a list of items to be filtered in subsequent decisions (although it would be possible to provide the same functionality using boxed contexts or raw FEEL).

    Is this valid? If so we need to provide an example.
    If not the spec needs to be clarified anyway.

  • Reported: DMN 1.0b1 — Tue, 25 Mar 2014 12:15 GMT
  • Disposition: Duplicate or Merged — DMN 1.0
  • Disposition Summary:

    0 input decision tables are explicitly allowed in beta3 (there is no example)

  • Updated: Tue, 21 Apr 2015 01:19 GMT

Some editorial changes

  • Key: DMNFTF-248
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    After careful review, we have found several minor wording changes to the final DMN specification that have been (or soon will be) made but do not have approved editing instructions. The resolution to this issue will provide thtese instructions.

  • Reported: DMN 1.0b1 — Mon, 3 Nov 2014 00:52 GMT
  • Disposition: Resolved — DMN 1.0
  • Disposition Summary:

    minor edits

    see attached

  • Updated: Tue, 21 Apr 2015 01:19 GMT
  • Attachments:

Change Tracking Document


Incorporate AB feedback into the FTF Report, the marked-up specification, and the clean specification

  • Key: DMNFTF-245
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    In the FTF Report,
    for DMNFTF-6 and DMNFTF-17, use the format Replace <old text> with <new text>,
    for DMNFTF-93, also use Replace/with, and identify the old text as all occurrences of invokes in 11.3, and
    for DMNFTF-221, describe the change as a restoration of the relative text positions that were unintentionally changed by a prior edit.

    In the specification,
    make changes to mark-up and comments as described in the subtask (issue 246).

  • Reported: DMN 1.0b1 — Sat, 13 Sep 2014 20:37 GMT
  • Disposition: Deferred — DMN 1.0
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was deferred to the next Task Force

  • Updated: Fri, 6 Mar 2015 20:57 GMT
  • Attachments: