Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — Open Issues

  • Acronym: DMN
  • Issues Count: 71
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN17-71 Updated type conversion contexts misses some scenarios and need to be more encompassing DMN 1.5 open
DMN17-70 Chapter 11 example models contain a lot of vendor specific "noise". DMN 1.5 open
DMN17-69 Spec compliance issues with Chapter 11 example models. DMN 1.5 open
DMN17-68 DMN 1.5 changebar PDF does not show changes from 1.4 DMN 1.5 open
DMN17-67 date() conversion function should return null for invalid dates DMN 1.5b1 open
DMN17-66 Wrong placement of useAlternativeInputDataShape attribute in the DMN specification document DMN 1.5b1 open
DMN17-65 Frequently changing Namespace URIs cause market fragmentation DMN 1.5b1 open
DMN17-64 ambiguity for collections DMN 1.4b1 open
DMN17-61 XML serialization is not human friendly DMN 1.5b1 open
DMN17-59 No binding to Python functions DMN 1.5 open
DMN17-57 It is not possible to assign a default value to a data type DMN 1.4 open
DMN17-56 No way to show dependencies of a grey-box decision service DMN 1.5 open
DMN17-58 Relation conforms to and equivalent do not cover functions with variable arguments DMN 1.5b1 open
DMN17-63 Clarification on the FEEL sort function with the precedes function DMN 1.5b1 open
DMN17-62 Knowledge Sources are not fit for ML or AI purposes DMN 1.5 open
DMN17-60 Duplicated names and labels DMN 1.5b1 open
DMN17-48 Allow for partial temporal values DMN 1.3 open
DMN17-50 Allow input data to be of type Interval DMN 1.3 open
DMN17-49 Adding a new interval built-in function DMN 1.3 open
DMN17-51 Links with other standards DMN 1.3 open
DMN17-54 Importing libraries of functions is not business friendly DMN 1.4b1 open
DMN17-55 Interchanging models that use external libraries of functions is complicated DMN 1.4b1 open
DMN17-52 Missing InformationItem Association? DMN 1.3 open
DMN17-53 Functions cannot invoke external services DMN 1.4 open
DMN17-42 DRG requirements only state am unused knowledge requirement is illegal DMN 1.3 open
DMN17-40 Spec does not mandate that all user-defined function parameters are utilised DMN 1.3 open
DMN17-41 Spec does not mandate that all formal parameters are utilised. DMN 1.3 open
DMN17-44 P0D == P0Y in SFEEL, but it is unclear if P0D == P0Y in FEEL DMN 1.3 open
DMN17-45 the operation of is() function is not well specified DMN 1.3 open
DMN17-47 FunctionItem `parameters` array attribute is plural, not singular in name DMN 1.3 open
DMN17-43 No way to show relative multiplicity of decisions and their information requirements DMN 1.3 open
DMN17-46 Ambiguous named params for before() and after() range functions DMN 1.3 open
DMN17-34 Clarification on DMN case sensitivity of timezones DMN 1.2 open
DMN17-36 Inconsistency DMNv1.2 dropping [a]=a and get entries example DMN 1.2b1 open
DMN17-35 properly define type(e) DMN 1.2 open
DMN17-37 "instance of" not possible with some built-in functions DMN 1.2b1 open
DMN17-38 Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests. DMN 1.3 open
DMN17-39 Add an itemKind property to ItemDefinition DMN 1.3b1 open
DMN17-28 Shared Data Model and Notation (SDMN) DMN 1.2b1 open
DMN17-29 Temporal precision inconsistencies DMN 1.2b1 open
DMN17-30 Provide better spec and examples for Equality, Identity, and Equivalence DMN 1.2b1 open
DMN17-33 Support for recursive calls by Business Knowledge Models DMN 1.2 open
DMN17-31 Friendlier handling of null values DMN 1.2b1 open
DMN17-32 Lack of visual notation for processing of / iteration over lists in FEEL DMN 1.2 open
DMN17-22 need set operations and equality in FEEL DMN 1.1 open
DMN17-20 Metamodel constraints & validation DMN 1.1 open
DMN17-21 In section 7.3.1 Expression Meta-Model: there is no table to display the typeRef attribute added by Expression to DMNElement DMN 1.1 open
DMN17-19 Requested additional built-in functions DMN 1.1 open
DMN17-23 notion of arbitrary order conflicts with lack of an unordered collection data type DMN 1.1 open
DMN17-26 DMN Models need a default timezone DMN 1.2 open
DMN17-24 Unspecified conclusion is not supported DMN 1.1 open
DMN17-27 inconsistent date comparisons make unavoidavle paradoxes DMN 1.2 open
DMN17-25 Fix interchange of links to objects in BPMN/BMM DMN 1.2 open
DMN17-10 Can the same Definitions/namespace be used by more than one model? DMN 1.1 open
DMN17-15 Can an expression in user defined function body reference a name outside of it's scope? DMN 1.1 open
DMN17-16 Should name declarations in same context fail or overwrite? DMN 1.1 open
DMN17-18 Semantic domain mapping for simple expressions DMN 1.1 open
DMN17-17 Missing FEEL semantic mapping for grammar rule 2.i - simple positive unary test DMN 1.1 open
DMN17-11 Add two new concrete numeric types, make number abstract DMN 1.1 open
DMN17-14 How to get FEEL type if evaluation is not an option? DMN 1.1 open
DMN17-12 FEEL grammar readability DMN 1.1 open
DMN17-13 Scope of decision table input/output entries is not well defined in the specification DMN 1.1 open
DMN17-4 Enhancement suggestion: make unary tests first class citizens of the FEEL language DMN 1.1 open
DMN17-6 Should encapsulated decisions of a decision service include output decisions? DMN 1.0 open
DMN17-5 Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions DMN 1.1 open
DMN17-3 Include Test Cases in Decision Model DMN 1.1 open
DMN17-2 italics and bold used for both typographic literal notation and FEEL semantic exposition DMN 1.0 open
DMN17-7 No adjustment for last day in month if duration is added/subtracted to date and time value DMN 1.1 open
DMN17-9 Improve description of built-in function string() DMN 1.1 open
DMN17-8 Clarification needed if null is passed as value for optional parameter of built in function DMN 1.1 open
DMN17-1 Business Context links go both ways DMN 1.0 open

Issues Descriptions

Updated type conversion contexts misses some scenarios and need to be more encompassing

  • Key: DMN17-71
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The new-for-1.5 text in "10.3.2.9.4 Type conversions" is a welcome addition, but many type safety / conversion scenarios remain undefined in behaviour.

    The undefined behaviour surrounds the use of explicit spec-supported typeRefs not covered by the new text. Indeed, I think the contexts under which type conversions are made can be simply defined and made broader in scope.

    In short, TLDR: "any element with an explicit typeRef SHALL be subject to conversion". I'll elaborate on this more at the end.

    The current definition is relatively narrow and perhaps focuses on how a human interacting with a DMN UI may use DMN. It may not always be humans creating DMN models ..

    The spec support explicit typeRefs at many places. Here are some examples of conversions not covered but the new spec text:

    • example: inputData typeRef

    ```
    <inputData name="input_001" id="_input_001">
    <variable name="input_001" typeRef="string"/>
    </inputData>
    ```

    Despite the explicit typeRef, the spec does not mandate type conversion on value assignment to an inputData. It refers to "DRG element's logic".

    • example: a boxed list that types some or all elements

    A boxed list could be used as a typed tuple. The typing of a list is for all elements of the list so therefore is not suitable here. The individual elements can be typed so a typed tuple could be:

    ```
    <list>
    <literalExpression typeRef="string"><text>someStringFunction()</text></literalExpression>
    <literalExpression typeRef="number"><text>someOtherFunctionThatReturnsString()</text></literalExpression>
    </list>
    ```

    The list elements should be subject to conversion with element 2 being null as it has an explicit typeRef, but a value being bound to it does not conform. At this time, the spec does not mandate type conversion on 'inner' elements of boxed expressions - just on the final DRG return type as it is bound to a variable in the global scope.

    The same could apply for data-type conversions such as a singleton list:

    ```
    <list>
    <literalExpression typeRef="string"><text>someStringFunction()</text></literalExpression>
    <literalExpression typeRef="number"><text>[123]</text></literalExpression>
    </list>
    ```

    The value of the second element should be coerced to just 123. I think implicitly, this is what we would expect, but the spec leaves this undefined.

    • example: a typed context entry:

    ```
    <contextEntry>
    <variable typeRef="number" name="foo"/>
    <literalExpression>
    <text>someFunctionThatReturnsAString()</text>
    </literalExpression>
    </contextEntry>
    ```

    The context entry (informationItem) typeRef specifies a number, but a string value is being bound to it - it should be null. The spec does not cover this.

    • example: An expression inside the logic of a BKM as such:

    ```
    <businessKnowledgeModel name="bkm_001" id="_bkm_001">
    <variable name="bkm_001"/>
    <encapsulatedLogic>
    <formalParameter name="arg1"/>
    <literalExpression typeRef="number">
    <text>someFunctionThatReturnsString(arg1)</text>
    </literalExpression>
    </encapsulatedLogic>
    </businessKnowledgeModel>
    ```

    In this case, neither the BKM nor the encapsulatedLogic is typed, but the expression of the logic is (or it could also be any nested boxed expression contained with it - you get the idea). With the above BKM example, the function invocation result should be null - the expression type is for number, but it calls something that ends up returning a string.

    With might also expect a singleton list to be converted. I think this what we would expect, but, as I read it, this is outside the spec.

    • example: An BKM typeRef defines an outputTypeRef.

    ```
    <itemDefinition name="tMyFuncType">
    <functionItem outputTypeRef="number">
    <parameters name="arg1"/>
    </functionItem>
    </itemDefinition>

    <businessKnowledgeModel name="bkm_001" id="_bkm_001">
    <variable name="bkm_001" typeRef="tMyFuncType"/>
    <encapsulatedLogic>
    <formalParameter name="arg1"/>
    <literalExpression typeRef="number">
    <text>someFunctionThatReturnsString(arg1)</text>
    </literalExpression>
    </encapsulatedLogic>
    </businessKnowledgeModel>
    ```

    The above BKM has a (functionType) typeRef. The BKM satisfies that typeRef. However, runtime invocations may not satisfy the functionItem return type.

    Strictly speaking, when the BKM "DRG Element’s logic" (function) is bound to the variable "bkm_001" it does indeed match the typeRef expectations of the functionType - the informationItem variable of a BKM holds a function, not the return value of an invocation. Currently, the spec says the variable binding is subject to conversion. But, the spec does not cover the type expectations of actually _invoking the BKM. The outputTypeRef specifies a number, but an encapsulatedLogic expression may provide a string.

    Again, I think implicitly this is what we would expect - but it is undefined.

    • Where should conversion occur?

    The 1.5 spec text explicitly defines where conversions can occur in section "10.3.2.9.4 Type conversions" paragraph "There are several kinds of contexts in which conversions may occur".

    • filter contexts. Fair enough. No change required
    • Invocation parameters - this is really binding a value to a typed InformationItem
    • DRG Element logic result bound to variable. This is also binding a value to a type InformationItem.

    As you can see from the above, this needs to be broadened and made more complete. I believe conversions should occur at all places the spec supports a typeRef.

    The spec model defines typeRefs for the following:

    • all expressions, except for UnaryTests
    • informationItems
    • itemDefinitions, including their "itemComponent"s as well as the (informationItem) parameters of functionItems and the "outputTypeRef" of functionItems
    • the outputClauses of decisions
    • the iterators of for/some/every boxed expressions

    I suggest amending the "There are several kinds of contexts in which conversions may occur" paragraphs text to the following.

    • Filter context (10.3.2.5) in which a filter expression is present. The expression to be filtered is subject to implicit conversion to singleton list.
    • Any DMN model element that has an explicit typeRef SHALL be subject to conversion. For elements that may have a value bound to them such as all InformationItems, iterators of boxed expressions, and the result values of outputClauses of decisions the conversion takes place at the moment the value is bound. InformationItems includes such elements as DRG Element variable bindings (including inputData), function/invokable/invocation parameter bindings, context entry values, and relation columns.
    • if any expression has a typeRef, then the result value of the expression SHALL be subject to conversion against the expression typeRef. A single exception to this is UnaryTests expressions which do not use typeRef. Refer 7.3.2 UnaryTests Metamodel.
    • invokable elements such as a FunctionDefinition or BusinessKnowledgeModel or DecisionService that have a typeRef (which must be a function type), and that typeRef function type has an "outputTypeRef", then additionally, the result value of invocation SHALL be subject to conversion against that outputTypeRef.

    Basically, - if is has an associated typeRef - then it SHALL be subject to type conversion including singleton lists, conforms to, date vs datetime.

  • Reported: DMN 1.5 — Mon, 19 Aug 2024 01:57 GMT
  • Updated: Wed, 4 Sep 2024 14:05 GMT

Chapter 11 example models contain a lot of vendor specific "noise".

  • Key: DMN17-70
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The XML examples for chapter 11 contains a lot of vendor-specific noise. An example below shows a simple element with two vendor-specific additions:

    ```
    <semantic:import namespace="http://www.trisotech.com/definitions/_5e8e877a-af87-434b-9c36-ed51c8d6b514"
    name="Financial"
    triso:fileId="eyJmIjp7InNrdSI6IjU1ZTFkZDA5LTdjYTUtNGUyMC04NzI1LWVlOTI5NzI2OTZkYiIsIm5hbWUiOiJGaW5hbmNpYWwifSwiciI6eyJhcGlrZXkiOiIyOTIwMDNmNjk4NDBlNzEyIn19"
    triso:fileName="Chapter 11 Example/Financial"
    importType="https://www.omg.org/spec/DMN/20211108/MODEL/"
    drools:modelName="Financial"/>
    ```

    The noise is distracting, makes the models overly verbose, and (IMO), the spec should not contain vendor specifics. The above need only be:

    ```
    <semantic:import namespace="http://www.trisotech.com/definitions/_5e8e877a-af87-434b-9c36-ed51c8d6b514"
    importType="https://www.omg.org/spec/DMN/20211108/MODEL/"
    name="Financial" />
    ```

    Please consider removing all vendor-specific noise from the examples.

  • Reported: DMN 1.5 — Sun, 18 Aug 2024 23:03 GMT
  • Updated: Wed, 4 Sep 2024 14:05 GMT

Spec compliance issues with Chapter 11 example models.

  • Key: DMN17-69
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    Some aspects of the DMN 1.5 chapter 11 examples are not spec compliant. This applies to both examples.

    • 8.3.2 Decision Table Input and Output metamodel. "A RuleAnnotationClause SHALL have a name." The models have a number of decision table rule annotations that do not have names and are simply `<semantic:annotation/>`. Names are required. I suggest removing the annotations on all models.
    • typeRef on EncapsulatedLogic and invokables may only be a function type. The chapter 11 models have primitives as typeRefs (as well as "Any" in financial.dmn) on a number of BKM encapsulated logic expressions and variables.

    In section: "6.3.9 Business Knowledge Model metamodel", "Table 15: Invocable attributes and model associations". Re the "variable":

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

    It is bound to the function, not the function return type. There are assertions in the TCK for same. I suggest removing all the explicit typeRefs from all the BKMs and their associated variables in all models.

    • 6.3.10 Decision service metamodel. "A DecisionService element has one or more associated outputDecisions". Some models have decision services with no outputDecisions such as below. I suggest removing these from the models.

    ```
    <semantic:decisionService id="_5c111794-4c6b-4747-8dfc-99d2ad0b6313_DS" name="Diagram Bureau Strategy Decision Service" triso:dynamicDecisionService="true">
    <semantic:variable name="Diagram Bureau Strategy Decision Service" id="_e69084e3-2a45-49f1-9bd0-7da468de75f8" typeRef="Any"/>
    </semantic:decisionService>
    <semantic:decisionService id="_69750f88-f46f-4b47-bb3c-fb77f574f2b3_DS" name="Diagram Routing Decision Service" triso:dynamicDecisionService="true">
    <semantic:variable name="Diagram Routing Decision Service" id="_5bb6af75-1df6-4f84-a2c7-1e106a313c94" typeRef="Any"/>
    </semantic:decisionService>
    <semantic:decisionService id="_95e871bf-e58f-4976-b1bf-d9b220fdb2cb_DS" name="Diagram DRD for Credit Risk Analytics" triso:dynamicDecisionService="true">
    <semantic:variable name="Diagram DRD for Credit Risk Analytics" id="_b6a75564-fdf6-44ec-a1cf-2141befbc189" typeRef="Any"/>
    </semantic:decisionService>

    ```

  • Reported: DMN 1.5 — Sun, 18 Aug 2024 22:41 GMT
  • Updated: Wed, 4 Sep 2024 14:05 GMT

DMN 1.5 changebar PDF does not show changes from 1.4

  • Key: DMN17-68
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The published 1.5 changebar PDF at https://www.omg.org/spec/DMN/1.5/PDF/changebar seems to only list changes from (perhaps) the 1.5 beta, but not from 1.4.

    For example, section "10.3.1.2 Grammar rules" shows no changes despite 1.5 makes changes for E numbers, unary tests and range literals.

    This document is crucial for understanding the changes made to the released specification. At this time it is not possible to fully understand 1.5 changes without a line by line comparison with the 1.4 spec.

  • Reported: DMN 1.5 — Sun, 18 Aug 2024 22:10 GMT
  • Updated: Wed, 4 Sep 2024 14:04 GMT

date() conversion function should return null for invalid dates

  • Key: DMN17-67
  • Status: open   Implementation work Blocked
  • Source: Camunda Services GmbH ( Mr. Philipp Ossler)
  • Summary:

    The description of the date() conversion function doesn't specify the expected result if the function is invoked with an invalid date.

    Examples:

    date("2023-02-29") 
    // expected: null (2023 is not a leap year)
    
    date("2023-06-31")
    // expected: null (June has only 30 days)
    

    I expect that the function should return null because an invalid date is outside of the parameter domain of a "valid date".

    From a user perspective, it would also be useful to return null to identify/detect invalid dates.

    Goal: clarify the expected behavior and adjust the description in the specification.

  • Reported: DMN 1.5b1 — Wed, 26 Jun 2024 06:56 GMT
  • Updated: Mon, 1 Jul 2024 15:21 GMT

Wrong placement of useAlternativeInputDataShape attribute in the DMN specification document

  • Key: DMN17-66
  • Status: open  
  • Source: International Business Machines ( Mr. Tibor Zimanyi)
  • Summary:

    There is a bug in the specification document (1) around the attribute useAlternativeInputDataShape. Looking into the approved proposal, that added the attribute here (2), it is approved to be added to DMNDiagram. In the XSD it is correctly in the DMNDiagram. However, when you check the document, it is part of the DMNShape definition (see 13.4.5 DMNShape [Class]).

    (1) https://www.omg.org/spec/DMN/1.5/Beta1/PDF
    (2) https://issues.omg.org/browse/DMN15-117

  • Reported: DMN 1.5b1 — Mon, 20 May 2024 11:24 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Frequently changing Namespace URIs cause market fragmentation

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

    Currently, the version of DMN used in an DMN XML file is identified by the XML namespace URI, which is therefore changed with every revision. However, frequently changing namespace URIs cause market fragmentation across supported specification versions, as it cannot be assumed that all vendors update to the latest version of the spec at the same time, if at all.

    This forces users to do unnecessary version migrations, or their models would be rejected by a tool as invalid or outdated even though language features used in the model may be perfectly supported by the tool. This issue has also been recognized by Specification Common Elements (SCE) in SCE-117.

    With DMN shipping bugfixes on a yearly pace, the fragmentation of the tool market increases, while the actual number of changes to the XML schema decreases. In fact, DMN 1.6 has zero changes to the XML schema at all but if it would follow the "tradition", it would again declare itself totally incompatible with DMN 1.5 and all prior versions.

    DMN 1.x revisions have been following the backwards compatibility guidelines for machine-readable files and XML schemas as defined in the OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces (smsc/2018-08-01). Therefore, DMN 1.x revisions should not change the namespace URL until a version 2.0 introduces breaking changes, which is not planned at the moment.

    The "tradition" to always change the namespace has somewhat accidentally grown:

  • Reported: DMN 1.5b1 — Mon, 22 Apr 2024 19:36 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

ambiguity for collections

  • Key: DMN17-64
  • Status: open  
  • Source: University of Koblent, SAP Signavio ( Carl Corea)
  • Summary:

    I do not understand the following aspect about collections: Assume the input data node is a collection, but the decision is NOT a collection. From my understanding, the individual values of the input collection are passed iteratively to the decision. As the latter is NOT a collection in the example, it is my understanding there should be some form of aggregation(?).

    I can understand how this should work for numerical values (e.g. "aggregate" by sum) however I am not clear of the aggregation method (is it always sum?). Furthermore, how should aggregation work if the output column of the decision contains strings?

    Example: Two rules: "a"->"b", "c"->"d". Then an input collection {"a","c"} is passed. So the two outputs are "b", "d". As the decision is NOT a collection, we should not yield something like {"b","d"}, but should aggregate(?), yet, as stated, how to aggregate b,d?

  • Reported: DMN 1.4b1 — Wed, 10 Apr 2024 07:57 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

XML serialization is not human friendly

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

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

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

  • Reported: DMN 1.5b1 — Tue, 5 Dec 2023 11:28 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

No binding to Python functions

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

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

  • Reported: DMN 1.5 — Fri, 3 Nov 2023 22:25 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-57
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: DMN 1.4 — Thu, 15 Jun 2023 19:56 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-56
  • Status: open  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

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

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

  • Reported: DMN 1.5 — Wed, 5 Jul 2023 16:05 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT
  • Attachments:

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

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

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

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

    The issue was discovered in TCK when testing function invocations.

  • Reported: DMN 1.5b1 — Tue, 4 Jul 2023 07:57 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Clarification on the FEEL sort function with the precedes function

  • Key: DMN17-63
  • Status: open  
  • Source: Trisotech ( Mr. Simon Ringuette)
  • Summary:

    In section 10.3.4.9 of the DMN 1.5 specification (page 153, PDF 161) the sort function is defined with the possibility to use a precedes boolean function to compare list elements.

    Text should be added after table 80 to clarify how the precedes function deal with equal parameters.

    I would propose that precedes return false when both parameters are equals.

    This new paragraph should also establish the stability expectation of the sort FEEL function (equal elements keep the order of the original list).

    I would propose that the FEEL sort function does not guarantee stability. Guaranteeing stability could impact certain sort performances.

  • Reported: DMN 1.5b1 — Thu, 21 Mar 2024 19:28 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Knowledge Sources are not fit for ML or AI purposes

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

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

  • Reported: DMN 1.5 — Fri, 23 Feb 2024 22:50 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Duplicated names and labels

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

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

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

    Possible solution:

    • deprecate the attributes (e.g. DMNElement.label)
    • add a constraint (e.g. DRGElement.name == DRGElement.variable.name)
  • Reported: DMN 1.5b1 — Mon, 27 Nov 2023 10:49 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Allow for partial temporal values

  • Key: DMN17-48
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

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

  • Reported: DMN 1.3 — Tue, 26 Jan 2021 22:17 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Allow input data to be of type Interval

  • Key: DMN17-50
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: DMN 1.3 — Mon, 25 Jan 2021 20:17 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Adding a new interval built-in function

  • Key: DMN17-49
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: DMN 1.3 — Tue, 26 Jan 2021 22:03 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Links with other standards

  • Key: DMN17-51
  • Status: open  
  • Source: FICO ( Dr. Alan Fish)
  • Summary:

    A "bucket" for collecting related issues around external links

  • Reported: DMN 1.3 — Tue, 3 Nov 2020 18:17 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Importing libraries of functions is not business friendly

  • Key: DMN17-54
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

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

  • Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:27 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Interchanging models that use external libraries of functions is complicated

  • Key: DMN17-55
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

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

  • Reported: DMN 1.4b1 — Tue, 18 Oct 2022 19:35 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Missing InformationItem Association?

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

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

  • Reported: DMN 1.3 — Fri, 10 Jul 2020 21:28 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Functions cannot invoke external services

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

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

  • Reported: DMN 1.4 — Wed, 16 Mar 2022 19:34 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

DRG requirements only state am unused knowledge requirement is illegal

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

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

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

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

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

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

  • Reported: DMN 1.3 — Thu, 25 Mar 2021 08:10 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-40
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

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

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

  • Reported: DMN 1.3 — Thu, 25 Mar 2021 08:35 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Spec does not mandate that all formal parameters are utilised.

  • Key: DMN17-41
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

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

  • Reported: DMN 1.3 — Thu, 25 Mar 2021 08:25 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-44
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

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

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

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

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

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 09:31 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

the operation of is() function is not well specified

  • Key: DMN17-45
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

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

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

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 10:20 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-47
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

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

  • Reported: DMN 1.3 — Tue, 2 Feb 2021 22:55 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

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

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

  • Reported: DMN 1.3 — Wed, 24 Feb 2021 05:36 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT
  • Attachments:

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

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

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

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

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

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

  • Reported: DMN 1.3 — Tue, 2 Feb 2021 23:38 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Clarification on DMN case sensitivity of timezones

  • Key: DMN17-34
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

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

  • Reported: DMN 1.2 — Sat, 16 Mar 2019 01:12 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-36
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Since DMNv1.2 the spec dropped the equivalence of:

    [a] = a
    

    because it does not apply to the statement that

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

    So the expression

    [a] = a
    

    on DMNv1.2 is expected to return false.

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

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

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

    BUT

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

    according to DMNv1.2 should be false

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

    [123] = 123
    

    on DMNv1.2 is expected to be false

  • Reported: DMN 1.2b1 — Wed, 30 Jan 2019 14:43 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

properly define type(e)

  • Key: DMN17-35
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

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

  • Reported: DMN 1.2 — Tue, 27 Nov 2018 22:31 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-37
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

  • Reported: DMN 1.2b1 — Thu, 15 Nov 2018 08:15 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

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

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

  • Reported: DMN 1.3 — Wed, 1 Jan 2020 00:23 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Add an itemKind property to ItemDefinition

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

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

  • Reported: DMN 1.3b1 — Tue, 6 Apr 2021 22:11 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Shared Data Model and Notation (SDMN)

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

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

  • Reported: DMN 1.2b1 — Tue, 10 Sep 2019 18:04 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT
  • Attachments:

Temporal precision inconsistencies

  • Key: DMN17-29
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: DMN 1.2b1 — Tue, 16 Jul 2019 14:02 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-30
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

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

  • Reported: DMN 1.2b1 — Tue, 28 May 2019 16:40 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Support for recursive calls by Business Knowledge Models

  • Key: DMN17-33
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

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

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

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

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

    The following paragraph is added:

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

  • Reported: DMN 1.2 — Sat, 6 Apr 2019 02:38 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Friendlier handling of null values

  • Key: DMN17-31
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

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

  • Reported: DMN 1.2b1 — Tue, 21 May 2019 16:53 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-32
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    split off from DMN13-12

  • Reported: DMN 1.2 — Tue, 20 Nov 2018 17:55 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

need set operations and equality in FEEL

  • Key: DMN17-22
  • Status: open  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

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

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

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

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

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

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

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

  • Reported: DMN 1.1 — Thu, 11 Aug 2016 15:35 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Metamodel constraints & validation

  • Key: DMN17-20
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

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

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

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

  • Reported: DMN 1.1 — Sun, 30 Oct 2016 11:45 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-21
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: DMN 1.1 — Wed, 24 Aug 2016 16:45 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Requested additional built-in functions

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

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

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

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

  • Reported: DMN 1.1 — Mon, 2 Jan 2017 20:43 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-23
  • Status: open  
  • Source: Signavio GmbH ( Dr. Bastian Steinert)
  • Summary:

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

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

  • Reported: DMN 1.1 — Sun, 26 Jun 2016 10:11 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

DMN Models need a default timezone

  • Key: DMN17-26
  • Status: open  
  • Source: fujitsu america ( keith swenson)
  • Summary:

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

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

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

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

  • Reported: DMN 1.2 — Wed, 18 Sep 2019 09:55 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Unspecified conclusion is not supported

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

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

  • Reported: DMN 1.1 — Mon, 13 Jun 2016 21:41 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

inconsistent date comparisons make unavoidavle paradoxes

  • Key: DMN17-27
  • Status: open  
  • Source: fujitsu america ( keith swenson)
  • Summary:

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

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

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

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

  • Reported: DMN 1.2 — Wed, 18 Sep 2019 10:01 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Fix interchange of links to objects in BPMN/BMM

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

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

  • Reported: DMN 1.2 — Thu, 27 Sep 2018 01:07 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-10
  • Status: open  
  • Source: Red Hat ( Edson Tirelli)
  • Summary:

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

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

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

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

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

  • Reported: DMN 1.1 — Thu, 8 Mar 2018 16:20 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-15
  • Status: open  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

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

    Examples:

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

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

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

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

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

  • Reported: DMN 1.1 — Wed, 3 May 2017 15:24 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Should name declarations in same context fail or overwrite?

  • Key: DMN17-16
  • Status: open  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

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

  • Reported: DMN 1.1 — Wed, 3 May 2017 09:25 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Semantic domain mapping for simple expressions

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

    The FEEL grammar contains simple expressions as starting terminal

    page 107 6. simple expressions = simple expression ,

    { "," , simple expression }

    ;

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

  • Reported: DMN 1.1 — Fri, 17 Mar 2017 14:42 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-17
  • Status: open  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

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

  • Reported: DMN 1.1 — Wed, 3 May 2017 09:11 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Add two new concrete numeric types, make number abstract

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

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

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

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

    Here is my proposal:

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

    If we agree in principal all start working on it.

  • Reported: DMN 1.1 — Wed, 6 Dec 2017 13:44 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-14
  • Status: open  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

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

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

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

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

    Examples:

    • [1,2,3][min(3,2,1)]
    • {a:function() external {java: {class: "clazz", method signature: "method()"}}, b:[1,2,3][a()]}.b
    • {a: 1, b: a instance of number, c: [1,2,3][b] }
  • Reported: DMN 1.1 — Wed, 3 May 2017 14:56 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

FEEL grammar readability

  • Key: DMN17-12
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

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

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

  • Reported: DMN 1.1 — Sun, 30 Oct 2016 11:37 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-13
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

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

  • Reported: DMN 1.1 — Mon, 15 May 2017 17:59 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-4
  • Status: open  
  • Source: Red Hat Inc ( Edson Tirelli)
  • Summary:

    This is a suggestion for future versions of the spec:

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

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

    function ( x ) x in <unary_test>

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

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

    Invoking unary tests explicitly would be like invoking a function:

    Bob is minor : is minor( bob.age )

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

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

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

  • Reported: DMN 1.1 — Tue, 23 Aug 2016 01:41 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Should encapsulated decisions of a decision service include output decisions?

  • Key: DMN17-6
  • Status: open  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

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

    {Decision 1, Decision 2}

    "

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

    {Decision 1}

    ".

    Table 20 on page 56:

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

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

  • Reported: DMN 1.0 — Tue, 20 Mar 2018 14:49 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Figure 6.15 shows incorrect multiplicity for Decision Service Output Decisions

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

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

  • Reported: DMN 1.1 — Fri, 3 Aug 2018 21:19 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Include Test Cases in Decision Model

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

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

  • Reported: DMN 1.1 — Sat, 28 May 2016 16:25 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT
  • Attachments:

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

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

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

  • Reported: DMN 1.0 — Thu, 3 Sep 2015 15:58 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

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

  • Key: DMN17-7
  • Status: open  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

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

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

    If you apply this expression to the following two values:

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

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

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

    Addition
    which results for addition into:

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

    which is:

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

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

    Subtraction
    which results for subtraction into:

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

    which is:

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

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

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

  • Reported: DMN 1.1 — Mon, 2 Oct 2017 12:41 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Improve description of built-in function string()

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

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

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

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

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

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

  • Key: DMN17-8
  • Status: open  
  • Source: ACTICO ( Daniel Thanner)
  • Summary:

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

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

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

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

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

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

    Clarification in the specification is appreciated.

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

  • Reported: DMN 1.1 — Tue, 10 Oct 2017 14:32 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT

Business Context links go both ways

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

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

  • Reported: DMN 1.0 — Tue, 14 Apr 2015 17:30 GMT
  • Updated: Fri, 21 Jun 2024 17:56 GMT