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

Decision Model and Notation 1.3 RTF — Closed Issues

  • Key: DMN13
  • Issues Count: 110
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN13-127 Incorrect claim about the Unicode character range and EBNF character expressions DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-143 Should add a new unicode escape syntax DMN 1.2b1 DMN 1.3 Duplicate or Merged closed
DMN13-109 Ambiguty for the source/target of DMNEdge when there is multiple depictions of its source and target DMN 1.2 DMN 1.3 Resolved closed
DMN13-244 Incorrect figure 6.10 DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-181 PMML invocation output value in the case of single prediction DMN 1.2 DMN 1.3 Resolved closed
DMN13-175 A signature for the time() built in function is missing from table 66 DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-2 Decision Logic Examples DMN 1.0 DMN 1.3 Resolved closed
DMN13-125 Disambiguation for Modulo / Remainder function DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-139 Add built-in functions to support Allen's interval algebra DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-140 Incorrect grammar rule references and missing UnaryTests section in MM DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-141 Allegedly bug in Table Table 40 Examples of equivalence and conformance relations DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-132 type conversions are too spread out in Ch 10 DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-111 Remove the limitation that the second operand of exponentiation be an integer DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-156 Decision Requirement Metadata Examples DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-163 Decision Service output value in the case of single output Decision DMN 1.2 DMN 1.3 Resolved closed
DMN13-188 New FEEL URI needed DMN 1.2 DMN 1.3 Resolved closed
DMN13-178 Functions resolution DMN 1.2 DMN 1.3 Resolved closed
DMN13-242 Update the copyright section DMN 1.2 DMN 1.3 Resolved closed
DMN13-195 New acknowledgments needed DMN 1.2 DMN 1.3 Resolved closed
DMN13-191 New XML Namespace needed DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-21 DMN v1.2 specification DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-19 ranges do not map to the semantic domain DMN 1.1 DMN 1.3 Duplicate or Merged closed
DMN13-7 No item definition for function definition DMN 1.0 DMN 1.3 Resolved closed
DMN13-6 Need group artifact in DRD, metamodel, and XSD DMN 1.0 DMN 1.3 Resolved closed
DMN13-29 mix up of list and non-list in filter expression example DMN 1.1 DMN 1.3 Resolved closed
DMN13-59 FEEL does not support named ranges DMN 1.1 DMN 1.3 Duplicate or Merged closed
DMN13-35 Equality for date, date and time, time and inequality for date doesn't use the value function, which make the <= and >= operations useless and = operation behaves differently as < and > DMN 1.1 DMN 1.3 Resolved closed
DMN13-34 Imprecise result for example calculation of function PMT and may be typo or rounding issue DMN 1.1 DMN 1.3 Resolved closed
DMN13-56 string built-in underspecified DMN 1.1 DMN 1.3 Duplicate or Merged closed
DMN13-75 Case-aware and case-insensitive DMN 1.1 DMN 1.3 Closed; Out Of Scope closed
DMN13-124 Disambiguation for Modulo / Remainder function DMN 1.2b1 DMN 1.3 Duplicate or Merged closed
DMN13-144 instance of clarification DMN 1.2 DMN 1.3 Resolved closed
DMN13-131 Make explicit reference to sample standard deviation DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-133 Wrong example in chapter "10.3.1.5" DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-106 Remove reference to SQL and PMML three value logic to eliminate misinterpretation DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-126 Built-in functions only described in chapter "10.3.2.6 Context", and not described in the "10.3.4 Built-in functions" DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-122 "get value" and "get entries" function not in built-in functions list DMN 1.2b1 DMN 1.3 Duplicate or Merged closed
DMN13-121 example shows literal inline function definition whereas grammar says function definitions only in boxed expressions. DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-120 Minor typos in the FEEL grammar DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-98 Example: Applicant Data.Monthly.Income and Applicant Data.Monthly.Expenses values inverted DMN 1.2b1 DMN 1.3 Resolved closed
DMN13-40 Need additional FEEL Types DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-41 Ambiguity between qualified name and path operation DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-37 Specification of type for instance of operator misses information DMN 1.1 DMN 1.3 Resolved closed
DMN13-45 Missing semantic specification for FEEL for and quantified expression DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-53 Can listed input data option be used in encapsulated decisions of decision service? DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-13 Expressions in Input Entries DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-66 Missing "date" FEEL type in some enumerations DMN 1.1 DMN 1.3 Resolved closed
DMN13-67 Broken HTTP links DMN 1.1 DMN 1.3 Resolved closed
DMN13-72 Description of Table 44 is out of place DMN 1.1 DMN 1.3 Resolved closed
DMN13-23 Remove rule#32 additional name symbols from BNF DMN 1.1 DMN 1.3 Closed; Out Of Scope closed
DMN13-62 Missing FEEL namespace in the header of the xml sample DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-61 Typo in the sample xml DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-64 Broken HTTP links DMN 1.1 DMN 1.3 Duplicate or Merged closed
DMN13-57 Additional name symbols DMN 1.1 DMN 1.3 Closed; Out Of Scope closed
DMN13-60 SFEEL grammar readbility DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-63 Naming inconsistency DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-77 Figure 70 does not correspond to example file DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-42 Is really only name allowed in a FEEL path? DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-49 FEEL grammar is ambiguous for grammar rule 2.i simple positive unary test when no operator is specified for an endpoint DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-51 Page 71 states that a DT can have 0 inputs. I believe this to be incorrect DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-54 Bug in specification of the ‘Any’ Hit Policy DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-1 BigDecimal is not the only mapping of number to Java DMN 1.0 DMN 1.3 Deferred closed
DMN13-14 FEEL operators in names DMN 1.1 DMN 1.3 Closed; Out Of Scope closed
DMN13-11 Decisions can be used for many things, do we need a taxonomy? DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-5 italics and bold used for both typographic literal notation and FEEL semantic exposition DMN 1.0 DMN 1.3 Deferred closed
DMN13-4 No notation for ItemDefinition DMN 1.0 DMN 1.3 Deferred closed
DMN13-3 Business Context links go both ways DMN 1.0 DMN 1.3 Deferred closed
DMN13-58 Spaces and additional characters in names / identifiers DMN 1.1 DMN 1.3 Closed; Out Of Scope closed
DMN13-70 null is not defined in the S-FEEL grammar DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-74 Semantics of variable in decision table input entry DMN 1.1 DMN 1.3 Closed; No Change closed
DMN13-26 Clarification needed if null is passed as value for optional parameter of built in function DMN 1.1 DMN 1.3 Deferred closed
DMN13-25 Introduce a new property "value" for type date, date and time, time, years and months duration, days and time duration DMN 1.1 DMN 1.3 Deferred closed
DMN13-24 No adjustment for last day in month if duration is added/subtracted to date and time value DMN 1.1 DMN 1.3 Deferred closed
DMN13-27 Improve description of built-in function string() DMN 1.1 DMN 1.3 Deferred closed
DMN13-36 FEEL grammar readbility DMN 1.1 DMN 1.3 Deferred closed
DMN13-32 Lexical representation of time string has ambiguous definitons DMN 1.1 DMN 1.3 Deferred closed
DMN13-38 More Generic Ways to Define Decision Table Properties DMN 1.1 DMN 1.3 Deferred closed
DMN13-39 Scope of decision table input/output entries is not well defined in the specification DMN 1.1 DMN 1.3 Deferred closed
DMN13-43 How to get FEEL type if evaluation is not an option? DMN 1.1 DMN 1.3 Deferred closed
DMN13-18 Enhancement suggestion: make unary tests first class citizens of the FEEL language DMN 1.1 DMN 1.3 Deferred closed
DMN13-17 Enhancement suggestion: allow for expressions to be used as "end points" DMN 1.1 DMN 1.3 Deferred closed
DMN13-16 Include Test Cases in Decision Model DMN 1.1 DMN 1.3 Deferred closed
DMN13-15 Change depiction of Input to be harmonized with BPMN and CMMN DMN 1.1 DMN 1.3 Deferred closed
DMN13-12 Lack of visual notation for processing of / iteration over lists in DRD DMN 1.1 DMN 1.3 Deferred closed
DMN13-10 XSD: global context DMN 1.0 DMN 1.3 Deferred closed
DMN13-9 LiteralExpression and textual expression seem to mean the same thing, need to use the same term DMN 1.0 DMN 1.3 Deferred closed
DMN13-8 Business Knowledge Model can have Information Requirements DMN 1.0 DMN 1.3 Deferred closed
DMN13-28 Can the same Definitions/namespace be used by more than one model? DMN 1.1 DMN 1.3 Deferred closed
DMN13-31 Add two new concrete numeric types, make number abstract DMN 1.1 DMN 1.3 Deferred closed
DMN13-33 Formally define enumerations and use throughout DMN 1.1 DMN 1.3 Deferred closed
DMN13-20 Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions DMN 1.1 DMN 1.3 Deferred closed
DMN13-22 Should encapsulated decisions of a decision service include output decisions? DMN 1.0 DMN 1.3 Deferred closed
DMN13-30 Wrong character in expression for PMT function definition DMN 1.1 DMN 1.3 Deferred closed
DMN13-55 Requested additional built-in functions DMN 1.1 DMN 1.3 Deferred closed
DMN13-69 Collect decision tables DMN 1.1 DMN 1.3 Deferred closed
DMN13-68 FEEL ambiguity DMN 1.1 DMN 1.3 Deferred closed
DMN13-71 In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement DMN 1.1 DMN 1.3 Deferred closed
DMN13-73 need set operations and equality in FEEL DMN 1.1 DMN 1.3 Deferred closed
DMN13-76 notion of arbitrary order conflicts with lack of an unordered collection data type DMN 1.1 DMN 1.3 Deferred closed
DMN13-78 Unspecified conclusion DMN 1.1 DMN 1.3 Deferred closed
DMN13-79 We need a way to identify current date and time. I propose Now() DMN 1.1 DMN 1.3 Deferred closed
DMN13-91 Fix interchange of links to objects in BPMN/BMM DMN 1.2 DMN 1.3 Deferred closed
DMN13-90 Allow representation of black-box Decision Service DMN 1.2 DMN 1.3 Deferred closed
DMN13-44 Can an expression in user defined function body reference a name outside of it's scope? DMN 1.1 DMN 1.3 Deferred closed
DMN13-46 Should name declarations in same context fail or overwrite? DMN 1.1 DMN 1.3 Deferred closed
DMN13-47 Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test DMN 1.1 DMN 1.3 Deferred closed
DMN13-48 Rule 51.c doesn't support FEEL syntax of list with squary brackets as shown on page 122 DMN 1.1 DMN 1.3 Deferred closed
DMN13-50 Improvement of Semantic Domains Specification DMN 1.1 DMN 1.3 Deferred closed
DMN13-52 Semantic domain mapping for simple expressions DMN 1.1 DMN 1.3 Deferred closed
DMN13-65 Metamodel constraints & validation DMN 1.1 DMN 1.3 Deferred closed

Issues Descriptions

Incorrect claim about the Unicode character range and EBNF character expressions

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

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

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

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

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

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

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

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

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

  • Reported: DMN 1.2b1 — Mon, 31 Dec 2018 17:00 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Allow 4 or 6 hexadecimal digits for unicode code point

    See attached word doc

  • Updated: Tue, 26 Jan 2021 20:17 GMT
  • Attachments:
    • DMN13-127-v7.docx 19 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Should add a new unicode escape syntax

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

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

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

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

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

    "\u

    {1F40E}

    "

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

    "A" = "\u

    {41}

    "

    "è" = "\u

    {E8}

    "

    "査" = "\u

    {67FB}

    "

    "" = "\u

    {1F407}

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

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

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

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

    UnicodeEscapeSequence ::
    \u Hex4Digits
    \u

    { CodePoint }

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

  • Reported: DMN 1.2b1 — Fri, 8 Feb 2019 19:06 GMT
  • Disposition: Duplicate or Merged — DMN 1.3
  • Disposition Summary:

    Addressed by resolution of DMN-127

    DMN-127 adds \U, 6*hex digit to address this issue as well

  • Updated: Tue, 26 Jan 2021 20:17 GMT

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

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

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

  • Reported: DMN 1.2 — Mon, 26 Nov 2018 22:50 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add sourceElement and targetElement to DMNEdge

    Add a sourceElement and targetElement to the DMNEdge class so the actual DMNShape used as source and target can be resolved without graphical deduction.

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

Incorrect figure 6.10

  • Key: DMN13-244
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    Figure 6.10 has not been updated in line with issue DMN13-140.

  • Reported: DMN 1.2b1 — Tue, 3 Dec 2019 17:14 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Correct fig 6.10 and associated text

    Replace figure 6.10 & modify para 2 of section 6.3.1 so that UnaryTests is a subclass of Expression, rather than DMNElement.

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

PMML invocation output value in the case of single prediction

  • Key: DMN13-181
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    The proposal targets the case of a PMML invocation having a single output prediction(s), for the result to be simply the value result of such single prediction, instead of a context with 1 only entry, name of the single output prediction, and value of that prediction.

  • Reported: DMN 1.2 — Mon, 23 Sep 2019 14:34 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Do not wrap single values returned from PMML in context

    Executive summary

    The proposal targets the case of a PMML invocation having a single output prediction(s), for the result to be simply the value result of such single prediction, instead of a context with 1 only entry, name of the single output prediction, and value of that prediction.
    This would also align expected invocation behaviour similarly to what RTF agreed on when dealing with Decision Service, ref: https://issues.omg.org/browse/DMN13-163

    Rationale and details

    By the PMML specification, a ML predictive model can produce multiple outputs, so in general a (FEEL) Context is assumed to be returned by its invocation, containing a key-value pair of prediction name and value.

    However,
    Most PMML models have a single prediction as output.
    To get an idea, can reference examples presented on PMML website: http://dmg.org/pmml/pmml_examples/index.html

    Specifically to a well-known example, Iris dataset, Tree model: http://dmg.org/pmml/pmml_examples/KNIME_PMML_4.1_Examples/single_iris_dectree.xml
    This would imply every time a Decision invokes a BKM for the PMML prediction, something like:

    { class : "Iris-versicolor" }
    

    is returned, instead of simply getting back something like a FEEL string:

    "Iris-versicolor" 
    

    So it would make very annoying for dependent decision the need to always access the single prediction output in the key-value pair:

    result.class
    

    instead of more simply:

    result
    

    and other analogous implications.

    This proposal would align the expected behaviour to what what RTF agreed on when dealing with Decision Service, ref: https://issues.omg.org/browse/DMN13-163 for coercion of the singleton value, in the case of a single PMML output prediction.

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

A signature for the time() built in function is missing from table 66

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

    Section 10.3.2.3.4 time of the spec already says:
    [..] If no time offset is specified, the time is interpreted as a local time of day at some location, whose relationship to UTC time is dependent on time zone rules for that location, and may vary from day to day. [..]

    But table 66 show the signature time(hour, minute, second, offset) but does not show the signature time(hour, minute, second) which forces users to write time(08, 04, 32, null) when what they would want to write is simply time(08, 04, 32)

  • Reported: DMN 1.2b1 — Thu, 29 Aug 2019 12:54 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Make offset parameter optional in built-in function time()

    In Table 66 page 145 change time(hour, minute, second, offset) for time(hour, minute, second, offset?)

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

Decision Logic Examples

  • Key: DMN13-2
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    DMN 1.1 should provide examples of all types of decision model allowed by the standard, both graphically (DRD and decision table, where appropriate) and XML serialization. Currently missing:
    1. decision tables with an expression (more than a name) in inputExpression and outputExpression.
    2. decision tables with inputEntry or outputEntry referencing a "name" as defined by S-FEEL, i.e. not just a literal.
    3. DRD and decision table involving what Vanthienen calls "action subtables". All existing examples are "condition subtables".
    4. Serialization of crosstab format tables.
    5. Representation of literal values vs names in serialization.
    6. Representation of PMML and FEEL in the serialization.

  • Reported: DMN 1.0 — Sun, 12 Apr 2015 15:39 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add second example to Chapter 11

    See attached word doc for spec changes. See attached zip file for additions to examples.zip.

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

Disambiguation for Modulo / Remainder function

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

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

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

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

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

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

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

  • Reported: DMN 1.2b1 — Fri, 4 Jan 2019 18:38 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Improve the specification of the modulo builtin function

    The existing specification does not restrict the arguments to integers, and does not clearly define the sign of the result.

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

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

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

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

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

  • Reported: DMN 1.2b1 — Wed, 6 Feb 2019 21:26 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add interval builtins, range objects in semantic domain, and compact date literals

    See attached word doc

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

Incorrect grammar rule references and missing UnaryTests section in MM

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

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

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

  • Reported: DMN 1.2b1 — Tue, 5 Feb 2019 17:53 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Fix grammar rule references and add UnaryTests MM

    Specification Text
    See revised text.

    Metamodel

    • In Figure 7.6, Change UnaryTests class to inherit from Expression rather than directly from DMNElement
    • See attached Fig7_6

    XML Schema

    • Correct tExpression to make the typeRef attribute optional (as shown in the metamodel of Fig 7.6)
    • make tUnaryTests extend tExpression instead of tDMNElement

    Backward Compatibility Argument

    • Expressions that do specify a typeRef will still be valid when the typeRef in the XSD is corrected to be optional
    • UnaryTests that do not specify a typeRef will still be valid because the typeRef is optional
  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:

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

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

    The DMNv1.2 spec reports these two lines examples:

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

    However concerning the first referenced line, type1

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

    and type2:

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

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

    Similarly for the second referenced line, type 1:

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

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

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

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

    Analogous issue for the reported values of Conformance.

    Can you kindly verify and clarify if needed, please?

  • Reported: DMN 1.2b1 — Fri, 1 Feb 2019 14:07 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Replace 2 rows in table 40

    See attached word doc

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

type conversions are too spread out in Ch 10

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

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

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

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

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

  • Reported: DMN 1.2b1 — Wed, 30 Jan 2019 16:34 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add extra paragraph to clarify type conversions

    see attached word doc

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

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

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

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

  • Reported: DMN 1.2b1 — Tue, 27 Nov 2018 14:10 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Allow second operand of exponentiation to be a number

    The second operand of exponentiation should be allowed to be a number rather than limited to an integer

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

Decision Requirement Metadata Examples

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

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

  • Reported: DMN 1.2b1 — Tue, 21 May 2019 00:52 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Enhance Chapter 11 example with additional standard metadata

    Enhance Chapter 11 example with additional standard metadata, as attached.

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

Decision Service output value in the case of single output Decision

  • Key: DMN13-163
  • Status: closed  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Executive summary

    The proposal targets the case of a Decision Service having a single output decision(s), for the result to be simply the value result of such single decision, instead of a context with 1 only entry, name of the single output decision, and value of that decision

    Rationale and details

    with reference to figure from the spec Figure 11.7: Routing Decision Service, the use of the decision service in a literal expression would currently require to write something like:

    if Routing Decision Service( ..., ... ).Routing = "ACCEPT" then true else false
    

    please notice specify the .Routing would sound redundant and arguably some may say user-unfriendly in the scenario of a Decision Service with a single output decision.

    In the case of a Decision Service with a single output decision, we could more friendly have:

    if Routing Decision Service( ..., ... ) = "ACCEPT" then true else false
    

    In other words, the result of invoking the "Routing Decision Service" accordingly to this proposal would be:

    Routing Decision Service :  "ACCEPT"
    

    and not:

    Routing Decision Service :  { Routing : "ACCEPT" }
    

    as of today.

    Naturally when a Decision Service contains multiple output DecisionS, then is always the context, for instance taking example from DMN Spec Figure 11.6: Bureau Strategy Decision Service the result will continue to be:

    Bureau Strategy Decision Service :  { Strategy : ..., Bureau call type: ... }
    

    Proposal specification change

    With reference to document formal/19-01-05, chapter "10.4 Execution Semantics of Decision Services", page 151
    Replace the following:

    The execution semantics of S is FEEL(F): a function that when invoked with values from the FEEL semantic domain
    bound to the parameters representing input data and input decisions, returns a context consisting of all the output
    decisions' output values.

    with:

    The execution semantics of S is FEEL(F): a function that when invoked with values from the FEEL semantic domain
    bound to the parameters representing input data and input decisions, returns:

    • in the case of a single output decision(s), the single decision's output value.
    • in the case of multiple output decisions, a context consisting of all the output decisions' output values.
  • Reported: DMN 1.2 — Mon, 20 May 2019 15:30 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    clarify that single output decision service does not result in context but rather the single output value

    Executive summary

    The proposal targets the case of a Decision Service having a single output decision(s), for the result to be simply the value result of such single decision, instead of a context with 1 only entry, name of the single output decision, and value of that decision

    Rationale and details

    with reference to figure from the spec Figure 11.7: Routing Decision Service, the use of the decision service in a literal expression would currently require to write something like:

    if Routing Decision Service( ..., ... ).Routing = "ACCEPT" then true else false
    

    please notice specify the .Routing would sound redundant and arguably some may say user-unfriendly in the scenario of a Decision Service with a single output decision.

    In the case of a Decision Service with a single output decision, we could more friendly have:

    if Routing Decision Service( ..., ... ) = "ACCEPT" then true else false
    

    In other words, the result of invoking the "Routing Decision Service" accordingly to this proposal would be:

    Routing Decision Service :  "ACCEPT"
    

    and not:

    Routing Decision Service :  { Routing : "ACCEPT" }
    

    as of today.

    Naturally when a Decision Service contains multiple output DecisionS, then is always the context, for instance taking example from DMN Spec Figure 11.6: Bureau Strategy Decision Service the result will continue to be:

    Bureau Strategy Decision Service :  { Strategy : ..., Bureau call type: ... }
    
  • Updated: Mon, 30 Mar 2020 19:50 GMT

New FEEL URI needed

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

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

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

  • Reported: DMN 1.2 — Tue, 8 Oct 2019 16:18 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Update FEEL URI

    Update the URI for FEEL to https://www.omg.org/spec/DMN/20191111/FEEL/ as defined in DMN13-187.

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

Functions resolution

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

    FEEL supports function invocation described in rule 40, for example f(a, b, c)

    The specification doesn't describe in details how the function is resolved (name of function is bound to the function definition). For example:

    • what are the DMN / FEEL artifacts that the call can be bound to (e.g. DMN invocables visible in context)
    • how are the name clashes resolved (e.g. both a BKM and a buil-in function have the same signature)
    • how are the binding candidates built (e.g. apply all combinations of implicit conversions) and selected (e.g. exact match takes precedence)
  • Reported: DMN 1.2 — Wed, 18 Sep 2019 08:08 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Specify how functions are found in scope and argument types are checked

    See attached word doc

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

Update the copyright section


New acknowledgments needed

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

    The spec should keep track and acknowledge the work of all the people and companies involved.

  • Reported: DMN 1.2 — Tue, 15 Oct 2019 16:20 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Update acknowledgments section

    Update copyright list with all participating companies

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

New XML Namespace needed


DMN v1.2 specification


ranges do not map to the semantic domain

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

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

    Proposed remove section 10.3.2.7

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

    Covered by Range builtins

    See DMN13-139

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

No item definition for function definition

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

    If a function definition is the value expression of an information item, then that information item should have an item definition that gives the type of the function definition. E.g., the type of a function of two numeric arguments that returns their sum should be something like function(number, number) returns number but we have no way to express such an item definition

  • Reported: DMN 1.0 — Thu, 6 Aug 2015 22:40 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    add FunctionItem to ItemDefinition MM, XSD, and spec text

    See attached word doc

  • Updated: Mon, 30 Mar 2020 19:50 GMT
  • Attachments:
    • DMN12.xsd 22 kB (text/xml)
    • DMN13-7-v3.docx 86 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Need group artifact in DRD, metamodel, and XSD

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

    Group is an unfilled rectangle enclosing various elements in the DRD, with meaning defined by the modeler. It follows the usage defined by BPMN, an “artifact” with no operational semantics, simply an annotation of the model.

  • Reported: DMN 1.0 — Thu, 20 Aug 2015 00:13 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Add Group to spec, MM, and XSD fashioned after BPMN

    See attached word doc

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

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

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

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

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

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

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

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

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

    Correct the example in 10.3.2.5

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

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

FEEL does not support named ranges

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

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

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

    Covered by new Range builtins

    See DMN13-139

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

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

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

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

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

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

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

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

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

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

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

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

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

    Recommendation:

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

    use timeline semantics for comparison of dates

    see attached .docx file

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

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

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

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

    We think that the expected result should be: 3975.982590125552338278440100112431

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

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

    May be the decimal function is missing?

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

    3975.982590125552

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

    fix result of calculation

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

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

string built-in underspecified

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

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

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

    duplicate of dmn13-27

    duplicate of dmn13-27

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

Case-aware and case-insensitive

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

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

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

    changing semantics of identifiers is not backward compatible

    changing semantics of identifiers is not backward compatible

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

Disambiguation for Modulo / Remainder function

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

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

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

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

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

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

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

  • Reported: DMN 1.2b1 — Fri, 4 Jan 2019 18:34 GMT
  • Disposition: Duplicate or Merged — DMN 1.3
  • Disposition Summary:

    corrected in dmn13-125

    corrected in dmn13-125

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

instance of clarification

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

    Table 56 describes the semantics of the instance of operator.

    It does not specify the expected result if the instance of expression is incorrect. For example, there is syntactic error, the type name cannot be found (e.g. typo or missing import) or if the type expression is incorrect (e.g. list<> or context<>).

  • Reported: DMN 1.2 — Tue, 12 Feb 2019 10:40 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Clarify type lattice L and tie 'instance of' semantics to L

    see attached word doc

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

Make explicit reference to sample standard deviation

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

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

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

    Name(parameters) Parameter Domain Description Example
    stddev( list )
    stddev( n 1 , ..., n n )
    list is a list of number. n 1 ... n n are numbers. Returns the
    (sample) standard deviation of the list of numbers. If the list is empty,
    returns null. If the list contains only one number item, if n is a single number returns null.
    stddev( 2, 4, 7, 5 ) =
    2.0816659994661
    stddev( [ 47 ] ) = null
    stddev( 47 ) = null
    stddev( [ ] ) = null
  • Reported: DMN 1.2b1 — Fri, 18 Jan 2019 15:30 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Clarify the semantics of the stddev() function

    See revised text.

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

Wrong example in chapter "10.3.1.5"

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

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

    presents the following example:

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

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

    a=[a]
    

    therefore line 2 is problematic:

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

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

    It is proposed to replace the example as follows:

    [{a: {b: 1}}, {a: {b: [2.1, 2.2]}}, {a: {b: 3}}, {a: {b: 4}}, {a: {b: 5}}].a.b =
    [{b: 1}, {b: [2.1, 2.2]}, {b: 3}, {b: 4}, {b: 5}].b =
    [1, [2.1, 2.1], 3, 4, 5]
    
  • Reported: DMN 1.2b1 — Sat, 26 Jan 2019 09:34 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Fix typo in the example on chapter 10.3.1.5

    See revised text.

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

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

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

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

  • Reported: DMN 1.2b1 — Tue, 20 Nov 2018 17:12 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    Remove reference to SQL and PMML three value logic

    This reference to SQL and PMML is not needed and may lead to misinterpretation. Simply remove that reference.

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

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

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

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

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

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

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

    10.3.4.x Context function

    Table xx defines Context functions.

    Table xx: Semantics of Context functions

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

    Add get entries() and get value() functions to the function tables in chapter 10

    See revised text.

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

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

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

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

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:18 GMT
  • Disposition: Duplicate or Merged — DMN 1.3
  • Disposition Summary:

    duplicate of dmn13-126

    closed as duplicate

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

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

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

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

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

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

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

    Happy to be guided otherwise. An all advice appreciated.

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:00 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    change grammar rule 2.h. in ch 10 to use expression instead of textual expression

    see revised text

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

Minor typos in the FEEL grammar

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

    Typo in rule

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

    c. should have | at the end not ;

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

  • Reported: DMN 1.2b1 — Sat, 8 Dec 2018 19:36 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    fix minor typos in FEEL grammar rules

    see attachment

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

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

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

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

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

    Also, check spelling of "Stragegy" in Fig 11.30

  • Reported: DMN 1.2b1 — Wed, 10 Oct 2018 13:13 GMT
  • Disposition: Resolved — DMN 1.3
  • Disposition Summary:

    *Replace erroneous figures *

    Monthly.Income and Monthly.Expenses corrected in figure 11.28
    Typo corrected in figure 11.30

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

Need additional FEEL Types

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

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

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

    2. [0,’a’]

    3. [0,[1,2]]

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

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

    I suggest one or more of these as possible solutions:

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

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

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

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

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

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

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

Ambiguity between qualified name and path operation

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

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

    Example:

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

      results to

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

      results to

      ["jack", "jack"]

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

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

      results to

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

    Not an issue

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

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

Specification of type for instance of operator misses information

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

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

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

    and this the corresponding result: "true"?

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

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

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

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

    see attached documents

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

Missing semantic specification for FEEL for and quantified expression

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

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

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

    Issue addressed by "iteration context" added in 1.2

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

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

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

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

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

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

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

    spec is clear enough

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

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

Expressions in Input Entries

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

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

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

    Support expressions in DT input entries

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

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

Missing "date" FEEL type in some enumerations

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

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

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

    add missing 'date' type in several places in spec

    see revised text

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

Broken HTTP links


Description of Table 44 is out of place

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

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

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

    move 2 paragraphs following Table 46 to before Table 45

    move indicated text

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

Remove rule#32 additional name symbols from BNF

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

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

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

    non-backward compatible FEEL grammar change

    would need 2.0 RFP

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

Missing FEEL namespace in the header of the xml sample

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

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

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

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

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

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

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

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

    please verify and let's close

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

Typo in the sample xml

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

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

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

    Strategy is misspelled. See below:

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

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

    no "Stategy" in DMN 1.2 sample file

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

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

Broken HTTP links


Additional name symbols

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

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

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

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

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

    non-backward compatible FEEL grammar change

    would need a 2.0 RFP

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

SFEEL grammar readbility

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

    The grammar contains several sub-grammars each one with its own start non-terminal: expression, simple expressions, simple unary tests.

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

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

    SFEEL is deprecated

    No editorial changes for SFEEL

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

Naming inconsistency

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

    Naming inconsistency in Figure 70.

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

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

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

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

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

Figure 70 does not correspond to example file

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

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

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

    Chapter 11 example xml has been fixed

    Fixed in 1.2 (generated from same tool)

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

Is really only name allowed in a FEEL path?

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

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

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

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

    submitter agrees there is no issue

    no issue here

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

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

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

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

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

    ambiguity per se is not a serious issue

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

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

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

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

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

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

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

    0 input tables (with collect policy) behave as relations

    may be useful for level 2 implementations

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

Bug in specification of the ‘Any’ Hit Policy

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

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

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

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

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

    DMN 1.2 provides annotation columns as well as result columns

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

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

BigDecimal is not the only mapping of number to Java

  • Key: DMN13-1
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Clause 10.3.2.9 shows FEEL number values as mapped to XML decimal, integer, and double, but the only mapping to Java is to BigDecimal. The appropriate mapping to Java, like the appropriate mapping to XML, depends on the range and intent of the data element. BigDecimal is rarely used for anything but currency. Java int and double are much more likely to be appropriate for most data items. The mapping of number to Java should be just as flexible as the mapping to XML and PMML.

  • Reported: DMN 1.0 — Wed, 9 Jul 2014 21:23 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

FEEL operators in names

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

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

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

    non-backward compatible FEEL grammar change

    would need 2.0 RFP

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

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

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

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

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

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

    withdrawn by submitter

    Do not see much value here.

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

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

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

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

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

    RTF 1.3 is ending

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

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

No notation for ItemDefinition

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

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

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

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

    RTF 1.3 is ending

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

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

Business Context links go both ways

  • Key: DMN13-3
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

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

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

    RTF 1.3 is ending

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

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

Spaces and additional characters in names / identifiers

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

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

    I suggest the following approach:

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

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

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

    non-backward compatible change to FEEL and metamodel

    would need to wait for 2.0 RFP

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

null is not defined in the S-FEEL grammar

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

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

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

    we decided in DMN 1.2 to "deprecate" SFEEL.

    We should not change SFEEL anymore.

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

Semantics of variable in decision table input entry

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

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

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

    No longer an issue

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

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

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

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

    Some built-in functions has optional parameters. Chapter 10.3.4 describes "Whenever a parameter is outside its domain, the result of the built-in is null."

    Should the following call to a built-in function result to null?

    replace("This is a string", "[a-z]", "#", null)
    

    The optional parameter "flags" of the built-in function replace() is null. Parameter domain is string as stated in table 60 on page 133. Null is not in the domain of type string.

    This topic was already discussed in the DMN TCK. We think that the behavior should be the same as the function is called without the optional parameter:

    replace("This is a string", "[a-z]", "#", null) = replace("This is a string", "[a-z]", "#")
    

    Clarification in the specification is appreciated.

    May be we can change the sentence in chapter 10.3.4 on page 130 to: "Whenever a parameter is outside its domain, the result of the built-in is null. If null is passed as value to an optional parameter, the built-in behaves like no value is passed."

  • Reported: DMN 1.1 — Tue, 10 Oct 2017 14:32 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

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

    Chapter 10.3.2.3.4 time, 10.3.2.3.5 date, 10.3.2.3.6 date-time, 10.3.2.3.7 days and time duration and chapter 10.3.2.3.8 years and months duration defines each a value function. For date time arithmetic operations it would be useful to have this value available in the FEEL semantic domain. Therefore we suggest to add a new property value that is directly available for values of this type. Return type of the value if always a number.

    Table 53 should be adjusted accordingly.

  • Reported: DMN 1.1 — Tue, 10 Oct 2017 09:57 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

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

    The specification says that the addition/subtraction of a date and time and a years and months duration value is defined as:

    date and time (
       date(e1.year +/– e2.years + floor((e1.month+/– e2.months)/12),
       e1.month +/– e2.months – floor((e1.month +/– e2.months)/12) * 12,
       e1.day), 
       time(e1))
    

    If you apply this expression to the following two values:

    • date and time("2017-08-30T11:00:00Z")
    • duration("P18M")
      you would expect the following results:
    date and time("2017-08-30T11:00:00Z") + duration("P18M")  --> result should be date and time("2019-02-28T11:00:00Z")
    date and time("2017-08-30T11:00:00Z") - duration("P18M")  --> result should be date and time("2016-02-29T11:00:00Z")
    

    If you apply the values to the defined formula, you get:

    date and time (
       date(2017 +/– 1 + floor((8 +/– 6)/12),
       8 +/– 6 – floor((8 +/– 6)/12) * 12,
       30), 
       time("11:00:00Z"))
    

    Addition
    which results for addition into:

    date and time (
       date(2018 + floor(1,1667),
       14 – floor(1,1667) * 12,
       30), 
       time("11:00:00Z"))
    

    which is:

    date and time (date(2019, 2, 30), time("11:00:00Z"))
    

    The adjustment to the last valid day in a month is missing. 30th February is invalid, since February has only 28/29 days.

    Subtraction
    which results for subtraction into:

    date and time (
       date(2016 + floor(0,1667),
       2 – floor(0,1667) * 12,
       30), 
       time("11:00:00Z"))
    

    which is:

    date and time (date(2016, 2, 30), time("11:00:00Z"))
    

    The adjustment to the last valid day in a month is missing. 30th February is invalid, since February has only 28/29 days.

    Recommendation:
    Adjustment to last valid day in month must be added to spec.

  • Reported: DMN 1.1 — Mon, 2 Oct 2017 12:41 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Improve description of built-in function string()

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

    The expected output of the built-in function string() should be defined for each type. Otherwise it is unclear what the result for a value, for example of type time, is. Is it the string literal or the full expression with built-in function time()?

    // which FEEL expression is valid?
    string(time("11:00:00")) = "11:00:00"
    string(time("11:00:00")) = "time("11:00:00")"
    

    Recommendation: Introduce a new table that lists example outputs for all types:

    • null -> null
    • boolean -> "true" or "false"
    • string -> "This is a string"
    • number -> "-1.234"
    • date -> "2017-10-11"
    • time -> "11:00:00.123" or "11:00:00.123+02:00" or "11:00:00.123@Europe/Paris"
    • date and time -> "2017-10-11T11:00:00.123" or "2017-10-11T11:00:00.123+02:00" or "2017-10-11T11:00:00.123@Europe/Paris"
    • days and time duration -> "P2DT3H4M5.123S"
    • years and months duration -> "P2Y3M"
    • list -> "[1,2,3]"
    • context -> "{a: true, b: false}"
    • range -> "[1..100]"
    • unary test -> "> 10"
    • function -> null
  • Reported: DMN 1.1 — Wed, 11 Oct 2017 09:02 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

FEEL grammar readbility

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

    The grammar contains several sub-grammars each one with its own start non-terminal: expression, simple expressions, unary tests.

    The grammar should be broken in several grammars, and common part to make things more obvious. It will help the CL3 implementation.

  • Reported: DMN 1.1 — Sun, 30 Oct 2016 11:37 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Lexical representation of time string has ambiguous definitons

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

    A lexical time string is defined o page 131 by XML Schema Part 2 Datatypes (for local times and offset times) and by ISO 8601 with the extended form of a local time (for zoned times).

    Unfortunately XML Schema Part 2 and ISO 8601 has different definitions. Therefore it is unclear which of them to use. Or are both of them valid?

    Additionally the user should not have different lexical time string formats for a local time, an offset time or a zoned time.

    The list of ambiguities:

    • ISO 8601 allows a leading "T" character prefix. XML Schema Part 2 does not.
    • ISO 8601 allows optional seconds. In XML Schema Part 2, the seconds are mandatory.
    • ISO 8601 allows decimal fraction for seconds and minutes. XML Schema Part does not allow this.
    • ISO 8601 allows 00:00:00 and 24:00:00 for midnight. XML Schema Part 2 only allows 00:00:00.
    • ISO 8601 allows time offset of hours only. Minutes are optional. XML Schema Part 2 always requires minutes.

    Therefore clarification is needed. Which definitions are valid for FEEL? The stricter XML Schema Part 2 or the more user friendly ISO 8601 spec?

  • Reported: DMN 1.1 — Mon, 13 Nov 2017 15:24 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

More Generic Ways to Define Decision Table Properties

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

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

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

    RTF 1.3 is ending

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

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

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

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

    While the scope of context entry specifically says to include the previous context entry (section 7.3.1), there is no mention for the scope of input and output entries of decision tables.

  • Reported: DMN 1.1 — Mon, 15 May 2017 17:59 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

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

    in chapter 10.3.2.10: "Sometimes we do not want to evalutate a FEEL expression e, we just want to know the type of e."

    in table 54: column Applicability defines which row in the table to use, depending on the type of a FEEL expression.

    Table 54 only makes sense if it is not allowed to pre-evaluate the expression e2, since even for a pre-evaluation context entries (for example: "item") must be declared in scope.

    How do we know the type of a FEEL expression if it is not allowed to evaluate it?

    Examples:

    • [1,2,3][min(3,2,1)]
    • {a:function() external {java: {class: "clazz", method signature: "method()"}}, b:[1,2,3][a()]}.b
    • {a: 1, b: a instance of number, c: [1,2,3][b] }
  • Reported: DMN 1.1 — Wed, 3 May 2017 14:56 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

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

    This is a suggestion for future versions of the spec:

    Add support for Unary Tests as first class citizens of the FEEL language, in a similar way as ranges and functions already are.

    A unary test is really a “predicate”: a single parameter function that returns a boolean. It is syntax sugar on:

    function ( x ) x in <unary_test>

    FEEL already supports functions as first class citizens, so it makes sense to support Unary Tests. The following two syntaxes would then be equivalent:

    is minor : < 18
    is minor : function( age ) age in < 18

    Invoking unary tests explicitly would be like invoking a function:

    Bob is minor : is minor( bob.age )

    More importantly, it would allow the implementation to actually support passing unary tests as parameters to functions and make the example on page 115 viable:

    decision table (
    outputs: "Applicant Risk Rating",
    input expression list: [Applicant Age, Medical History],
    rule list: [
    [ >60, "good", "Medium" ],
    [ >60, "bad", "High" ],
    [ [25..60], -, "Medium" ],
    [ <25, "good", "Low" ],
    [ <25, "bad", "Medium" ]
    ],
    hit policy: "Unique"
    )

    Unary test syntax is not ambiguous, so supporting it would mean to basically change rule 2 in the grammar to include rules 14 and 17 as possible options. The semantic mapping table on page 116 would also need to include a new FEEL value type: "unary test".

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

    RTF 1.3 is ending

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

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

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

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

    This is a suggestion for future revisions of the specification:

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

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

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

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

    RTF 1.3 is ending

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

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

Include Test Cases in Decision Model

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

    For interchange of test cases along with a decision model, it would be convenient to define metamodel and xsd elements for a suite of test cases, where a test case contains values for input data and expected values output decisions.

  • Reported: DMN 1.1 — Sat, 28 May 2016 16:25 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Change depiction of Input to be harmonized with BPMN and CMMN


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

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

    The processing of lists of data is fundamental to business decisions. Some kind of multiplicity should be indicated at the DRD level, and iteration should be supported visually at the decision logic level. In spite of the attached figures (meant to provoke discussion), the scope of this issue is limited to "flat" DRDs, that is, no "sub-DRDs" nested inside an outer decision or BKM. DRD proposal should specify what the multiplicity marker or other DRD notation looks like, and where it may appear, e.g. attached to head or tail of a requirement arrow, or inside a decision or BKM shape left of the name, etc.

  • Reported: DMN 1.1 — Wed, 4 May 2016 08:49 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

XSD: global context

  • Key: DMN13-10
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

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

  • Reported: DMN 1.0 — Sun, 31 May 2015 16:35 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

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

    literal expression is used in MM, and textual expression is used in grammar. Let's use 1 consistently, but check that they are really the same concept.

  • Reported: DMN 1.0 — Thu, 16 Jul 2015 16:30 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Business Knowledge Model can have Information Requirements

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

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

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

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

    RTF 1.3 is ending

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

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

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

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

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

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

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

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

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

  • Reported: DMN 1.1 — Thu, 8 Mar 2018 16:20 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Add two new concrete numeric types, make number abstract

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

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

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

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

    Here is my proposal:

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

    If we agree in principal all start working on it.

  • Reported: DMN 1.1 — Wed, 6 Dec 2017 13:44 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Formally define enumerations and use throughout

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

    Item Definitions can share constraints and these constraints are specified as unary tests. This allows definitions such as requiring a positive number ( >0) or restricting a field to a specific value ("high", "medium", "low").

    However this requires enumerations to be strings and does not allow enumerations to be managed (sorted for instance). In addition, an enumerated list might be used for a set of Information Items but it must be repeated in Decision Tables when columns are meant to be restricted to the list of values.

    DMN should allow for the creation and management of enumerations:

    • Name
    • Description (optional)
    • List of enumerated values (optionally with a sort order)

    These enumerations should be considered symbolic constants, not strings

    FEEL functions should be created to:
    Get the list of of allowed values for a specified enumeration
    Check a value against an enumeration to see if it is an allowed value for that enumeration
    Check the sort order of some specified values in the context of an enumeration

    Decision Tables should be able to reference an enumeration by name in the value list row
    Information Items should be able to be linked to an enumeration

  • Reported: DMN 1.1 — Thu, 26 Oct 2017 16:12 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions

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

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

  • Reported: DMN 1.1 — Fri, 3 Aug 2018 21:19 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Should encapsulated decisions of a decision service include output decisions?

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

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

    {Decision 1, Decision 2}

    "

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

    {Decision 1}

    ".

    Table 20 on page 56:

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

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

  • Reported: DMN 1.0 — Tue, 20 Mar 2018 14:49 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Wrong character in expression for PMT function definition

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

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

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

    Fixed:

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

  • Reported: DMN 1.1 — Fri, 2 Feb 2018 10:32 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Requested additional built-in functions

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

    (from Bruce)
    a. String-join(stringList, separatorString)

    b. Format-number(value, formatString), where formatString (to be negotiated) generally follows Excel or xpath, maybe not all the features.

    c. Format-date(value, formatString), format-dateTime(value, formatString)

  • Reported: DMN 1.1 — Mon, 2 Jan 2017 20:43 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Collect decision tables

  • Key: DMN13-69
  • Status: closed  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    (1) The spec says "Collect: returns all hits in arbitrary order. An operator (‘+’, ‘<’, ‘>’, ‘#’) can be added to apply a simple function to the outputs. If no operator is present, the result is the list of all the output entries.". This is confusing - as I understand it if an operator is present a collect hit policy does not return all hits, only the result of the operation.

    (2) The spec should state clearly what result is returned by Collect decision tables when no rules fire. In particular the result of a C+ decision table is not clear, because the result of sum([]) is undefined. I think a case could be made (based on a recursive definition) that the sum of an empty list is zero, which would be a much more useful result from the decision table than null. In general, section 10.3.4.4 restricts the semantics of all list functions to non-empty lists, although some functions have natural and useful results for the empty list e.g. count([])=0, sum([])=0, sublist([],x,y)=[], append([],items)=[items], concatenate([],items)=items, reverse([])=[], union([],items)=[], distinct values([])=[], flatten([])=[].

    (3) Why is the result of C+ defined as "sum of all the distinct outputs" rather than just "sum of all the outputs"? I would say that if three rules fire proposing the value 5, the C+ result should be 15, not 5.

  • Reported: DMN 1.1 — Thu, 13 Oct 2016 08:25 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

FEEL ambiguity

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

    FEEL grammar is ambiguous. Rule 2.i is ambiguous for identifiers like Person, as it can lead to two parse trees, one with QualifiedName the other with Name in it. See rule for simple value.

    Rule 1 is ambiguous as there is an overlap between textual expression and boxed expression. I suggest breaking the grammar in several grammars with a common part. This ambiguity will just go away as soon as we do that.

  • Reported: DMN 1.1 — Sun, 30 Oct 2016 11:41 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

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

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

  • Reported: DMN 1.1 — Wed, 24 Aug 2016 16:45 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

need set operations and equality in FEEL

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

    some notes toward a proper description:
    FEEL has ordered lists and some set builtins, e.g. distinct values and union. Lacks intersection and equality.

    [1,2] in (1,2,[1,2], 3) is true

    intersect([1,2,3], [3,1,4]) = [1,3]

    set equals([1,1,3], [3,1]) is true
    probably - distinct values([1,1,3]) = distinct values([3,1])
    maybe change to set([1,1,3]) = set([3,1])
    (set needs to both remove dups and return elements in canonical order)
    what is canonical order [null, 0, {}, []]?
    [1,3] = [3,1] is false

    Another option is to add sets to FEEL semantic domain (along with lists, numbers, contexts, ...). And need syntax.

    simpler and more biz friendly proposal - add 'contains any' and 'contains all' as boolean infix operators taking 2 lists as LHS and RHS. And allow these to be added to unary tests w/o a '?'. E.g. 1,2,3 , in (1,2,3) , contains any (1,2,3), contains all (1,2,3). First 2 are what we have now (2nd allowed for symmetry). Last 2 assume input expr is a list (set).

    if we just add set oriented builtins, but no friendlier syntax, this may not solve the biz problem of allowing DTs to process sets in a user friendly way. Too many ()s and ?s

  • Reported: DMN 1.1 — Thu, 11 Aug 2016 15:35 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

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

    Section "8.2.11 Hit policy" describes that hit policy "Collect: returns all hits in arbitrary order". This implies that the order of the results does not have to be deterministic and can also vary among different implementations. However, the standard only supports the notion of 'lists', which do have an order. The comparison of lists is also specified in a way that the order of elements is significant. The issue might get more clear when thinking about testing the interface of decisions. Strictly speaking, it is currently not feasible to define a test against a decision table with hit policy 'collect'. The expected result can only be defined using a list, whose elements do have an order. The operator to compare the 'expected' and the 'actual' result will also take order into account.

    The issue could easily be resolved by replacing 'arbitrary order' with 'rule order'.

  • Reported: DMN 1.1 — Sun, 26 Jun 2016 10:11 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Unspecified conclusion

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

    I remember discussions about allowing "-" in conclusions to mark an unspecified conclusion in a decision table. This would allow some of the conclusions in a multiple output decision table to be marked as "unspecified" where there was no output relevant for that conclusion for a specific rule and to allow rules in multi-hit tables to show that a particular combination of conditions had been considered but did not result in anything being added to the result set.
    However the standard as written says that an output entry must adhere to the literal expression grammar, and '-' is not allowed. You have to return some FEEL value, e.g. 0, false, "N/A", null, etc.

  • Reported: DMN 1.1 — Mon, 13 Jun 2016 21:41 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

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

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

    We need to be able to compare to the current date and time
    e.g.
    Now() as a unitary test
    or
    Now() = a specified date and time

  • Reported: DMN 1.1 — Thu, 2 Jun 2016 15:54 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Fix interchange of links to objects in BPMN/BMM

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

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

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

    RTF 1.3 is ending

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

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

Allow representation of black-box Decision Service

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

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

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

    RTF 1.3 is ending

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

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

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

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

    If an expression in a user defined function body references a name outside of it's scope (for example a parent scope), this scope must be available also during invocation of the function.

    Examples:

    • {f:function() a, a:1, i:f()}

      possible, since name a is still available in local context (scope) during invocation

    • {b:1,f:function() b}

      .f() impossible, since name b is not available outside of the context.

    It would be nice if the semantic mapping and the differentiation between function definition and invocation is clearly specified in the spec. What names can be referenced? Must the scopes also be available during invocation?

  • Reported: DMN 1.1 — Wed, 3 May 2017 15:24 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Should name declarations in same context fail or overwrite?

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

    As I see the spec doesn't define what should happen if in a context a name should be declared that already exists in the current context. Sample FEEL expression: "for i in [1,2,3], i in [4,5,6] return i * i" Does the second definition of i overwrite the first one or should we return null for the complete "for" expression?

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

    RTF 1.3 is ending

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

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

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

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

    For simple positive unary test(s) there are extra entry points in the FEEL grammar. Therefore why do we need simple positive unary test in grammar rule 2.i. What is the semantic mapping?

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

    RTF 1.3 is ending

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

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

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

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

    on page 122 in table 43 in row 2 and 3: "e1 in [e2, e3, ...]"
    on page 109 grammar rule 51.c: expression "in" positive unary test
    on page 109 grammar rule 51.c: expression "in" "(" positive unary tests ")"

    The syntax with square brackets is not allowed by the grammar rules 51.c. Either table 43 or grammar definition should be changed.

  • Reported: DMN 1.1 — Wed, 3 May 2017 08:58 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Improvement of Semantic Domains Specification

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

    The definition of Semantic Domains / Types in 10.3.2 does not contain:

    • a metamodel
    • relationships between various types

    I propose adding a metamodel and the following two relationship:

    1. Conforms To
    A semantic domain T1 conforms to a semantic domain T2 when an instance of T1 can be substituted at each place where an instance of T2 is expected.

    2. Equivalent To
    A semantic domain T1 is equivalent to a domain T2 iff they have the same name and the corresponding embedded semantic domains are equivalent. (e.g. List<Number> is equivalent only to List<Number> not List <String>).

    The above relationships should be defined via tables, similar to the ones used to describe the semantics of logic operators (page 119 Table 38).

  • Reported: DMN 1.1 — Thu, 30 Mar 2017 12:38 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Semantic domain mapping for simple expressions

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

    The FEEL grammar contains simple expressions as starting terminal

    page 107 6. simple expressions = simple expression ,

    { "," , simple expression }

    ;

    I could not find a mapping to a semantics domain for it. What is the type / domain of "simple expressions"? A list with element type Any or a Tuple Type with several element types?

  • Reported: DMN 1.1 — Fri, 17 Mar 2017 14:42 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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

Metamodel constraints & validation

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

    None of the metamodels contain logic constraints. For example, the name of a decision table is the same with the name of the variable defined inside of the decision table tag (invariant at decision table level).

    Ideally these constrains would be used to validate the diagrams before execution (e.g. generating code from Java). Bruce Silver's already covers some of the. We should add them and more in the spec.

    I think the metamodel constraints should be described with OCL – see the UML metamodels. There should be constraints for CL1, CL2 and CL3. It’s very likely the CL3 constraints will be a superset of CL2 constraints.

  • Reported: DMN 1.1 — Sun, 30 Oct 2016 11:45 GMT
  • Disposition: Deferred — DMN 1.3
  • Disposition Summary:

    RTF 1.3 is ending

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

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