${taskforce.name} Avatar
  1. OMG Task Force

Decision Model and Notation 1.3 RTF — Open Issues

  • Key: DMN13
  • Issues Count: 111
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN13-2 Decision Logic Examples DMN 1.0 open
DMN13-158 Friendlier handling of null values DMN 1.2b1 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-139 Add built-in functions to support Allen's interval algebra DMN 1.2b1 open
DMN13-156 Decision Requirement Metadata Examples DMN 1.2b1 open
DMN13-143 Should add a new unicode escape syntax DMN 1.2b1 open
DMN13-127 Incorrect claim about the Unicode character range and EBNF character expressions DMN 1.2b1 open
DMN13-56 string built-in underspecified DMN 1.1 open
DMN13-6 Need group artifact in DRD, metamodel, and XSD DMN 1.0 open
DMN13-132 type conversions are too spread out in Ch 10 DMN 1.2b1 open
DMN13-144 instance of clarification DMN 1.2 open
DMN13-91 Fix interchange of links to objects in BPMN/BMM DMN 1.2 open
DMN13-131 Make explicit reference to sample standard deviation DMN 1.2b1 open
DMN13-34 Imprecise result for example calculation of function PMT and may be typo or rounding issue DMN 1.1 open
DMN13-66 Missing "date" FEEL type in some enumerations DMN 1.1 open
DMN13-72 Description of Table 44 is out of place DMN 1.1 open
DMN13-126 Built-in functions only described in chapter "10.3.2.6 Context", and not described in the "10.3.4 Built-in functions" DMN 1.2b1 open
DMN13-109 Ambiguty for the source/target of DMNEdge when there is multiple depictions of its source and target DMN 1.2 open
DMN13-125 Disambiguation for Modulo / Remainder function DMN 1.2b1 open
DMN13-27 Improve description of built-in function string() DMN 1.1 open
DMN13-4 No notation for ItemDefinition DMN 1.0 open
DMN13-108 Lack of visual notation for processing of / iteration over lists in FEEL DMN 1.2 open
DMN13-38 More Generic Ways to Define Decision Table Properties DMN 1.1 open
DMN13-153 Convenience documents DMN 1.2b1 open
DMN13-98 Example: Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses values inverted DMN 1.2b1 open
DMN13-133 Wrong example in chapter "10.3.1.5" DMN 1.2b1 open
DMN13-120 Minor typos in the FEEL grammar DMN 1.2b1 open
DMN13-121 example shows literal inline function definition whereas grammar says function definitions only in boxed expressions. DMN 1.2b1 open
DMN13-29 mix up of list and non-list in filter expression example DMN 1.1 open
DMN13-111 Remove the limitation that the second operand of exponentiation be an integer DMN 1.2b1 open
DMN13-106 Remove reference to SQL and PMML three value logic to eliminate misinterpretation DMN 1.2b1 open
DMN13-37 Specification of type for instance of operator misses information DMN 1.1 open
DMN13-145 Support for function types in metamodel and XSD DMN 1.2b1 open
DMN13-150 Support for recursive calls by Business Knowledge Models DMN 1.2 open
DMN13-78 Unspecified conclusion DMN 1.1 open
DMN13-122 "get value" and "get entries" function not in built-in functions list DMN 1.2b1 open
DMN13-59 FEEL does not support named ranges DMN 1.1 open
DMN13-140 Fix grammar rule references in FEEL grammar DMN 1.2b1 open
DMN13-141 Allegedly bug in Table Table 40 Examples of equivalence and conformance relations DMN 1.2b1 open
DMN13-142 Spec does not clarify meaning of hex value DMN 1.2b1 open
DMN13-149 Clarification on DMN case sensitivity of timezones DMN 1.2 open
DMN13-114 properly define type(e) DMN 1.2 open
DMN13-124 Disambiguation for Modulo / Remainder function DMN 1.2b1 open
DMN13-13 Expressions in Input Entries DMN 1.1 open
DMN13-134 Inconsistency DMNv1.2 dropping [a]=a and get entries example DMN 1.2b1 open
DMN13-19 ranges do not map to the semantic domain DMN 1.1 open
DMN13-123 "instance of" not possible with some built-in functions DMN 1.2b1 open
DMN13-53 Can listed input data option be used in encapsulated decisions of decision service? DMN 1.1 open
DMN13-18 Enhancement suggestion: make unary tests first class citizens of the FEEL language DMN 1.1 open
DMN13-67 Broken HTTP links DMN 1.1 open
DMN13-75 Case-aware and case-insensitive DMN 1.1 open
DMN13-40 Need additional FEEL Types DMN 1.1 open
DMN13-32 Lexical representation of time string has ambiguous definitons DMN 1.1 open
DMN13-68 FEEL ambiguity DMN 1.1 open
DMN13-69 Collect decision tables DMN 1.1 open
DMN13-36 FEEL grammar readbility DMN 1.1 open
DMN13-12 Lack of visual notation for processing of / iteration over lists in DRD DMN 1.1 open
DMN13-17 Enhancement suggestion: allow for expressions to be used as "end points" 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-41 Ambiguity between qualified name and path operation 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-14 FEEL operators in names 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-73 need set operations and equality in FEEL 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-54 Bug in specification of the ‘Any’ Hit Policy DMN 1.1 open
DMN13-60 SFEEL grammar readbility DMN 1.1 open
DMN13-64 Broken HTTP links DMN 1.1 open
DMN13-15 Change depiction of Input to be harmonized with BPMN and CMMN DMN 1.1 open
DMN13-90 Allow representation of black-box Decision Service 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-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-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-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-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-9 LiteralExpression and textual expression seem to mean the same thing, need to use the same term DMN 1.0 open
DMN13-77 Figure 70 does not correspond to example file DMN 1.1 open
DMN13-74 Semantics of variable in decision table input entry 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-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-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-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-3 Business Context links go both ways DMN 1.0 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-21 DMN v1.2 specification DMN 1.1 open

Issues Descriptions

Decision Logic 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, 21 May 2019 18:58 GMT
  • Attachments:

Friendlier handling of null values

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

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

  • Reported: DMN 1.2b1 — Tue, 21 May 2019 16:53 GMT
  • Updated: Tue, 21 May 2019 16:53 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: Tue, 21 May 2019 15:56 GMT

Add built-in functions to support Allen's interval algebra

  • Key: DMN13-139
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    Allen's interval algebra defines possible relations between two intervals.
    Namely:
    before
    meets
    overlaps
    finishes
    includes
    starts
    coincides
    after
    metBy
    overlappedBy
    finishedBy
    during
    finishes

    Some more info available here: https://en.wikipedia.org/wiki/Allen%27s_interval_algebra

  • Reported: DMN 1.2b1 — Wed, 6 Feb 2019 21:26 GMT
  • Updated: Tue, 21 May 2019 15:35 GMT

Decision Requirement Metadata Examples

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

    Enhance the example in chapter 11 with more realistic metadata attached to the decisions, input data, knowledge sources, etc.

  • Reported: DMN 1.2b1 — Tue, 21 May 2019 00:52 GMT
  • Updated: Tue, 21 May 2019 00:54 GMT

Should add a new unicode escape syntax

  • Key: DMN13-143
  • Status: open  
  • Source: fujitsu america ( keith swenson)
  • Summary:

    On page 110, rule #66 gives these escape sequences:

    string escape sequence = "\'" | "\"" | "
    " | "\n" | "\r" | "\t" | "\u", hex digit, hex digit, hex digit, hex digit;

    Using the hex character value notation "\uD41A" you can only four hex digits which is not enough to specify the entire Unicode character range. The spec specifically mentions that much higher values are allowed, and there should be a standard way to specify them without having to use the cryptic surrogate character pairs.

    This suggestion is to add braces to allow variable length hex values in exactly the way that JavaScript allows:

    "\u

    {1F40E}

    "

    This is character 128,014 in the unicode set. To specify this character using surrogate pairs you would have to use: "\uD83D\uDC0E" which is complicated and confusing and is currently subject to discussion on whether this is valid or not within the current spec.

    "A" = "\u

    {41}

    "

    "è" = "\u

    {E8}

    "

    "査" = "\u

    {67FB}

    "

    "" = "\u

    {1F407}

    " (Jira seems to crash if I inlcude this character)

    It is nice because you actually use the Unicode code point value, and because of the braces you can specify a variable number of hex digits so the entire Unicode set can be easily addressed. The precidence for this syntax is set by JavaScript (

    https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

    See page 218 where it defines this (slightly translated):

    UnicodeEscapeSequence ::
    \u Hex4Digits
    \u

    { CodePoint }

    This will not conflict with any existing implementation since the opening brace was not allowed in earlier implementations. The new allowed syntax could be used in DMN 1.3 and higher.

  • Reported: DMN 1.2b1 — Fri, 8 Feb 2019 19:06 GMT
  • Updated: Tue, 14 May 2019 02:26 GMT

Incorrect claim about the Unicode character range and EBNF character expressions

  • Key: DMN13-127
  • Status: open  
  • Source: Fujitsu ( Keith Swenson)
  • Summary:

    This is a trivial typo, and the fix is easy.

    Lower on page 108 it says: "the character range that includes all Unicode characters is [\u0-\u10FFF]." This range specified has less than 70,000 characters.

    I don't think your intent is to limit implementations to 70K characters and in fact in places (e.g. grammar rule #30) character values larger than this are mentioned.

    "all Unicode characters" is actually the entire range of 32-bit values (minus some control codes: hundreds of millions of characters, most of which are undefined). Instead you are defining a SUBSET of this that will be allowed.

    Second, the most common implementation of Unicode uses UTF-16, and as a consequences OF THIS ENCODING, the range of representable characters is 0 through 10FFFF. Note that is six hex digits, there are four F digits. There are over a million characters in this range.

    (1) Nowhere in the spec does is say you are limiting characters to the UTF-16 range. This should be explicitly stated if that is your intent.

    (2) The phrase on page 108 should be changed to; "DMN allows the use of unicode characters in the range of [\u0-\u10FFFF]."

    (3) The specification of EBNF character expression should be changed to allow 6 hex digits, currently it says you can only use five digits max.

  • Reported: DMN 1.2b1 — Mon, 31 Dec 2018 17:00 GMT
  • Updated: Tue, 14 May 2019 02:26 GMT
  • Attachments:

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: Tue, 14 May 2019 02:13 GMT

Need group artifact in DRD, metamodel, and XSD


type conversions are too spread out in Ch 10

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

    The spec does not contain a section where the type conversions are described, hence they end-up spread across the spec. For example, a particular case of invocation conversion is described in 10.3.2.5:

    Similarly, on a function f( p ) where the domain of the formal parameter p does not include lists, but on an invocation f( pa ) the
    actual parameter pa is a singleton list where the type of pa[1] belongs to the domain of p, then pa[1] should be used instead.

    Consolidating all of them in one paragraph will make the spec more readable and easier to change in the future (e.g. we want to apply conversions in other context). It will also help us to identify gaps in the spec.

    It's a natural step after adding the type relationships in DMN 1.2.

  • Reported: DMN 1.2b1 — Wed, 30 Jan 2019 16:34 GMT
  • Updated: Thu, 9 May 2019 00:42 GMT
  • Attachments:

instance of clarification


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, 7 May 2019 16:55 GMT

Make explicit reference to sample standard deviation

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

    The specification in chapter "10.3.4.4 List functions" for built-in function stddev does not explicit if it's meant to be population or sample standard deviation.
    However based on the example provided "stddev( 2, 4, 7, 5 ) = 2.0816659994661" would indicate it is meant to be the sample standard deviation --which is undefined for a single 1 sample value

    In order to be explicit, it is suggested to change the table entry as:

    Name(parameters) Parameter Domain Description Example
    stddev( list )
    stddev( n 1 , ..., n n )
    list is a list of number. n 1 ... n n are numbers. Returns the
    (sample) standard deviation of the list of numbers. If the list is empty,
    returns null. If the list contains only one number item, if n is a single number returns null.
    stddev( 2, 4, 7, 5 ) =
    2.0816659994661
    stddev( [ 47 ] ) = null
    stddev( 47 ) = null
    stddev( [ ] ) = null
  • Reported: DMN 1.2b1 — Fri, 18 Jan 2019 15:30 GMT
  • Updated: Tue, 7 May 2019 14:59 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, 7 May 2019 14:58 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 42
    • Date is part of S-FEEL and this paragraph from section 9.3 should probably be modified too:
      S-FEEL does not support FEEL date and time. However, it supports the date type, which is like FEEL date and time with hour, minute, and second required to be absent. The lexical and value spaces of FEEL date are the literal and value spaces of the XML Schema date datatype.
  • Reported: DMN 1.1 — Tue, 1 Nov 2016 14:30 GMT
  • Updated: Tue, 7 May 2019 14:57 GMT

Description of Table 44 is out of place

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

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

  • Reported: DMN 1.1 — Mon, 15 Aug 2016 22:53 GMT
  • Updated: Tue, 7 May 2019 14:57 GMT

Built-in functions only described in chapter "10.3.2.6 Context", and not described in the "10.3.4 Built-in functions"

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

    In section "10.3.2.6 Context" two built-in functions are described: get value(), get entries().
    However these functions are not summarized later in section "10.3.4 Built-in functions"

    Describing all built-in functions in latter section "10.3.4 Built-in functions" is important to agree on the function parameters name.

    Agree on the function parameters name is important for invoking function and binding parameters by name, rather than positional.

    I propose to add a new section inside "10.3.4 Built-in functions", with the following:

    10.3.4.x Context function

    Table xx defines Context functions.

    Table xx: Semantics of Context functions

    Name(parameters) Parameter Domain Description Example
    get value(m, key) context, string select the value of the entry named key from context m
    get value({key1 : "value1"}, "key1") = "value1"
    get value({key1 : "value1"}, "unexistent-key") = null
    
    get entries(m) context produces a list of key,value pairs from a context m
    get entries({key1 : "value1"}) = [ { key : "key1", value : "value1" } ]
    get entries({key1 : "value1"})[key="key1"].value = "value1"
    
  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 15:42 GMT
  • Updated: Tue, 7 May 2019 14:56 GMT

Ambiguty for the source/target of DMNEdge when there is multiple depictions of its source and target

  • Key: DMN13-109
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    DMN DI allows to depict element more than once. When drawing a diagram, tools need to check graphically the way points to know to which DMNShape a DMNEdge is actually connected to.

  • Reported: DMN 1.2 — Mon, 26 Nov 2018 22:50 GMT
  • Updated: Tue, 7 May 2019 14:54 GMT
  • Attachments:

Disambiguation for Modulo / Remainder function

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

    (please discard the previous JIRA on subject made by me, THIS is the correct one)

    The spec defines "modulo" FEEL built-in function as: "the remainder of the division of dividend by divisor"
    However, this might be subject to ambiguity in the case the Divisor or Dividend are negative, as also mentioned by Wikipedia page which list examples out of several programming languages and systems: https://en.wikipedia.org/wiki/Modulo_operation by saying that "When either a or n is negative, the naive definition breaks down and programming languages differ in how these values are defined".

    FEEL aims to be a Friendly Enough expression language, and especially thinking about DMN practitioners who might be used to Spreadsheet based systems might find misleading if the definition of the FEEL "modulo" gets bind to the Java (default) definition, the following table illustrate the difference:

    Dividend Divisor MOD() from Microsoft Excel, Google Sheets, LibreOffice Calc, Wolfram Alpha, etc. Java % or BigDecimal#remainder or other languages default
    10 4 2 2
    10 -4 -2 2
    -10 4 2 -2
    -10 -4 -2 -2

    or to other implementation languages where the definition of Modulo/Remainder is not explicit, or the default one is not consistent with Spreadsheet default one.

    It is proposed therefore to change the specification in 10.3.4.5 Numeric functions Table 70 for the FEEL "modulo" built-in function
    FROM: "Returns the remainder of the division of dividend by divisor."
    TO: "Returns the remainder of the division of dividend by divisor. In case either dividend or divisor is negative, the result has the same sign of the DIVISOR."

    This would avoid ambiguity by making a clear definition of what should be the sign in case either of the operands are negative.
    This should make this consistent with Spreadsheet based system result of "MOD()" expression, which should address being Friendly Enough for DMN practitioners and DM analyst.
    This would not make the result the same as the default of Java % operator or BigDecimal#remainder, but Java based implementation/Vendor can trivially address the result to be compliant with the spec.

  • Reported: DMN 1.2b1 — Fri, 4 Jan 2019 18:38 GMT
  • Updated: Tue, 7 May 2019 14:52 GMT
  • Attachments:

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: Tue, 7 May 2019 00:13 GMT

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, 30 Apr 2019 16:31 GMT

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




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

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

    Fig 11.28 on page 179 of formal-19-01-05 shows a screenshot of Applicant Data.
    The values of Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses are inverted, if the end result of executing the model is for decision Routing = "ACCEPT".

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

    Also, check spelling of "Stragegy" in Fig 11.30

  • Reported: DMN 1.2b1 — Wed, 10 Oct 2018 13:13 GMT
  • Updated: Tue, 30 Apr 2019 14:17 GMT
  • Attachments:

Wrong example in chapter "10.3.1.5"

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

    The specification in chapter "10.3.1.5 Contexts, Lists, Qualified Names, and Context Lists"

    presents the following example:

    [{a: [{b: 1}, {b: [2.1, 2.2]}]}, {a: [{b: 3}, {b: 4}, {b: 5}]}].a.b =
    [[{b: 1}, {b: [2.1, 2.2]}], [{b: 3}, {b: 4}, {b: 5}]].b =
    [[1, [2.1, 2.1]],[ 3, 4, 5]]
    

    However line 2 is wrong since DMNv1.2 dropped the equivalence that

    a=[a]
    

    therefore line 2 is problematic:

    [[{b: 1}, {b: [2.1, 2.2]}], [{b: 3}, {b: 4}, {b: 5}]].b =
     ^ b property is not available here
    

    as at the cursor position is not a context but two items of the root list.

    It is proposed to replace the example as follows:

    [{a: {b: 1}}, {a: {b: [2.1, 2.2]}}, {a: {b: 3}}, {a: {b: 4}}, {a: {b: 5}}].a.b =
    [{b: 1}, {b: [2.1, 2.2]}, {b: 3}, {b: 4}, {b: 5}].b =
    [1, [2.1, 2.1], 3, 4, 5]
    
  • Reported: DMN 1.2b1 — Sat, 26 Jan 2019 09:34 GMT
  • Updated: Tue, 30 Apr 2019 14:05 GMT

Minor typos in the FEEL grammar

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

    Typo in rule

    51. comparison =
    a.expression , ( "=" | "!=" | "<" | "<=" | ">" | ">=" ) , expression |
    b.expression , "between" , expression , "and" , expression |
    c.expression , "in" , positive unary test ;
    d.expression , "in" , " (", positive unary tests, ")" ;

    c. should have | at the end not ;

    We should replace non-terminal Boolean literal with boolean literal for consistency.

  • Reported: DMN 1.2b1 — Sat, 8 Dec 2018 19:36 GMT
  • Updated: Tue, 30 Apr 2019 13:46 GMT
  • Attachments:

example shows literal inline function definition whereas grammar says function definitions only in boxed expressions.

  • Key: DMN13-121
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The spec example shows a function definition inline in a literal expression using sort(). My take on the FEEL grammar spec is that a function definition can only exist inside a boxed expression, not inside a literal expression. A function definition inside a literal expression whose body has names with spaces or additional characters makes the parsing of the entire expression before execution darn hard - we'll I haven't figured it out anyways.

    In the specific case of the sort function, the type of the 'list' parameter may only be known at execution time, and thus the types of the arguments to the 'precedes' function can only be known at execution time - that is, when actually executing the sort. And to execute a sort, you need to pass it its arguments - which means a parsed function definition. If that function definition has names with spaces, then parsing can't be done until the types are known - during the sort execution. A little bit chicken an egg.

    But, if I read the spec correctly, you should not be able to have a function definition inside a literal expression. In which case, it is parsed separately to its invoking function and the above is not an issue.

    As a note, the given example and some tests in the TCK (which I am not sure should be there) involve simple params or simple names and can be parsed. But the scenario above is not covered by the TCK.

    Happy to be guided otherwise. An all advice appreciated.

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:00 GMT
  • Updated: Tue, 30 Apr 2019 13:45 GMT

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: Tue, 30 Apr 2019 11:19 GMT

Remove the limitation that the second operand of exponentiation be an integer

  • Key: DMN13-111
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    Table 55: Semantics of exponentiation limits the second operand to be an integer. It allow any number.

  • Reported: DMN 1.2b1 — Tue, 27 Nov 2018 14:10 GMT
  • Updated: Tue, 30 Apr 2019 11:18 GMT

Remove reference to SQL and PMML three value logic to eliminate misinterpretation

  • Key: DMN13-106
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    The spec says: Three-valued logic (true, false, null) based on SQL and PMML
    This statement can lead to misinterpretation (given their understanding of the SQL and/or PMML three value logic) for nothing given that we define the semantic of the FEEL three Value logic clearly below.

  • Reported: DMN 1.2b1 — Tue, 20 Nov 2018 17:12 GMT
  • Updated: Tue, 30 Apr 2019 11:15 GMT

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: Tue, 30 Apr 2019 11:12 GMT
  • Attachments:

Support for function types in metamodel and XSD

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

    The DMN metamodel & the XSD schema do not support definition of function type. For example, a construction as the one below is not supported:

    <functionDefinition name='add_type' returnType='number'>
             <parameters>
                    <param name='a' typeRef='number'>
                    <param name='b' typeRef='number'>
            </parameters>
    </functionDefinition>
    
  • Reported: DMN 1.2b1 — Fri, 22 Feb 2019 11:57 GMT
  • Updated: Tue, 30 Apr 2019 04:25 GMT

Support for recursive calls by Business Knowledge Models

  • Key: DMN13-150
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

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

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

    The following paragraph is added:

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

  • Reported: DMN 1.2 — Sat, 6 Apr 2019 02:38 GMT
  • Updated: Mon, 29 Apr 2019 20:25 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, 23 Apr 2019 16:41 GMT

"get value" and "get entries" function not in built-in functions list

  • Key: DMN13-122
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The above section mentions to two context-related functions "get value" and "get entries" that are not in the built in functions list. Are they meant to be there?

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:18 GMT
  • Updated: Thu, 11 Apr 2019 00:46 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: Tue, 2 Apr 2019 00:14 GMT

Fix grammar rule references in FEEL grammar

  • Key: DMN13-140
  • Status: open  
  • Source: Red Hat ( Edson Tirelli)
  • Summary:

    As discussed in the RTF call on Feb 5th, we need to fix:

    1.Refs to grammar rules at end of ch9 are incorrect (change 14 to 12 and check others)
    2. grammar rule 14 in ch10 is unused and should be removed
    3. UnaryTests UML class is missing from the spec (it is shown on one diagram not the defining occurrence
    Need to specify this MM class and point to the correct unary tests grammar rule that defines its syntax (this will be different for FEEL and SFEEL)

  • Reported: DMN 1.2b1 — Tue, 5 Feb 2019 17:53 GMT
  • Updated: Tue, 2 Apr 2019 00:08 GMT

Allegedly bug in Table Table 40 Examples of equivalence and conformance relations

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

    The DMNv1.2 spec reports these two lines examples:

    type1 type2 equivalent to conforms to
    type([{"id": 1,"name":"Peter", "age": 45}])
    
    type(Decision3)
    
    True True
    type(Decision4)
    
    type(Decision3)
    
    True True

    However concerning the first referenced line, type1

    type([{"id": 1,"name":"Peter", "age": 45}])
         ^
      by following the syntax used in table 39 takes the form of the type:
    
    list<context<"id": number,"name": string, "age": number>>
    

    and type2:

    type(Decision3)
    
      by following the syntax used in table 39 takes the form of the type:
    
    context<"id": number,"name": string, "age": number>
    

    So in the first referenced line it is asserted type1 is Equivalent to type2, but a list and a context are not Equivalent by the rule described in section 10.3.2.9.1 Type Equivalence

    Similarly for the second referenced line, type 1:

    type(Decision4)
    
      by following the syntax used in table 39 takes the form of the type:
    
    list<context<"id": number,"name": string, "age": number>>
    

    As for the ItemDefinition with the isCollection="true" which therefore obliges the definition that:

    IsCollection: Boolean Setting this flag to true indicates that the actual values defined by this ItemDefinition are collections of allowed values.

    So again by the section 10.3.2.9.1 Type Equivalence there are no "iff" rules explicited which would make a LIST Equivalent to a CONTEXT.

    Analogous issue for the reported values of Conformance.

    Can you kindly verify and clarify if needed, please?

  • Reported: DMN 1.2b1 — Fri, 1 Feb 2019 14:07 GMT
  • Updated: Tue, 2 Apr 2019 00:08 GMT
  • Attachments:

Spec does not clarify meaning of hex value

  • Key: DMN13-142
  • Status: open  
  • Source: fujitsu america ( keith swenson)
  • Summary:

    Rule #66 on page 111 says that a character in a string can be expressed as:

    "\u", hex digit, hex digit, hex digit, hex digit

    For example "\uD83D"

    That is, exactly four hex digits. I believe the intent is that FEEL only allows exactly four digits, and does not allow the kinds of expressions that we see in the EBNF.

    What is never specified is the exact meaning of that hex value. There are two possibilities:

    (a) Is that value a Unicode code point? In this case it is easy, the hex value is the code point value, however because you are limited to 64K characters, and not the 1.1M character range normally considered, and not even the values that are mentioned in the spec as having significance.

    (b) Or is it a UTF-16 code value? UTF-16 has encoding rules about values in the surrogate character range. In UTF-16 a high-surrogate-code value must be followed by a low-surrogate-code value or else the sequence of values is invalid and undefined. Using surrogate characters you can address the entire 1.1million characters but the user is required to understand about surrogate pairs.

    The spec never mentions that UTF-16 encoding is required! It always uses "Unicode" and talks about "characters" and "code points". It does not mention anything about surrogate pairs. It never says that these values a "just like Java" or any other UTF-16 implementation.

    Page 124 says that the FEEL string value is the same as java.lang.String. Should we infer from that that internal representations must be in UTF-16? however it also says that it is equivalent to an XML string (which is NOT constrained to UTF-16) and PMML string which I looked up and seems to be based on XML. XML allows characters to be expressed as &#nnnn ; That is an ampersand, a hash, a decimal number, terminated by a semicolon. In this case, the decimal value is the actual code point, and not the UTF-16 value. So page 124 does not say unambiguously that Java defines the string values that can be used.

    Unicode is mentioned only in three places: on page 108 (about EBNF character ranges), page 111 that tokens are a sequence of unicode characters, page 114 in an example.

    While it might be nice to be a "code point", the syntax clearly limits you to four digits leaving you no way to express larger code point values. If it was a code point you would be limited to only specifying 64,000 character (minus several thousand code points that not allowed for various reasons).

    The easiest repair is to state clearly that the \u notation assumes that UTF-16 is being used to encode the strings, and that UTF-16 rules must be used when specifying hex values for characters.

    I believe most implementations to date have assumed that these are UTF-16 code unit values. That is what Java does. That is what JavaScript does. I don't know of any environments that do anything different for this kind of expression.

  • Reported: DMN 1.2b1 — Fri, 8 Feb 2019 18:33 GMT
  • Updated: Tue, 2 Apr 2019 00:07 GMT

Clarification on DMN case sensitivity of timezones

  • Key: DMN13-149
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

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

  • Reported: DMN 1.2 — Sat, 16 Mar 2019 01:12 GMT
  • Updated: Tue, 2 Apr 2019 00:04 GMT

properly define type(e)

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

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

  • Reported: DMN 1.2 — Tue, 27 Nov 2018 22:31 GMT
  • Updated: Mon, 1 Apr 2019 23:58 GMT

Disambiguation for Modulo / Remainder function

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

    The spec defines "modulo" FEEL built-in function as: "the remainder of the division of dividend by divisor"
    However, this might be subject to ambiguity in the case the Divisor or Dividend are negative, as also mentioned by Wikipedia page which list examples out of several programming languages and systems: https://en.wikipedia.org/wiki/Modulo_operation by saying that "When either a or n is negative, the naive definition breaks down and programming languages differ in how these values are defined".

    FEEL aims to be a Friendly Enough expression language, and especially thinking about DMN practitioners who might be used to Spreadsheet based systems might find misleading if the definition of the FEEL "modulo" gets bind to the Java (default) definition, the following table illustrate the difference:

    Dividend Divisor MOD() from Microsoft Excel, Google Sheets, LibreOffice Calc, Wolfram Alpha, etc. Java % or BigDecimal#remainder or other languages default
    10 4 2 2
    10 -4 -2 2
    -10 4 2 -2
    -10 -4 -2 -2

    or to other implementation languages where the definition of Modulo/Remainder is not explicit, or the default one is not consistent with Spreadsheet default one.

    It is proposed therefore to change the specification in 10.3.4.5 Numeric functions Table 70 for the FEEL "modulo" built-in function
    FROM: "Returns the remainder of the division of dividend by divisor."
    TO: "Returns the remainder of the division of dividend by divisor. In case either dividend or divisor is negative, the result has the same sign of the dividend."

    This would avoid ambiguity by making a clear definition of what should be the sign in case either of the operands are negative.
    This should make this consistent with Spreadsheet based system result of "MOD()" expression, which should address being Friendly Enough for DMN practitioners and DM analyst.
    This would not make the result the same as the default of Java % operator or BigDecimal#remainder, but Java based implementation/Vendor can trivially address the result to be compliant with the spec.

  • Reported: DMN 1.2b1 — Fri, 4 Jan 2019 18:34 GMT
  • Updated: Thu, 14 Mar 2019 00:24 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: Thu, 14 Mar 2019 00:24 GMT

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

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

    Since DMNv1.2 the spec dropped the equivalence of:

    [a] = a
    

    because it does not apply to the statement that

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

    So the expression

    [a] = a
    

    on DMNv1.2 is expected to return false.

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

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

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

    BUT

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

    according to DMNv1.2 should be false

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

    [123] = 123
    

    on DMNv1.2 is expected to be false

  • Reported: DMN 1.2b1 — Wed, 30 Jan 2019 14:43 GMT
  • Updated: Tue, 12 Mar 2019 16:38 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, 12 Mar 2019 16:24 GMT

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

  • Key: DMN13-123
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:15 GMT
  • Updated: Tue, 5 Mar 2019 17:25 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: Thu, 31 Jan 2019 00:55 GMT

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: Tue, 22 Jan 2019 04:00 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, 21 Dec 2018 15:22 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: Thu, 13 Dec 2018 00:17 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 Dec 2018 23:52 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: Tue, 11 Dec 2018 17:53 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: Tue, 11 Dec 2018 17:35 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: Tue, 27 Nov 2018 04:30 GMT

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

  • 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: Wed, 21 Nov 2018 03:56 GMT
  • Attachments:

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, 20 Nov 2018 02:02 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

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

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

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

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

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:

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


Change depiction of Input to be harmonized with BPMN and CMMN


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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

DMN v1.2 specification