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

Open Issues

  • Issues not resolved
  • Name: dmn-rtf
  • Issues Count: 82

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN13-37 Specification of type for instance of operator misses information DMN 1.1 open
DMN13-41 Ambiguity between qualified name and path operation DMN 1.1 open
DMN13-23 Remove rule#32 additional name symbols from BNF DMN 1.1 open
DMN13-58 Spaces and additional characters in names / identifiers DMN 1.1 open
DMN13-57 Additional name symbols DMN 1.1 open
DMN13-49 FEEL grammar is ambiguous for grammar rule 2.i simple positive unary test when no operator is specified for an endpoint DMN 1.1 open
DMN13-67 Broken HTTP links DMN 1.1 open
DMN13-14 FEEL operators in names DMN 1.1 open
DMN13-40 Need additional FEEL Types DMN 1.1 open
DMN13-65 Metamodel constraints & validation DMN 1.1 open
DMN13-33 Formally define enumerations and use throughout DMN 1.1 open
DMN13-38 More Generic Ways to Define Decision Table Properties DMN 1.1 open
DMN13-73 need set operations and equality in FEEL DMN 1.1 open
DMN13-54 Bug in specification of the ‘Any’ Hit Policy DMN 1.1 open
DMN13-51 Page 71 states that a DT can have 0 inputs. I believe this to be incorrect DMN 1.1 open
DMN13-60 SFEEL grammar readbility DMN 1.1 open
DMN13-64 Broken HTTP links DMN 1.1 open
DMN13-29 mix up of list and non-list in filter expression example DMN 1.1 open
DMN13-15 Change depiction of Input to be harmonized with BPMN and CMMN DMN 1.1 open
DMN13-2 Examples DMN 1.0 open
DMN13-17 Enhancement suggestion: allow for expressions to be used as "end points" DMN 1.1 open
DMN13-90 Allow representation of black-box Decision Service DMN 1.2 open
DMN13-98 Example: Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses values inverted DMN 1.2b1 open
DMN13-91 Fix interchange of links to objects in BPMN/BMM DMN 1.2 open
DMN13-50 Improvement of Semantic Domains Specification DMN 1.1 open
DMN13-1 BigDecimal is not the only mapping of number to Java DMN 1.0 open
DMN13-31 Add two new concrete numeric types, make number abstract DMN 1.1 open
DMN13-34 Imprecise result for example calculation of function PMT and may be typo or rounding issue DMN 1.1 open
DMN13-46 Should name declarations in same context fail or overwrite? DMN 1.1 open
DMN13-45 Missing semantic specification for FEEL for and quantified expression DMN 1.1 open
DMN13-47 Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test DMN 1.1 open
DMN13-19 ranges do not map to the semantic domain DMN 1.1 open
DMN13-53 Can listed input data option be used in encapsulated decisions of decision service? DMN 1.1 open
DMN13-52 Semantic domain mapping for simple expressions DMN 1.1 open
DMN13-55 Requested additional built-in functions DMN 1.1 open
DMN13-48 Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122 DMN 1.1 open
DMN13-43 How to get FEEL type if evaluation is not an option? DMN 1.1 open
DMN13-39 Scope of decision table input/output entries is not well defined in the specification DMN 1.1 open
DMN13-36 FEEL grammar readbility DMN 1.1 open
DMN13-30 Wrong character in expression for PMT function definition DMN 1.1 open
DMN13-28 Can the same Definitions/namespace be used by more than one model? DMN 1.1 open
DMN13-27 Improve description of built-in function string() DMN 1.1 open
DMN13-25 Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration DMN 1.1 open
DMN13-22 Should encapsulated decisions of a decision service include output decisions? DMN 1.0 open
DMN13-26 Clarification needed if null is passed as value for optional parameter of built in function DMN 1.1 open
DMN13-24 No adjustment for last day in month if duration is added/subtracted to date and time value DMN 1.1 open
DMN13-16 Include Test Cases in Decision Model DMN 1.1 open
DMN13-18 Enhancement suggestion: make unary tests first class citizens of the FEEL language DMN 1.1 open
DMN13-9 LiteralExpression and textual expression seem to mean the same thing, need to use the same term DMN 1.0 open
DMN13-59 FEEL does not support named ranges DMN 1.1 open
DMN13-75 Case-aware and case-insensitive DMN 1.1 open
DMN13-77 Figure 70 does not correspond to example file DMN 1.1 open
DMN13-63 Naming inconsistency DMN 1.1 open
DMN13-62 Missing FEEL namespace in the header of the xml sample DMN 1.1 open
DMN13-70 null is not defined in the S-FEEL grammar DMN 1.1 open
DMN13-74 Semantics of variable in decision table input entry DMN 1.1 open
DMN13-61 Typo in the sample xml DMN 1.1 open
DMN13-42 Is really only name allowed in a FEEL path? DMN 1.1 open
DMN13-11 Decisions can be used for many things, do we need a taxonomy? DMN 1.1 open
DMN13-10 XSD: global context DMN 1.0 open
DMN13-20 Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions DMN 1.1 open
DMN13-56 string built-in underspecified DMN 1.1 open
DMN13-35 Equality for date, date and time, time and inequality for date doesn't use the value function, which make the <= and >= operations useless and = operation behaves differently as < and > DMN 1.1 open
DMN13-71 In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement DMN 1.1 open
DMN13-44 Can an expression in user defined function body reference a name outside of it's scope? DMN 1.1 open
DMN13-8 Business Knowledge Model can have Information Requirements DMN 1.0 open
DMN13-32 Lexical representation of time string has ambiguous definitons DMN 1.1 open
DMN13-5 italics and bold used for both typographic literal notation and FEEL semantic exposition DMN 1.0 open
DMN13-7 No item definition for function definition DMN 1.0 open
DMN13-6 Need group artifact in DRD, metamodel, and XSD DMN 1.0 open
DMN13-4 No notation for ItemDefinition DMN 1.0 open
DMN13-3 Business Context links go both ways DMN 1.0 open
DMN13-13 Expressions in Input Entries DMN 1.1 open
DMN13-12 Lack of visual notation for processing of / iteration over lists DMN 1.1 open
DMN13-79 We need a way to identify current date and time. I propose Now() DMN 1.1 open
DMN13-76 notion of arbitrary order conflicts with lack of an unordered collection data type DMN 1.1 open
DMN13-68 FEEL ambiguity DMN 1.1 open
DMN13-69 Collect decision tables DMN 1.1 open
DMN13-66 Missing "date" FEEL type in some enumerations DMN 1.1 open
DMN13-72 Description of Table 37 is out of place DMN 1.1 open
DMN13-78 Unspecified conclusion DMN 1.1 open
DMN13-21 DMN v1.2 specification DMN 1.1 open

Issues Descriptions

Specification of type for instance of operator misses information

  • Key: DMN13-37
  • 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: Sat, 17 Nov 2018 15:15 GMT
  • Attachments:

Ambiguity between qualified name and path operation

  • Key: DMN13-41
  • 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:

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

      results to

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

      results to

      ["jack", "jack"]

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

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

      results to

      "jack"
  • Reported: DMN 1.1 — Wed, 3 May 2017 15:16 GMT
  • Updated: Thu, 15 Nov 2018 00:27 GMT

Remove rule#32 additional name symbols from BNF

  • Key: DMN13-23
  • 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, 15 Nov 2018 00:27 GMT

Spaces and additional characters in names / identifiers

  • Key: DMN13-58
  • 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, 15 Nov 2018 00:27 GMT

Additional name symbols

  • Key: DMN13-57
  • 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, 15 Nov 2018 00:27 GMT

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

  • Key: DMN13-49
  • Status: 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, 15 Nov 2018 00:27 GMT


FEEL operators in names

  • Key: DMN13-14
  • 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, 15 Nov 2018 00:27 GMT

Need additional FEEL Types

  • Key: DMN13-40
  • 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: Tue, 13 Nov 2018 17:49 GMT

Metamodel constraints & validation

  • Key: DMN13-65
  • 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: Sun, 11 Nov 2018 10:48 GMT

Formally define enumerations and use throughout

  • Key: DMN13-33
  • 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: Tue, 6 Nov 2018 17:56 GMT


need set operations and equality in FEEL

  • Key: DMN13-73
  • 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: Tue, 6 Nov 2018 17:17 GMT

Bug in specification of the ‘Any’ Hit Policy

  • Key: DMN13-54
  • 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: Thu, 1 Nov 2018 00:55 GMT
  • Attachments:

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

  • Key: DMN13-51
  • 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: Thu, 1 Nov 2018 00:55 GMT

SFEEL grammar readbility

  • Key: DMN13-60
  • 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, 1 Nov 2018 00:55 GMT

Broken HTTP links


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

  • Key: DMN13-29
  • 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: Thu, 1 Nov 2018 00:55 GMT

Change depiction of Input to be harmonized with BPMN and CMMN


Examples

  • Key: DMN13-2
  • 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: Tue, 23 Oct 2018 17:03 GMT

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

  • Key: DMN13-17
  • 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: Tue, 23 Oct 2018 16:50 GMT

Allow representation of black-box Decision Service

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

    As DMN gets used to produce publicly available decision services we will need some way to represent a decision service that the modeler cannot see into. They know its a side-effect free, stateless decision service and know its signature so they can add a decision to their own model that is implemented by it but they don't know what decisions, BKMs, knowledge sources etc were used to produce it. There is currently no way to do this - a decision service can be shown collapsed but only if the model "knows" what the expanded version looks like. It feels like it would be useful to do so.

  • Reported: DMN 1.2 — Thu, 27 Sep 2018 01:04 GMT
  • Updated: Tue, 23 Oct 2018 16:37 GMT

Example: Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses values inverted

  • Key: DMN13-98
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Current PDF document on page 173 shows a screenshot of Applicant Data valorized.
    The values of Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses are inverted, if the end result of executing the model is for decision Routing = "ACCEPT".

    In other words; currently the PDF document display as:
    Applicant Data.Monthly.Income = 10000 (ten-thousands)
    Applicant Data.Monthly.Expenses = 100000 (a-hundred-thousands)
    but actually it should be:
    Applicant Data.Monthly.Income = 100000 (a-hundred-thousands)
    Applicant Data.Monthly.Expenses = 10000 (ten-thousands)
    if the decision Routing should evaluate to "ACCEPT".

  • Reported: DMN 1.2b1 — Wed, 10 Oct 2018 13:13 GMT
  • Updated: Tue, 16 Oct 2018 19:37 GMT

Fix interchange of links to objects in BPMN/BMM

  • Key: DMN13-91
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor)
  • Summary:

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

  • Reported: DMN 1.2 — Thu, 27 Sep 2018 01:07 GMT
  • Updated: Tue, 16 Oct 2018 16:47 GMT

Improvement of Semantic Domains Specification

  • Key: DMN13-50
  • 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: Mon, 15 Oct 2018 21:32 GMT
  • Attachments:

BigDecimal is not the only mapping of number to Java

  • Key: DMN13-1
  • 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, 11 Oct 2018 11:14 GMT

Add two new concrete numeric types, make number abstract

  • Key: DMN13-31
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

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

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

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

    Here is my proposal:

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

    If we agree in principal all start working on it.

  • Reported: DMN 1.1 — Wed, 6 Dec 2017 13:44 GMT
  • Updated: Wed, 10 Oct 2018 15:25 GMT

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

  • Key: DMN13-34
  • 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, 9 Oct 2018 16:21 GMT

Should name declarations in same context fail or overwrite?

  • Key: DMN13-46
  • 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: Tue, 9 Oct 2018 15:58 GMT

Missing semantic specification for FEEL for and quantified expression

  • Key: DMN13-45
  • 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: Tue, 9 Oct 2018 15:57 GMT

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

  • Key: DMN13-47
  • 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: Tue, 9 Oct 2018 15:57 GMT

ranges do not map to the semantic domain

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

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

    Proposed remove section 10.3.2.7

  • Reported: DMN 1.1 — Fri, 6 Apr 2018 17:36 GMT
  • Updated: Tue, 9 Oct 2018 15:56 GMT

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

  • Key: DMN13-53
  • 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: Tue, 9 Oct 2018 15:54 GMT

Semantic domain mapping for simple expressions

  • Key: DMN13-52
  • 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: Tue, 9 Oct 2018 15:53 GMT

Requested additional built-in functions

  • Key: DMN13-55
  • 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: Tue, 9 Oct 2018 15:52 GMT

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

  • Key: DMN13-48
  • 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: Mon, 8 Oct 2018 23:26 GMT

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

  • Key: DMN13-43
  • 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: Mon, 8 Oct 2018 23:25 GMT

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

  • Key: DMN13-39
  • 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, 8 Oct 2018 23:22 GMT

FEEL grammar readbility

  • Key: DMN13-36
  • 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: Mon, 8 Oct 2018 23:19 GMT

Wrong character in expression for PMT function definition

  • Key: DMN13-30
  • Status: open  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

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

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

    Fixed:

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

  • Reported: DMN 1.1 — Fri, 2 Feb 2018 10:32 GMT
  • Updated: Mon, 8 Oct 2018 23:08 GMT

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

  • Key: DMN13-28
  • Status: open   Implementation work Blocked
  • Source: Red Hat ( Edson Tirelli)
  • Summary:

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

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

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

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

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

  • Reported: DMN 1.1 — Thu, 8 Mar 2018 16:20 GMT
  • Updated: Mon, 8 Oct 2018 23:07 GMT

Improve description of built-in function string()

  • Key: DMN13-27
  • 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: Mon, 8 Oct 2018 23:05 GMT

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

  • Key: DMN13-25
  • Status: 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: Mon, 8 Oct 2018 22:45 GMT

Should encapsulated decisions of a decision service include output decisions?

  • Key: DMN13-22
  • Status: open  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

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

    {Decision 1, Decision 2}

    "

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

    {Decision 1}

    ".

    Table 20 on page 56:

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

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

  • Reported: DMN 1.0 — Tue, 20 Mar 2018 14:49 GMT
  • Updated: Mon, 8 Oct 2018 22:44 GMT

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

  • Key: DMN13-26
  • 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: Mon, 8 Oct 2018 22:37 GMT

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

  • Key: DMN13-24
  • 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: Mon, 8 Oct 2018 22:35 GMT

Include Test Cases in Decision Model

  • Key: DMN13-16
  • 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: Mon, 8 Oct 2018 22:34 GMT
  • Attachments:

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

  • Key: DMN13-18
  • 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: Mon, 8 Oct 2018 22:25 GMT

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

  • Key: DMN13-9
  • 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: Mon, 8 Oct 2018 22:14 GMT

FEEL does not support named ranges

  • Key: DMN13-59
  • 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: Mon, 8 Oct 2018 06:15 GMT

Case-aware and case-insensitive

  • Key: DMN13-75
  • 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: Fri, 5 Oct 2018 18:15 GMT

Figure 70 does not correspond to example file

  • Key: DMN13-77
  • 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: Fri, 5 Oct 2018 18:15 GMT

Naming inconsistency

  • Key: DMN13-63
  • 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: Fri, 5 Oct 2018 18:15 GMT

Missing FEEL namespace in the header of the xml sample

  • Key: DMN13-62
  • 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: Fri, 5 Oct 2018 18:15 GMT

null is not defined in the S-FEEL grammar

  • Key: DMN13-70
  • 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: Fri, 5 Oct 2018 18:15 GMT

Semantics of variable in decision table input entry

  • Key: DMN13-74
  • 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: Fri, 5 Oct 2018 18:15 GMT

Typo in the sample xml

  • Key: DMN13-61
  • 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: Fri, 5 Oct 2018 18:15 GMT

Is really only name allowed in a FEEL path?

  • Key: DMN13-42
  • 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: Fri, 5 Oct 2018 18:15 GMT

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

  • Key: DMN13-11
  • 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: Fri, 5 Oct 2018 18:15 GMT

XSD: global context

  • Key: DMN13-10
  • 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: Mon, 24 Sep 2018 22:11 GMT

Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions

  • Key: DMN13-20
  • Status: open  
  • Source: Department of Veterans Affairs ( Stephen White)
  • Summary:

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

  • Reported: DMN 1.1 — Fri, 3 Aug 2018 21:19 GMT
  • Updated: Mon, 24 Sep 2018 21:51 GMT

string built-in underspecified

  • Key: DMN13-56
  • 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: Mon, 24 Sep 2018 21:41 GMT

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

  • Key: DMN13-35
  • Status: 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: Mon, 24 Sep 2018 20:51 GMT

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

  • Key: DMN13-71
  • Status: 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: Mon, 24 Sep 2018 20:28 GMT

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

  • Key: DMN13-44
  • 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, 11 Sep 2018 22:52 GMT

Business Knowledge Model can have Information Requirements

  • Key: DMN13-8
  • 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: Tue, 11 Sep 2018 22:51 GMT

Lexical representation of time string has ambiguous definitons

  • Key: DMN13-32
  • 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: Tue, 11 Sep 2018 22:31 GMT

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

  • Key: DMN13-5
  • 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, 11 Sep 2018 22:22 GMT

No item definition for function definition

  • Key: DMN13-7
  • 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: Tue, 11 Sep 2018 22:20 GMT

Need group artifact in DRD, metamodel, and XSD

  • Key: DMN13-6
  • 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: Tue, 11 Sep 2018 22:14 GMT
  • Attachments:

No notation for ItemDefinition

  • Key: DMN13-4
  • 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: Tue, 11 Sep 2018 22:05 GMT

Business Context links go both ways

  • Key: DMN13-3
  • 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: Tue, 11 Sep 2018 21:47 GMT

Expressions in Input Entries

  • Key: DMN13-13
  • 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: Tue, 11 Sep 2018 21:45 GMT

Lack of visual notation for processing of / iteration over lists

  • Key: DMN13-12
  • 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: Tue, 11 Sep 2018 21:34 GMT
  • Attachments:

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

  • Key: DMN13-79
  • 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: Wed, 5 Sep 2018 20:30 GMT

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

  • Key: DMN13-76
  • Status: open  
  • 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, 5 Sep 2018 20:29 GMT

FEEL ambiguity

  • Key: DMN13-68
  • 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: Wed, 5 Sep 2018 01:01 GMT

Collect decision tables

  • Key: DMN13-69
  • 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: Wed, 5 Sep 2018 01:00 GMT

Missing "date" FEEL type in some enumerations

  • Key: DMN13-66
  • 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: Wed, 5 Sep 2018 00:46 GMT

Description of Table 37 is out of place

  • Key: DMN13-72
  • 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: Wed, 5 Sep 2018 00:16 GMT

Unspecified conclusion

  • Key: DMN13-78
  • 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: Tue, 4 Sep 2018 23:22 GMT

DMN v1.2 specification