1. OMG Mailing List
  2. Decision Modeling and Notation 1.1 Revision Task Force

All Issues

  • All Issues
  • Name: dmn-rtf
  • Issues Count: 235

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN12-212 Lexical representation of time string has ambiguous definitons DMN 1.1 open
DMN12-129 Would like to use duplicate shapes/names in diagram to avoid multiple requirement line crossings DMN 1.1 open
DMN12-20 Add Diagram Interchange to DMN DMN 1.0 open
DMN12-211 Table 45 does not provide the semantic of addition and subtraction between elements of type Date and Duration DMN 1.1 open
DMN12-44 Change depiction of Input to be harmonized with BPMN and CMMN DMN 1.1 open
DMN12-204 Clarification needed if null is passed as value for optional parameter of built in function DMN 1.1 open
DMN12-203 Wrong chapter reference for date and time / date and time subtraction DMN 1.1 open
DMN12-205 Improve description of built-in function string() DMN 1.1 open
DMN12-210 Expected behavior for list/sort built-in functions in combination with singleton lists DMN 1.1 open
DMN12-115 mix up of list and non-list in filter expression example DMN 1.1 open
DMN12-209 Formally define enumerations and use throughout DMN 1.1 open
DMN12-38 Show diagram elements with hidden links DMN 1.1 open
DMN12-13 Need group artifact in DRD, metamodel, and XSD DMN 1.0 open
DMN12-39 Show implied Information Requirements DMN 1.1 open
DMN12-27 Lack of visual notation for processing of / iteration over lists DMN 1.1 open
DMN12-207 Imprecise result for example calculation of function PMT and may be typo or rounding issue DMN 1.1 open
DMN12-206 Invalid example for date and time property access DMN 1.1 open
DMN12-202 Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration DMN 1.1 open
DMN12-201 Type should be specified for date, time and duration properties DMN 1.1 open
DMN12-195 Parameter names of built-in function date and time(date, time) are not allowed by name rules DMN 1.1 open
DMN12-48 SFEEL makes too few people happy DMN 1.1 open
DMN12-5 Consider date and time datatype in S-FEEL DMN 1.0 open
DMN12-189 Table 45 does not provide the semantic of addition and subtraction between two elements of type date DMN 1.1 open
DMN12-186 Wrong length range check for built-in function sublist() and substring() DMN 1.1 open
DMN12-187 Parameter domain for built-in function years and months duration() is wrong DMN 1.1 open
DMN12-184 Semantic mapping for XML syntactical artifacts DMN 1.1 open
DMN12-77 DMN v1.2 specification DMN 1.1 open
DMN12-197 No adjustment for last day in month if duration is added/subtracted to date and time value DMN 1.1 open
DMN12-10 While BKMs enable re-use, the options for re-use are restricted to single pieces of decision logic DMN 1.0 open
DMN12-49 Include Test Cases in Decision Model DMN 1.1 open
DMN12-29 Generalized Unary Tests DMN 1.1 open
DMN12-30 Expressions in Input Entries DMN 1.1 open
DMN12-89 Label versus name attribute DMN 1.1 open
DMN12-196 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 open
DMN12-40 Spaces in FEEL builtin functions DMN 1.1 open
DMN12-162 FEEL precedence for function definition DMN 1.1 open
DMN12-58 Space in FEEL names is not well-specified DMN 1.1 open
DMN12-160 Metamodel is missing the "kind" attribute on function DMN 1.1 open
DMN12-141 Unclear meaning of unique name constraint for ItemDefinitions and DRGElements DMN 1.1 open
DMN12-87 some/every ... satisfies not defined for empty list DMN 1.1 open
DMN12-33 Scope of Variables in Context Boxed Expression DMN 1.1 open
DMN12-176 Decision Table hit policies C and C# should not return null when there are no matches DMN 1.1 open
DMN12-175 Different definition of hit policy collect aggregations in FEEL and DMN DMN 1.1 open
DMN12-101 Requirements don't have an ID (needed for DI) DMN 1.1 open
DMN12-155 Supporting text about Expression lists non-existing name attribute DMN 1.1 open
DMN12-149 Output Order hit policy on pg 85 is incorrect DMN 1.1 open
DMN12-143 Inconsistencies between metamodel and xsd schema DMN 1.1 open
DMN12-134 Add id to context entry DMN 1.1 open
DMN12-124 Return All Annotations for All Hit Policies DMN 1.1 open
DMN12-190 DMN built-in functions are missing to ensure business friendliness DMN 1.1 open
DMN12-188 semantics of import is unspecified DMN 1.1 open
DMN12-183 Missing type names in FEEL functions (user and external) DMN 1.1 open
DMN12-110 FEEL grammar readbility DMN 1.1 open
DMN12-161 Specification of type for instance of operator misses information DMN 1.1 open
DMN12-68 DMN 1.1 XML schema starts with ZERO WIDTH NO-BREAK SPACE (U+FEFF) DMN 1.1 open
DMN12-173 More Generic Ways to Define Decision Table Properties DMN 1.1 open
DMN12-172 Scope of decision table input/output entries is not well defined in the specification DMN 1.1 open
DMN12-117 Need additional FEEL Types DMN 1.1 open
DMN12-170 Ambiguity between qualified name and path operation DMN 1.1 open
DMN12-168 Is really only name allowed in a FEEL path? DMN 1.1 open
DMN12-169 How to get FEEL type if evaluation is not an option? DMN 1.1 open
DMN12-171 Can an expression in user defined function body reference a name outside of it's scope? DMN 1.1 open
DMN12-167 Missing semantic specification for FEEL for and quantified expression DMN 1.1 open
DMN12-166 Should name declarations in same context fail or overwrite? DMN 1.1 open
DMN12-165 Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test DMN 1.1 open
DMN12-164 Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122 DMN 1.1 open
DMN12-163 FEEL grammar is ambiguous for grammar rule 2.i simple positive unary test when no operator is specified for an endpoint DMN 1.1 open
DMN12-157 Improvement of Semantic Domains Specification DMN 1.1 open
DMN12-148 decision table structure in 8.1 does not agree with MM DMN 1.1 open
DMN12-138 Duplicate definition of BKM/@variable in Table 14 DMN 1.1 open
DMN12-137 clarify format of time literals / resolve inconsistency DMN 1.1 open
DMN12-94 Problem with QName usage in typeRef DMN 1.1 open
DMN12-88 Label of Input in decision table DMN 1.1 open
DMN12-144 Add specification for DMN diagrams layout DMN 1.1 open
DMN12-127 Missign Comma in Grammar Rule 48 (some/every...) DMN 1.1 open
DMN12-55 Attributes in tables 29a and 29b do not correspond to metamodel Fig 51 DMN 1.1 open
DMN12-103 singular helping verb used with plural subject DMN 1.1 open
DMN12-84 Decision table is not a good example of a builtin function DMN 1.1 open
DMN12-158 Page 71 states that a DT can have 0 inputs. I believe this to be incorrect DMN 1.1 open
DMN12-70 Chapter 11 example serialization has many errors DMN 1.1 open
DMN12-136 Decision Service Cannot be Shown in DRD DMN 1.1 open
DMN12-133 DRD elements must be labeled with their name DMN 1.1 open
DMN12-43 Drg element labels DMN 1.1 open
DMN12-121 Releation between Definitions and DecisionService does not specified in XSD DMN 1.1 open
DMN12-2 BigDecimal is not the only mapping of number to Java DMN 1.0 open
DMN12-147 Semantic domain mapping for simple expressions DMN 1.1 open
DMN12-132 Remove rule#32 additional name symbols from BNF DMN 1.1 open
DMN12-131 Execution Semantics of Decision Services does not explain imported elements DMN 1.1 open
DMN12-130 Can listed input data option be used in encapsulated decisions of decision service? DMN 1.1 open
DMN12-126 Chapter 11 example decision tables are incomplete DMN 1.1 open
DMN12-125 Bug in specification of the ‘Any’ Hit Policy DMN 1.1 open
DMN12-123 Requested additional built-in functions DMN 1.1 open
DMN12-122 string built-in underspecified DMN 1.1 open
DMN12-6 alternative indication of reusable logic in DRD DMN 1.0 open
DMN12-111 Additional name symbols DMN 1.1 open
DMN12-120 Spaces and additional characters in names / identifiers DMN 1.1 open
DMN12-119 Support for function calls in unary tests DMN 1.1 open
DMN12-118 FEEL does not support named ranges DMN 1.1 open
DMN12-42 FEEL operators in names DMN 1.1 open
DMN12-109 SFEEL grammar readbility DMN 1.1 open
DMN12-106 Typo in the sample xml DMN 1.1 open
DMN12-107 Missing FEEL namespace in the header of the xml sample DMN 1.1 open
DMN12-108 Naming inconsistency DMN 1.1 open
DMN12-105 Broken HTTP links DMN 1.1 open
DMN12-113 Metamodel constraints & validation DMN 1.1 open
DMN12-116 Missing "date" FEEL type in some enumerations DMN 1.1 open
DMN12-114 Broken HPP links DMN 1.1 open
DMN12-112 FEEL ambiguity DMN 1.1 open
DMN12-74 Issues with Table 61 DMN 1.1 open
DMN12-86 grammar rule 56 missing comma DMN 1.1 open
DMN12-83 X and TBD are undefined in Table 35 DMN 1.1 open
DMN12-78 Impossible to invoke functions and() and or() DMN 1.1 open
DMN12-100 Collect decision tables DMN 1.1 open
DMN12-95 null is not defined in the S-FEEL grammar DMN 1.1 open
DMN12-79 Typo in sublist() function example DMN 1.1 open
DMN12-8 Wrong DecisionTable class diagram (metamodel) DMN 1.0 open
DMN12-81 Enhancement suggestion: make unary tests first class citizens of the FEEL language DMN 1.1 open
DMN12-80 Enhancement suggestion: allow for expressions to be used as "end points" DMN 1.1 open
DMN12-82 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
DMN12-60 FEEL path expression has same precedence as filter and invocation DMN 1.1 open
DMN12-53 Missing comma to split “in” in quantified expression in FEEL syntax DMN 1.1 open
DMN12-24 Table 47 should specify duration/duration rather than number/duration DMN 1.1 open
DMN12-23 typeRef from tables 10 and 15 not in figures 20 and 23 DMN 1.1 open
DMN12-16 Business Knowledge Model can have Information Requirements DMN 1.0 open
DMN12-76 Description of Table 37 is out of place DMN 1.1 open
DMN12-75 need set operations and equality in FEEL DMN 1.1 open
DMN12-73 Semantics of variable in decision table input entry DMN 1.1 open
DMN12-36 Alternative DRD representation of BKM DMN 1.1 open
DMN12-31 Collection Operators DMN 1.1 open
DMN12-32 Expressions in Input Entries DMN 1.1 open
DMN12-69 Case-aware and case-insensitive DMN 1.1 open
DMN12-57 notion of arbitrary order conflicts with lack of an unordered collection data type DMN 1.1 open
DMN12-28 Graphical representation of Context - "sub-DRDs" DMN 1.1 open
DMN12-41 FEEL + operator semantics operand-dependent DMN 1.1 open
DMN12-3 Examples DMN 1.0 open
DMN12-7 No notation for ItemDefinition DMN 1.0 open
DMN12-59 Need attribute for human and external decisions DMN 1.1 open
DMN12-9 Typo error on Business Knowledge Model DMN 1.0 open
DMN12-18 add richer variety of DT examples in Ch 11 DMN 1.0 open
DMN12-17 LiteralExpression and textual expression seem to mean the same thing, need to use the same term DMN 1.0 open
DMN12-1 cannot interchange input data style DMN 1.0b1 open
DMN12-4 Business Context links go both ways DMN 1.0 open
DMN12-52 Figure 70 does not correspond to example file DMN 1.1 open
DMN12-51 Unspecified conclusion DMN 1.1 open
DMN12-45 Remove tight coupling with BPMN and BMM DMN 1.1 open
DMN12-50 We need a way to identify current date and time. I propose Now() DMN 1.1 open
DMN12-47 FEEL 'instance of' operator is underspecified DMN 1.1 open
DMN12-37 Dynamic invocation DMN 1.1 open
DMN12-46 Wrong numbering in S-FEEL syntax DMN 1.1 open
DMN12-21 Eliminate () from FEEL and S-FEEL DMN 1.1 open
DMN12-19 XSD: global context DMN 1.0 open
DMN12-14 Useful to denote which info requirements are unconditional DMN 1.0 open
DMN12-25 Decisions can be used for many things, do we need a taxonomy? DMN 1.1 open
DMN11-45 Define decision service DMN 1.0 DMN 1.1 Resolved closed
DMN11-122 DMN 1.1 Beta documents 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-146 DMN XSD, MM, Attribute/Association Tables, and spec text are not consistent 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-155 DMN needs to provide a standard way for vendors to serialize extensions (Vendor Extensions) 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-81 extra level of indirection in decision table serialization is undesirable 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-99 Need for annotations and comments in DRD DMN 1.0 DMN 1.1 Resolved closed
DMN11-58 Decision table default output 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-127 would like to annotate Expression with typeRef 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-89 Remove parameters from BKM MM - these belong at logic level 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-175 typos for DMN 1.1 RTF final report 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-69 inputVariable and itemDefinition are redundant in Expression metamodel 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-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-120 Knowledge Source metamodel diagram missing 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-137 Need InformationItem for the FunctionDefinition of a BKM 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-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-13 DMN 1.1 RTF Issue: Negative numerics in decision tables 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-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-3 XMI issues from Pete Rivett DMN 1.0b1 DMN 1.1 Closed; No Change closed
DMN11-21 input expression example 'age<25' is not legal in SFEEL grammar 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-43 change "output expression" to "output name" 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-25 Definitions/@namespace has no purpose DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-30 add Definitions optional attributes exporter, exporterVersion DMN 1.0 DMN 1.1 Resolved closed
DMN11-44 Remove attribute DecisionTable/@isConsistent DMN 1.0 DMN 1.1 Resolved closed
DMN11-34 extraneous asterisks (*) DMN 1.0 DMN 1.1 Resolved closed
DMN11-35 Dangling reference 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-130 Clarify defaults for decision table outputs 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-60 Beta2 XSDs are broken 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-147 Nested ItemDefinition doesn't work DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-52 authorityRequirement in XSD 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-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-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-8 DMN Issue: Boxed context example of XML data is wrong 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-80 XSD: make @id optional in tExpression DMN 1.0 DMN 1.1 Resolved closed
DMN11-29 Examples DMN 1.0 DMN 1.1 Deferred closed
DMN11-10 cannot interchange input data style DMN 1.0b1 DMN 1.1 Deferred closed
DMN11-39 Clarify Decision/outputDefinition, DecisionTable/clause/outputDefinition, DecisionTable/@name, clause/@name 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-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-76 XSD: Relation and List DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-62 FEEL/S-FEEL names DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-152 not all references in DMN are by ID DMN 1.0 DMN 1.1 Resolved closed
DMN11-88 8.2.10 calls crosstab tables "rules as columns" 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-11 BigDecimal is not the only mapping of number to Java DMN 1.0 DMN 1.1 Deferred closed
DMN11-33 list variables in decision tables 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-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-42 output data symbol & comment symbol missing in DRDs DMN 1.0 DMN 1.1 Closed; No Change closed
DMN11-23 S-FEEL "expression" undefined DMN 1.0 DMN 1.1 Duplicate or Merged closed
DMN11-46 Consider date and time datatype in S-FEEL DMN 1.0 DMN 1.1 Deferred closed
DMN11-66 No notation for ItemDefinition 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
DMN12-15 No item definition for function defintion DMN 1.0 open
DMN11-116 Need group artifact in DRD, metamodel, and XSD DMN 1.0 DMN 1.1 Deferred closed
DMN12-11 italics and bold used for both typographic literal notation and FEEL semantic exposition DMN 1.0 open
DMN12-12 definition of expression in glossary omits CL3 expressions DMN 1.0 open

Issues Descriptions

Lexical representation of time string has ambiguous definitons

  • Key: DMN12-212
  • 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: Fri, 17 Nov 2017 10:14 GMT

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

  • Key: DMN12-129
  • Status: open  
  • 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
  • Updated: Thu, 16 Nov 2017 20:32 GMT

Add Diagram Interchange to DMN

  • Key: DMN12-20
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    This may include both the DRD and boxed expressions (decision tables, etc)

  • Reported: DMN 1.0 — Thu, 21 May 2015 15:42 GMT
  • Updated: Thu, 16 Nov 2017 20:32 GMT
  • Attachments:

Table 45 does not provide the semantic of addition and subtraction between elements of type Date and Duration

  • Key: DMN12-211
  • Status: open  
  • Source: Trisotech ( 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
  • Updated: Thu, 16 Nov 2017 17:02 GMT

Change depiction of Input to be harmonized with BPMN and CMMN


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

  • Key: DMN12-204
  • 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, 16 Nov 2017 16:27 GMT

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

  • Key: DMN12-203
  • Status: open  
  • 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
  • Updated: Thu, 16 Nov 2017 06:19 GMT

Improve description of built-in function string()

  • Key: DMN12-205
  • 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, 16 Nov 2017 06:13 GMT

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

  • Key: DMN12-210
  • Status: open  
  • 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
  • Updated: Thu, 9 Nov 2017 16:57 GMT

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

  • Key: DMN12-115
  • Status: open  
  • Source: Signavio GmbH ( 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
  • Updated: Sun, 5 Nov 2017 18:45 GMT

Formally define enumerations and use throughout

  • Key: DMN12-209
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor)
  • 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
  • Updated: Thu, 26 Oct 2017 16:12 GMT

Show diagram elements with hidden links

  • Key: DMN12-38
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor)
  • 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
  • Updated: Thu, 26 Oct 2017 04:19 GMT

Need group artifact in DRD, metamodel, and XSD

  • Key: DMN12-13
  • Status: open  
  • 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
  • Updated: Thu, 26 Oct 2017 04:13 GMT
  • Attachments:

Show implied Information Requirements

  • Key: DMN12-39
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor)
  • 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
  • Updated: Thu, 26 Oct 2017 04:07 GMT
  • Attachments:

Lack of visual notation for processing of / iteration over lists

  • Key: DMN12-27
  • Status: open  
  • Source: Signavio GmbH ( 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
  • Updated: Thu, 26 Oct 2017 04:06 GMT
  • Attachments:

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

  • Key: DMN12-207
  • Status: open  
  • 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
  • Updated: Tue, 17 Oct 2017 14:30 GMT

Invalid example for date and time property access

  • Key: DMN12-206
  • Status: open  
  • 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
  • Updated: Tue, 17 Oct 2017 14:29 GMT

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

  • Key: DMN12-202
  • 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, 17 Oct 2017 14:27 GMT

Type should be specified for date, time and duration properties

  • Key: DMN12-201
  • Status: open  
  • 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
  • Updated: Tue, 17 Oct 2017 14:26 GMT

Parameter names of built-in function date and time(date, time) are not allowed by name rules

  • Key: DMN12-195
  • Status: open  
  • 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
  • Updated: Tue, 17 Oct 2017 11:54 GMT

SFEEL makes too few people happy

  • Key: DMN12-48
  • Status: open  
  • Source: Trisotech ( 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
  • Updated: Thu, 12 Oct 2017 15:58 GMT

Consider date and time datatype in S-FEEL

  • Key: DMN12-5
  • Legacy Issue Number: 19755
  • Status: open  
  • Source: FICO ( 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
  • Updated: Wed, 11 Oct 2017 23:58 GMT

Table 45 does not provide the semantic of addition and subtraction between two elements of type date

  • Key: DMN12-189
  • Status: open   Implementation work Blocked
  • Source: Trisotech ( 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
  • Updated: Sat, 7 Oct 2017 00:46 GMT

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

  • Key: DMN12-186
  • Status: open  
  • 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 sentance.

  • Reported: DMN 1.1 — Thu, 31 Aug 2017 14:14 GMT
  • Updated: Sat, 7 Oct 2017 00:46 GMT

Parameter domain for built-in function years and months duration() is wrong

  • Key: DMN12-187
  • Status: open  
  • 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
  • Updated: Sat, 7 Oct 2017 00:46 GMT

Semantic mapping for XML syntactical artifacts

  • Key: DMN12-184
  • Status: open  
  • Source: Trisotech ( 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
  • Updated: Sat, 7 Oct 2017 00:46 GMT

DMN v1.2 specification


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

  • Key: DMN12-197
  • 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, 5 Oct 2017 04:53 GMT

While BKMs enable re-use, the options for re-use are restricted to single pieces of decision logic


Include Test Cases in Decision Model

  • Key: DMN12-49
  • 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, 5 Oct 2017 04:08 GMT
  • Attachments:

Generalized Unary Tests

  • Key: DMN12-29
  • Status: open  
  • Source: Sapiens Decision NA ( 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
  • Updated: Thu, 5 Oct 2017 03:52 GMT
  • Attachments:

Expressions in Input Entries

  • Key: DMN12-30
  • Status: open  
  • Source: Sapiens Decision NA ( 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
  • Updated: Thu, 5 Oct 2017 03:52 GMT

Label versus name attribute

  • Key: DMN12-89
  • Status: open  
  • Source: Trisotech ( 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
  • Updated: Thu, 5 Oct 2017 03:34 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: DMN12-196
  • Status: open  
  • 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
  • Updated: Tue, 3 Oct 2017 20:50 GMT

Spaces in FEEL builtin functions

  • Key: DMN12-40
  • Status: open  
  • 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
  • Updated: Tue, 3 Oct 2017 18:09 GMT

FEEL precedence for function definition

  • Key: DMN12-162
  • Status: open  
  • 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
  • Updated: Tue, 3 Oct 2017 08:39 GMT

Space in FEEL names is not well-specified

  • Key: DMN12-58
  • Status: open  
  • 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
  • Updated: Tue, 3 Oct 2017 08:33 GMT
  • Attachments:

Metamodel is missing the "kind" attribute on function

  • Key: DMN12-160
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    This attribute is depicted on boxed function and explain on page 104 but cannot be serialize as it is not part of table 67 presenting function attribute on page 140.

  • Reported: DMN 1.1 — Wed, 19 Apr 2017 04:00 GMT
  • Updated: Thu, 28 Sep 2017 13:36 GMT
  • Attachments:

Unclear meaning of unique name constraint for ItemDefinitions and DRGElements

  • Key: DMN12-141
  • Status: open  
  • Source: Signavio GmbH ( 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
  • Updated: Thu, 28 Sep 2017 13:28 GMT

some/every ... satisfies not defined for empty list

  • Key: DMN12-87
  • Status: open  
  • 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
  • Updated: Thu, 28 Sep 2017 13:23 GMT

Scope of Variables in Context Boxed Expression

  • Key: DMN12-33
  • Status: open  
  • Source: Sapiens Decision NA ( 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
  • Updated: Thu, 28 Sep 2017 13:16 GMT

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


Different definition of hit policy collect aggregations in FEEL and DMN

  • Key: DMN12-175
  • Status: open  
  • 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
  • Updated: Thu, 28 Sep 2017 12:02 GMT
  • Attachments:

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


Supporting text about Expression lists non-existing name attribute

  • Key: DMN12-155
  • Status: open  
  • Source: Camunda Services GmbH ( 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
  • Updated: Thu, 28 Sep 2017 09:07 GMT

Output Order hit policy on pg 85 is incorrect

  • Key: DMN12-149
  • Status: open  
  • 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
  • Updated: Thu, 28 Sep 2017 09:03 GMT

Inconsistencies between metamodel and xsd schema

  • Key: DMN12-143
  • Status: open  
  • Source: Goldman Sachs ( 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
  • Updated: Thu, 28 Sep 2017 08:59 GMT
  • Attachments:

Add id to context entry

  • Key: DMN12-134
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    Rules of a decision table have ids but context entries do not. One should be added so it can be reference; for error reporting for example.

  • Reported: DMN 1.1 — Mon, 13 Feb 2017 21:49 GMT
  • Updated: Thu, 28 Sep 2017 08:35 GMT
  • Attachments:

Return All Annotations for All Hit Policies

  • Key: DMN12-124
  • Status: open  
  • Source: Sapiens Decision NA ( 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
  • Updated: Wed, 27 Sep 2017 16:06 GMT
  • Attachments:

DMN built-in functions are missing to ensure business friendliness

  • Key: DMN12-190
  • Status: open  
  • Source: Trisotech ( 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
  • Updated: Thu, 21 Sep 2017 15:43 GMT

semantics of import is unspecified

  • Key: DMN12-188
  • Status: open  
  • 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
  • Updated: Thu, 14 Sep 2017 15:18 GMT

Missing type names in FEEL functions (user and external)

  • Key: DMN12-183
  • Status: open   Implementation work Blocked
  • Source: Goldman Sachs ( 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
  • Updated: Wed, 30 Aug 2017 15:18 GMT

FEEL grammar readbility

  • Key: DMN12-110
  • 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, 3 Aug 2017 14:05 GMT

Specification of type for instance of operator misses information

  • Key: DMN12-161
  • Status: open  
  • 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
  • Updated: Thu, 3 Aug 2017 00:21 GMT

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

  • Key: DMN12-68
  • Status: open  
  • Source: Camunda Services GmbH ( 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
  • Updated: Fri, 23 Jun 2017 12:50 GMT


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

  • Key: DMN12-172
  • Status: open  
  • Source: Trisotech ( 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: Mon, 15 May 2017 18:03 GMT

Need additional FEEL Types

  • Key: DMN12-117
  • Status: open  
  • 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
  • Updated: Thu, 11 May 2017 16:04 GMT

Ambiguity between qualified name and path operation

  • Key: DMN12-170
  • Status: open  
  • 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:

    • Unknown macro: {p}

      .persons results to ["jack", "jack"]

    • Unknown macro: {p}

      .path results to ["jack", "jack"] (or is dynamic path access not possible in FEEL?)

    • Unknown macro: {persons}

      .qn results to "jack"

  • Reported: DMN 1.1 — Wed, 3 May 2017 15:16 GMT
  • Updated: Wed, 10 May 2017 22:41 GMT

Is really only name allowed in a FEEL path?

  • Key: DMN12-168
  • Status: open  
  • 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
  • Updated: Tue, 9 May 2017 07:35 GMT

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

  • Key: DMN12-169
  • 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: Tue, 9 May 2017 04:38 GMT

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

  • Key: DMN12-171
  • 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: Tue, 9 May 2017 04:22 GMT

Missing semantic specification for FEEL for and quantified expression

  • Key: DMN12-167
  • Status: open  
  • 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
  • Updated: Thu, 4 May 2017 17:52 GMT

Should name declarations in same context fail or overwrite?

  • Key: DMN12-166
  • 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, 4 May 2017 17:52 GMT

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

  • Key: DMN12-165
  • 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, 4 May 2017 17:51 GMT

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

  • Key: DMN12-164
  • 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: Thu, 4 May 2017 17:51 GMT

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

  • Key: DMN12-163
  • Status: open  
  • 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
  • Updated: Thu, 4 May 2017 17:50 GMT

Improvement of Semantic Domains Specification

  • Key: DMN12-157
  • Status: open  
  • Source: Goldman Sachs ( 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
  • Updated: Thu, 4 May 2017 04:31 GMT
  • Attachments:

decision table structure in 8.1 does not agree with MM

  • Key: DMN12-148
  • Status: open  
  • 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
  • Updated: Thu, 20 Apr 2017 16:10 GMT

Duplicate definition of BKM/@variable in Table 14

  • Key: DMN12-138
  • Status: open  
  • Source: Camunda Services GmbH ( 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
  • Updated: Thu, 20 Apr 2017 15:58 GMT
  • Attachments:

clarify format of time literals / resolve inconsistency

  • Key: DMN12-137
  • Status: open  
  • Source: Signavio GmbH ( 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
  • Updated: Thu, 20 Apr 2017 15:54 GMT

Problem with QName usage in typeRef

  • Key: DMN12-94
  • Status: open  
  • Source: Trisotech ( 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
  • Updated: Thu, 20 Apr 2017 15:38 GMT
  • Attachments:

Label of Input in decision table

  • Key: DMN12-88
  • Status: open  
  • Source: Trisotech ( 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
  • Updated: Thu, 13 Apr 2017 16:24 GMT

Add specification for DMN diagrams layout

  • Key: DMN12-144
  • Status: open  
  • Source: Goldman Sachs ( 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
  • Updated: Sat, 8 Apr 2017 00:10 GMT

Missign Comma in Grammar Rule 48 (some/every...)

  • Key: DMN12-127
  • Status: open   Implementation work Blocked
  • Source: Camunda Services GmbH ( 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
  • Updated: Wed, 5 Apr 2017 09:54 GMT

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

  • Key: DMN12-55
  • Status: open  
  • 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
  • Updated: Wed, 5 Apr 2017 09:53 GMT

singular helping verb used with plural subject

  • Key: DMN12-103
  • Status: open  
  • 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
  • Updated: Wed, 5 Apr 2017 09:53 GMT

Decision table is not a good example of a builtin function

  • Key: DMN12-84
  • Status: open  
  • 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
  • Updated: Wed, 5 Apr 2017 09:52 GMT
  • Attachments:

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

  • Key: DMN12-158
  • Status: open   Implementation work Blocked
  • Source: Trisotech ( 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
  • Updated: Tue, 4 Apr 2017 00:22 GMT


Decision Service Cannot be Shown in DRD

  • Key: DMN12-136
  • Status: open  
  • Source: Sapiens Decision NA ( 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
  • Updated: Thu, 23 Mar 2017 18:44 GMT

DRD elements must be labeled with their name

  • Key: DMN12-133
  • Status: open  
  • 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
  • Updated: Thu, 23 Mar 2017 18:41 GMT

Drg element labels

  • Key: DMN12-43
  • Status: open  
  • 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
  • Updated: Thu, 23 Mar 2017 18:36 GMT

Releation between Definitions and DecisionService does not specified in XSD

  • Key: DMN12-121
  • Status: open  
  • 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
  • Updated: Thu, 23 Mar 2017 16:37 GMT

BigDecimal is not the only mapping of number to Java

  • Key: DMN12-2
  • Status: open  
  • Source: Thematix Partners LLC ( Edward 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
  • Updated: Thu, 23 Mar 2017 16:17 GMT

Semantic domain mapping for simple expressions

  • Key: DMN12-147
  • Status: open  
  • Source: Goldman Sachs ( 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: Fri, 17 Mar 2017 14:50 GMT

Remove rule#32 additional name symbols from BNF

  • Key: DMN12-132
  • Status: open  
  • Source: Trisotech ( 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
  • Updated: Thu, 9 Feb 2017 16:55 GMT

Execution Semantics of Decision Services does not explain imported elements

  • Key: DMN12-131
  • Status: open  
  • 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
  • Updated: Thu, 2 Feb 2017 15:54 GMT

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

  • Key: DMN12-130
  • Status: open  
  • 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
  • Updated: Thu, 2 Feb 2017 15:41 GMT

Chapter 11 example decision tables are incomplete

  • Key: DMN12-126
  • Status: open  
  • 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
  • Updated: Thu, 19 Jan 2017 19:14 GMT

Bug in specification of the ‘Any’ Hit Policy

  • Key: DMN12-125
  • Status: open  
  • Source: Sapiens Decision NA ( 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
  • Updated: Tue, 17 Jan 2017 08:39 GMT
  • Attachments:

Requested additional built-in functions

  • Key: DMN12-123
  • 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, 5 Jan 2017 16:46 GMT

string built-in underspecified

  • Key: DMN12-122
  • Status: open  
  • 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
  • Updated: Thu, 5 Jan 2017 16:39 GMT

alternative indication of reusable logic in DRD

  • Key: DMN12-6
  • Status: open  
  • Source: Bruce Silver Associates ( 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
  • Updated: Thu, 8 Dec 2016 17:14 GMT

Additional name symbols

  • Key: DMN12-111
  • Status: open   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
  • Updated: Thu, 1 Dec 2016 17:05 GMT

Spaces and additional characters in names / identifiers

  • Key: DMN12-120
  • Status: open  
  • 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
  • Updated: Thu, 1 Dec 2016 17:00 GMT

Support for function calls in unary tests

  • Key: DMN12-119
  • Status: open   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
  • Updated: Thu, 1 Dec 2016 06:18 GMT

FEEL does not support named ranges

  • Key: DMN12-118
  • Status: open  
  • 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
  • Updated: Thu, 10 Nov 2016 16:20 GMT

FEEL operators in names

  • Key: DMN12-42
  • Status: open  
  • 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
  • Updated: Thu, 3 Nov 2016 15:27 GMT

SFEEL grammar readbility

  • Key: DMN12-109
  • 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, 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
  • Updated: Thu, 3 Nov 2016 15:21 GMT

Typo in the sample xml

  • Key: DMN12-106
  • Status: open  
  • 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
  • Updated: Thu, 3 Nov 2016 15:16 GMT

Missing FEEL namespace in the header of the xml sample

  • Key: DMN12-107
  • Status: open  
  • 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
  • Updated: Thu, 3 Nov 2016 15:16 GMT

Naming inconsistency

  • Key: DMN12-108
  • Status: open  
  • 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
  • Updated: Thu, 3 Nov 2016 15:16 GMT

Broken HTTP links


Metamodel constraints & validation

  • Key: DMN12-113
  • 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: Wed, 2 Nov 2016 15:38 GMT

Missing "date" FEEL type in some enumerations

  • Key: DMN12-116
  • Status: open  
  • Source: Trisotech ( 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 45
    • 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
  • Updated: Tue, 1 Nov 2016 14:30 GMT


FEEL ambiguity

  • Key: DMN12-112
  • Status: open  
  • 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
  • Updated: Mon, 31 Oct 2016 19:54 GMT

Issues with Table 61

  • Key: DMN12-74
  • Status: open  
  • 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
  • Updated: Mon, 31 Oct 2016 16:53 GMT

grammar rule 56 missing comma

  • Key: DMN12-86
  • Status: open  
  • 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
  • Updated: Mon, 31 Oct 2016 16:13 GMT

X and TBD are undefined in Table 35

  • Key: DMN12-83
  • Status: open  
  • 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
  • Updated: Mon, 31 Oct 2016 16:10 GMT

Impossible to invoke functions and() and or()

  • Key: DMN12-78
  • Status: open   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
  • Updated: Mon, 31 Oct 2016 16:05 GMT

Collect decision tables

  • Key: DMN12-100
  • Status: open  
  • Source: FICO ( 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, 13 Oct 2016 15:43 GMT

null is not defined in the S-FEEL grammar

  • Key: DMN12-95
  • Status: open  
  • Source: Trisotech ( 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
  • Updated: Tue, 27 Sep 2016 20:15 GMT

Typo in sublist() function example

  • Key: DMN12-79
  • Status: open  
  • 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
  • Updated: Sat, 17 Sep 2016 00:19 GMT

Wrong DecisionTable class diagram (metamodel)

  • Key: DMN12-8
  • Legacy Issue Number: 19844
  • Status: open  
  • 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
  • Updated: Sat, 17 Sep 2016 00:19 GMT

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

  • Key: DMN12-81
  • 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, 25 Aug 2016 06:11 GMT

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

  • Key: DMN12-80
  • Status: open  
  • 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
  • Updated: Thu, 25 Aug 2016 05:55 GMT

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

  • Key: DMN12-82
  • Status: open  
  • Source: Trisotech ( 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, 25 Aug 2016 05:16 GMT

FEEL path expression has same precedence as filter and invocation

  • Key: DMN12-60
  • Status: open  
  • 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
  • Updated: Fri, 19 Aug 2016 08:05 GMT

Missing comma to split “in” in quantified expression in FEEL syntax

  • Key: DMN12-53
  • Status: open   Implementation work Blocked
  • Source: Trisotech ( 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
  • Updated: Fri, 19 Aug 2016 08:00 GMT

Table 47 should specify duration/duration rather than number/duration

  • Key: DMN12-24
  • Status: open  
  • 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
  • Updated: Fri, 19 Aug 2016 07:56 GMT

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

  • Key: DMN12-23
  • Status: open  
  • 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
  • Updated: Thu, 18 Aug 2016 16:29 GMT

Business Knowledge Model can have Information Requirements

  • Key: DMN12-16
  • 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: Thu, 18 Aug 2016 15:26 GMT

Description of Table 37 is out of place

  • Key: DMN12-76
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Most is described after Table 39. Needs to be moved just after Table 37.

  • Reported: DMN 1.1 — Mon, 15 Aug 2016 22:53 GMT
  • Updated: Mon, 15 Aug 2016 22:53 GMT

need set operations and equality in FEEL

  • Key: DMN12-75
  • 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: Fri, 12 Aug 2016 15:55 GMT

Semantics of variable in decision table input entry

  • Key: DMN12-73
  • Status: open  
  • 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
  • Updated: Mon, 8 Aug 2016 20:45 GMT

Alternative DRD representation of BKM

  • Key: DMN12-36
  • Status: open  
  • 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
  • Updated: Fri, 5 Aug 2016 00:27 GMT

Collection Operators

  • Key: DMN12-31
  • Status: open  
  • Source: Sapiens Decision NA ( 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
  • Updated: Fri, 5 Aug 2016 00:27 GMT

Expressions in Input Entries

  • Key: DMN12-32
  • Status: open  
  • Source: Sapiens Decision NA ( 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
  • Updated: Fri, 5 Aug 2016 00:27 GMT

Case-aware and case-insensitive

  • Key: DMN12-69
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor)
  • 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
  • Updated: Mon, 18 Jul 2016 17:06 GMT

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

  • Key: DMN12-57
  • Status: open   Implementation work Blocked
  • Source: Signavio GmbH ( 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: Wed, 13 Jul 2016 17:28 GMT

Graphical representation of Context - "sub-DRDs"

  • Key: DMN12-28
  • Status: open  
  • Source: Signavio GmbH ( 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
  • Updated: Mon, 11 Jul 2016 17:00 GMT
  • Attachments:

FEEL + operator semantics operand-dependent

  • Key: DMN12-41
  • Status: open  
  • 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
  • Updated: Thu, 30 Jun 2016 06:42 GMT

Examples

  • Key: DMN12-3
  • Status: open  
  • Source: Bruce Silver Associates ( 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
  • Updated: Thu, 30 Jun 2016 06:26 GMT

No notation for ItemDefinition

  • Key: DMN12-7
  • 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: Thu, 30 Jun 2016 06:25 GMT

Need attribute for human and external decisions

  • Key: DMN12-59
  • Status: open  
  • 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
  • Updated: Tue, 28 Jun 2016 14:49 GMT

Typo error on Business Knowledge Model

  • Key: DMN12-9
  • Legacy Issue Number: 19843
  • Status: open  
  • 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
  • Updated: Thu, 23 Jun 2016 15:39 GMT

add richer variety of DT examples in Ch 11

  • Key: DMN12-18
  • Status: open  
  • 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
  • Updated: Thu, 23 Jun 2016 15:28 GMT

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

  • Key: DMN12-17
  • Status: open  
  • 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
  • Updated: Thu, 23 Jun 2016 15:13 GMT

cannot interchange input data style

  • Key: DMN12-1
  • Status: open  
  • 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
  • Updated: Thu, 16 Jun 2016 06:26 GMT

Business Context links go both ways

  • Key: DMN12-4
  • Status: open  
  • Source: Bruce Silver Associates ( 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: Thu, 16 Jun 2016 06:26 GMT

Figure 70 does not correspond to example file

  • Key: DMN12-52
  • Status: open  
  • 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
  • Updated: Wed, 15 Jun 2016 14:37 GMT

Unspecified conclusion

  • Key: DMN12-51
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor)
  • 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: Mon, 13 Jun 2016 21:41 GMT

Remove tight coupling with BPMN and BMM

  • Key: DMN12-45
  • Status: open  
  • Source: Trisotech ( 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
  • Updated: Thu, 9 Jun 2016 05:03 GMT

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

  • Key: DMN12-50
  • Status: open  
  • Source: Trisotech ( 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
  • Updated: Fri, 3 Jun 2016 06:20 GMT

FEEL 'instance of' operator is underspecified

  • Key: DMN12-47
  • Status: open  
  • 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
  • Updated: Sat, 28 May 2016 15:59 GMT

Dynamic invocation

  • Key: DMN12-37
  • Status: open  
  • 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
  • Updated: Thu, 19 May 2016 18:13 GMT

Wrong numbering in S-FEEL syntax

  • Key: DMN12-46
  • Status: open  
  • Source: Trisotech ( 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
  • Updated: Tue, 17 May 2016 15:00 GMT

Eliminate () from FEEL and S-FEEL

  • Key: DMN12-21
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor)
  • 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
  • Updated: Thu, 5 May 2016 15:54 GMT

XSD: global context

  • Key: DMN12-19
  • Status: open  
  • Source: Bruce Silver Associates ( 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: Thu, 5 May 2016 15:33 GMT

Useful to denote which info requirements are unconditional

  • Key: DMN12-14
  • Status: open  
  • 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
  • Updated: Wed, 4 May 2016 16:27 GMT

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

  • Key: DMN12-25
  • Status: open  
  • 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
  • Updated: Tue, 12 Apr 2016 10:50 GMT

Define decision service

  • Key: DMN11-45
  • Legacy Issue Number: 19754
  • Status: closed  
  • Source: FICO ( 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:

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

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

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

DMN needs to provide a standard way for vendors to serialize extensions (Vendor Extensions)

  • Key: DMN11-155
  • Status: closed  
  • Source: Camunda Services GmbH ( 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:

Reference to BMM::Objective, BPMN::Process and BPMN::Task in XMI

  • Key: DMN11-12
  • Status: closed  
  • Source: International Business Machines ( 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

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:

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

Need for annotations and comments in DRD


Decision table default output

  • Key: DMN11-58
  • Status: closed  
  • Source: Bruce Silver Associates ( 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:

Information item name on DTs not correct in some figures

  • Key: DMN11-166
  • Status: closed  
  • Source: FICO ( 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

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:

'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

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:

Add association connector (artifact) with text label to represent conditional decision

  • Key: DMN11-47
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

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

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:

inputVariable and itemDefinition are redundant in Expression metamodel

  • Key: DMN11-69
  • Status: closed  
  • Source: Bruce Silver Associates ( 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:

XSD itemDefinition/typeRef and typeDefinition are underspecified and incorrect

  • Key: DMN11-54
  • Status: closed  
  • Source: Bruce Silver Associates ( 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:

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

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:

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:

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:

XSD; modify tItemDefinition by changing tItemComponent

  • Key: DMN11-56
  • Status: closed  
  • Source: Bruce Silver Associates ( 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 ( 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

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

DMN 1.1 RTF Issue: Negative numerics in decision tables

  • Key: DMN11-13
  • Legacy Issue Number: 19731
  • Status: closed  
  • Source: FICO ( 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

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

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

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

input expression example 'age<25' is not legal in SFEEL grammar

  • Key: DMN11-21
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

Expression defined as resulting in single value, but Decision may have multiple values

  • Key: DMN11-22
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

change "output expression" to "output name"

  • Key: DMN11-43
  • Status: closed  
  • Source: Bruce Silver Associates ( 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)

XSD internally inconsistent, does not match the spec

  • Key: DMN11-9
  • Legacy Issue Number: 19724
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

Definitions/@namespace has no purpose

  • Key: DMN11-25
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

add Definitions optional attributes exporter, exporterVersion

  • Key: DMN11-30
  • Status: closed  
  • Source: Bruce Silver Associates ( 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:

Remove attribute DecisionTable/@isConsistent

  • Key: DMN11-44
  • Status: closed  
  • Source: Bruce Silver Associates ( 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:

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

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

DecisionRule, InputClause & OutputClause should have ID and label for referencing in execution logs


Clarify defaults for decision table outputs

  • Key: DMN11-130
  • Status: closed  
  • Source: FICO ( 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

Constraints on Decision Table elements unclear

  • Key: DMN11-24
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

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

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

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

authorityRequirement in XSD

  • Key: DMN11-52
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

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

XSD: add optional @name to inputVariable

  • Key: DMN11-55
  • Status: closed  
  • Source: Bruce Silver Associates ( 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 ( 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

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

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

dmn3.xsd

  • Key: DMN11-48
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

XSD: make @id optional in tExpression

  • Key: DMN11-80
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

Examples

  • Key: DMN11-29
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

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

Clarify Decision/outputDefinition, DecisionTable/clause/outputDefinition, DecisionTable/@name, clause/@name

  • Key: DMN11-39
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

XSD: change type of LiteralExpression/text, ItemDefinition/typeDefinition, and (new) textAnnotation/text to xsd:string

  • Key: DMN11-102
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

XSD: DecisionTable/rule/condition should be IDREF not IDREFS

  • Key: DMN11-27
  • Status: closed  
  • Source: Bruce Silver Associates ( 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: Relation and List

  • Key: DMN11-76
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

FEEL/S-FEEL names

  • Key: DMN11-62
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

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

8.2.10 calls crosstab tables "rules as columns"

  • Key: DMN11-88
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

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

BigDecimal is not the only mapping of number to Java

  • Key: DMN11-11
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward 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

list variables in decision tables

  • Key: DMN11-33
  • Status: closed  
  • Source: Bruce Silver Associates ( 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 typeRef and itemDefinitionRef

  • Key: DMN11-57
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

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

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

S-FEEL "expression" undefined

  • Key: DMN11-23
  • Status: closed  
  • Source: Bruce Silver Associates ( 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

Consider date and time datatype in S-FEEL

  • Key: DMN11-46
  • Legacy Issue Number: 19755
  • Status: closed  
  • Source: FICO ( 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

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

alternative indication of reusable logic in DRD

  • Key: DMN11-51
  • Status: closed  
  • Source: Bruce Silver Associates ( 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 ( 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

No item definition for function defintion

  • Key: DMN12-15
  • Status: open  
  • 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
  • Updated: Fri, 12 Feb 2016 18:26 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:

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

  • Key: DMN12-11
  • 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, 22 Dec 2015 15:43 GMT

definition of expression in glossary omits CL3 expressions

  • Key: DMN12-12
  • Status: open  
  • 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
  • Updated: Tue, 22 Dec 2015 15:43 GMT