Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN16-67 Functions cannot invoke external services DMN 1.4 open
DMN16-69 Importing libraries of functions is not business friendly DMN 1.4b1 open
DMN15-139 Import into default namespace is undefined DMN 1.4b1 open
DMN16-73 Incorrect names for parameters DMN 1.4b1 open
DMN16-72 FEEL descendants operator DMN 1.4b1 open
DMN15-124 Interchanging models that use external libraries of functions is complicated DMN 1.4b1 open
DMN15-151 Friendly enough cohersion to string DMN 1.4b1 open
DMN16-71 Friendly enough cohersion to string DMN 1.4b1 open
DMN16-70 Interchanging models that use external libraries of functions is complicated DMN 1.4b1 open
DMN15-123 Importing libraries of functions is not business friendly DMN 1.4b1 open
DMN15-101 No Mapping of FEEL to JSON DMN 1.4 open
DMN16-68 No Mapping of FEEL to JSON DMN 1.4 open
DMN15-91 Functions cannot invoke external services DMN 1.4 open
DMN15-96 Gaps: Range as input, mapping to JSON, evaluation of non-FEEL expression languages DMN 1.4 open
DMN15-83 Typo in 6.3.7 Decision metamodel DMN 1.4 open
DMN15-81 Typo in 8.3.1 Decision Table metamodel "DecsionTable" DMN 1.4 open
DMN15-106 Incorrect reference to FEEL rule DMN 1.4b1 open
DMN15-79 Typo in the DMN 1.4 XSD schema (complexType tFilter) DMN 1.4 open
DMN15-109 There are questions regarding precedence of operator between negation and exponation DMN 1.4 open
DMN15-108 Positive unary tests lack equality operators DMN 1.4b1 open
DMN15-137 Allowed Values for collection item definitions DMN 1.4b1 open
DMN15-131 Another False, or at least ignored statement by most vendors DMN 1.4b1 open
DMN15-130 False, or at least ignored statement by most if not all vendors DMN 1.4b1 open
DMN15-88 UNused Requirements are considered invalid DMN 1.4 open
DMN15-99 No built-in function to support Range conversion DMN 1.4 open
DMN15-86 Table 62 limited to "negative numbers" DMN 1.4 open
DMN15-94 Typo in "10.3.1.2 Grammar rules" 3rd bulletpoint in the bottom DMN 1.4 open
DMN15-107 No support for numbers in scientific notation DMN 1.4b1 open
DMN15-135 Precision on Allowed Values UnaryTests DMN 1.4b1 open
DMN15-143 Missing FEEL function to replace items in a list DMN 1.4b1 open
DMN15-125 Lists and filters section does not provide a dot accessor "." example with null DMN 1.4b1 open
DMN15-121 It is not possible to use a range of Dates as an iteration context DMN 1.4b1 open
DMN15-120 Wording in section above does not match the rule 35 in grammar DMN 1.4b1 open
DMN15-98 DMN 1.4 updated XMI references external file DMN14.mdxml DMN 1.4 open
DMN15-142 Misprint in DMN 1.4b1 open
DMN15-149 Typo - "duraion" DMN 1.4 open
DMN15-104 Acknowledgements for DMN 1.4 and 1.5 contributors needed DMN 1.4b1 open
DMN15-159 New Namespace URIs needed DMN 1.4b1 open
DMN15-155 Superfluous spaces after "1" DMN 1.4 open
DMN15-157 Copyright section needs update DMN 1.4b1 open
DMN15-153 Multiple empty imports using the order as a precedence is not allowed DMN 1.4b1 open
DMN15-119 Incorrect function name in example DMN 1.4b1 open
DMN15-118 Typo in Table 66 DMN 1.4b1 open

Issues Descriptions

Functions cannot invoke external services

  • Key: DMN16-67
  • 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, 14 Apr 2023 16:54 GMT

Importing libraries of functions is not business friendly

  • Key: DMN16-69
  • Status: open  
  • Source: Trisotech ( 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: Wed, 12 Apr 2023 13:06 GMT

Import into default namespace is undefined

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

    The current mechanism for importing in DMN requires a name attribute to be a prefix to imported elements names.
    Importing an item definition named Person becomes import. Person when referencing it from the local model.
    This is confusing to some business users.

    We would like to allow the import into the default namespace by specifying an empty name.
    This, of course, has the potential of creating name collisions for the imported elements.
    We suggest that when a name collision occurs for one of the imported elements, the local element is kept and the imported one is discarded.

  • Reported: DMN 1.4b1 — Fri, 2 Dec 2022 14:35 GMT
  • Updated: Wed, 12 Apr 2023 08:31 GMT

Incorrect names for parameters

  • Key: DMN16-73
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    The names of the number() function in note 1 at the end of Table 72

  • Reported: DMN 1.4b1 — Tue, 31 Jan 2023 18:50 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

FEEL descendants operator

  • Key: DMN16-72
  • Status: open  
  • Source: Bruce Silver Associates ( Bruce Silver)
  • Summary:

    In some decision models, the input data must conform to an industry-standard xml schema in which elements of interest are many levels deep. Converting such a schema directly to a FEEL item definition requires very long path references. The xpath language has a descendants operator that significantly shortens the path expression. I propose a similar operator (or, less ideally, a function) for FEEL.

    An example is MISMO from the Mortgage Bankers Association. In home appraisals, one item of interest is the Appraiser. To reference the Appraiser from the FEEL item definition generated from the xsd requires this:
    MESSAGE.DOCUMENT_SETS.DOCUMENT_SET.DOCUMENTS.DOCUMENT.DEAL_SETS.DEAL_SET.DEALS.DEAL.SERVICES.SERVICE.VALUATION.VALUATION_RESPONSE.VALUATION_ANALYSES.VALUATION_ANALYSIS.PARTIES.PARTY[ROLES.ROLE.ROLE_DETAIL.PartyRoleType="Appraiser"][1]

    In xpath, omitting namespace prefixes, the descendants operator // simplifies this considerably:
    MESSAGE//PARTY[.//PartyRoleType='Appraiser']

    If // were used as a FEEL descendants operator, you would need only
    MESSAGE//PARTY//PartyRoleType="Appraiser"[1]

    To get the Appraiser's name, instead of
    MESSAGE.DOCUMENT_SETS.DOCUMENT_SET.DOCUMENTS.DOCUMENT.DEAL_SETS.DEAL_SET.DEALS.DEAL.SERVICES.SERVICE.VALUATION.VALUATION_RESPONSE.VALUATION_ANALYSES.VALUATION_ANALYSIS.PARTIES.PARTY[ROLES.ROLE.ROLE_DETAIL.PartyRoleType="Appraiser"].INDIVIDUAL.NAME[1]

    you would need only

    MESSAGE//PARTY//PartyRoleType="Appraiser"//NAME[1]

  • Reported: DMN 1.4b1 — Tue, 14 Mar 2023 19:38 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Interchanging models that use external libraries of functions is complicated

  • Key: DMN15-124
  • Status: open  
  • Source: Trisotech ( 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: Thu, 6 Apr 2023 14:59 GMT

Friendly enough cohersion to string

  • Key: DMN15-151
  • Status: open  
  • Source: camunda.com ( Nico Rehwaldt)
  • Summary:

    Currently concatenating strings is not intuitive to users, as I always have to convert non string values to strings using the built-in `string` function.

    So

    ```
    "Today is " + now() = null
    ```

    In order to yield the actual string you explicitly convert `now()` to its string representation:

    ```
    "Today is " + string(now()) = "Today is 2021-12-12"
    ```

    A more user friendly behavior would be to coherse the second argument to string if the first argument is already a string. This always yields a string representation of the thing. If it is not what I desire I can use custom stringification mechanisms explicitly.

    We'd need to amend the Table 57 (page 128, https://www.omg.org/spec/DMN/1.4/Beta1/PDF) to support such cohersion.

    Additional details on this case can be found in https://github.com/dmn-tck/tck/issues/538 (DMN TCK issue on this topic).

  • Reported: DMN 1.4b1 — Thu, 19 Jan 2023 12:50 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Friendly enough cohersion to string

  • Key: DMN16-71
  • Status: open  
  • Source: camunda.com ( Nico Rehwaldt)
  • Summary:

    Currently concatenating strings is not intuitive to users, as I always have to convert non string values to strings using the built-in `string` function.

    So

    ```
    "Today is " + now() = null
    ```

    In order to yield the actual string you explicitly convert `now()` to its string representation:

    ```
    "Today is " + string(now()) = "Today is 2021-12-12"
    ```

    A more user friendly behavior would be to coherse the second argument to string if the first argument is already a string. This always yields a string representation of the thing. If it is not what I desire I can use custom stringification mechanisms explicitly.

    We'd need to amend the Table 57 (page 128, https://www.omg.org/spec/DMN/1.4/Beta1/PDF) to support such cohersion.

    Additional details on this case can be found in https://github.com/dmn-tck/tck/issues/538 (DMN TCK issue on this topic).

  • Reported: DMN 1.4b1 — Thu, 19 Jan 2023 12:50 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Interchanging models that use external libraries of functions is complicated

  • Key: DMN16-70
  • Status: open  
  • Source: Trisotech ( 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: Thu, 6 Apr 2023 14:59 GMT

Importing libraries of functions is not business friendly

  • Key: DMN15-123
  • Status: open  
  • Source: Trisotech ( 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: Thu, 6 Apr 2023 14:59 GMT

No Mapping of FEEL to JSON

  • Key: DMN15-101
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Current DMN Specification v1.4 does not define a mapping of FEEL to JSON, while it already provides mapping for Java, XML, PMML in chapter "10.3.2.12 Mapping between FEEL and other domains"

    This capability can be useful in other use-cases beyond mapping itself. For example, but not limiting to: the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services.

  • Reported: DMN 1.4 — Wed, 13 Apr 2022 13:22 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT
  • Attachments:

No Mapping of FEEL to JSON

  • Key: DMN16-68
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Current DMN Specification v1.4 does not define a mapping of FEEL to JSON, while it already provides mapping for Java, XML, PMML in chapter "10.3.2.12 Mapping between FEEL and other domains"

    This capability can be useful in other use-cases beyond mapping itself. For example, but not limiting to: the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services.

  • Reported: DMN 1.4 — Wed, 13 Apr 2022 13:22 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT
  • Attachments:

Functions cannot invoke external services

  • Key: DMN15-91
  • 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: Thu, 6 Apr 2023 14:59 GMT

Gaps: Range as input, mapping to JSON, evaluation of non-FEEL expression languages

  • Key: DMN15-96
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Current DMN Specification v1.4 has a few gaps in the following areas:

    1. Built-in function to support Range conversion
    2. Mapping of FEEL to JSON
    3. Evaluation of other expression language beyond FEEL

    In addition to the above gaps, during conversations in the OMG DMN RTF group, and in other communities with DMN interests, SMEs and Vendors have reported on the missing capabilities for a complete, semantically well-defined and interoperable solution, connected to the mentioned cases. For example, but not limiting to: the need to have FEEL:range as an input of the model, the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services, etc.

    The pragmatic aspects introduced in this proposal to cover the mentioned gaps above, could also be a meaningful foundational and propaedeutic work if the OMG DMN RTF group will want to pursue to eventually propose the DMN Specification to ISO, and/or the group will want to pursue to eventually refactor FEEL into its own stand-alone Specification.

    Finally, the DMN Specification already provides recommendations in the Annex(es) for integrations, in the scope of BPMN, etc., for harmonised semantic and potential improved interoperability; the DMN Spec could also offer similar recommendations in the scope of gap 3 identified above.

    This document advances pragmatic proposals that would both cover the existing gaps and provide the capabilities required to a well-defined and more interoperable solution.

  • Reported: DMN 1.4 — Fri, 25 Mar 2022 08:29 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Typo in 6.3.7 Decision metamodel

  • Key: DMN15-83
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    In the chapter "6.3.7 Decision metamodel",
    a reference is made to the fact a Decision's Name MUST be unique in the model, but there is likely a wrong copy-paste of a sentence from other section of the spec.

    It currently reads as:

    The name of an Invocable must be different from the name of any other invocable, input data, decision, or import in the decision model.

    But a Decision is NOT an Invocable.

    In the chapter "6.3.9 Business Knowledge Model metamodel" the same pharse is used and there is valid since a BKM is indeed an Invocable.

    In the chapter "6.3.11 Input Data metamodel" the analogous phrase is correctly adapted, since it reads as:

    The name of an InputData must be different from the name of any other decision, input data, business knowledge model, decision service, or import in the decision model.

    Conclusion

    Only in chapter chapter "6.3.7 Decision metamodel" the phrase is wrong as referring to "Invocable" when in fact it should have just used the term "Decision". The proposal will address this accordingly.

  • Reported: DMN 1.4 — Wed, 19 Jan 2022 12:58 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Typo in 8.3.1 Decision Table metamodel "DecsionTable"

  • Key: DMN15-81
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    In the paragraph of 8.3.1 Decision Table metamodel

    DecisionTable inherits all the attributes and model associations from Expression. Table 32 presents the additional attributes and model associations of the DecsionTable element.

  • Reported: DMN 1.4 — Wed, 5 Jan 2022 08:48 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Incorrect reference to FEEL rule

  • Key: DMN15-106
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    In the following bullet point:

    In rule 62, the only permitted functions are the builtins date, time, date and time, and duration.

    the correct reference is rule 60 where the date time literals are defined.

  • Reported: DMN 1.4b1 — Tue, 31 May 2022 07:56 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Typo in the DMN 1.4 XSD schema (complexType tFilter)

  • Key: DMN15-79
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Typo of spurious trailing whitespace in the name of the complexType "tFilter " (notice the extra space at the end) make XSD validators to fail to validate the XML Schema itself.

  • Reported: DMN 1.4 — Mon, 3 Jan 2022 16:30 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

There are questions regarding precedence of operator between negation and exponation

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

    in FEEL -4**2 = 16
    Some may expect = -16

  • Reported: DMN 1.4 — Tue, 5 Jul 2022 17:03 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Positive unary tests lack equality operators

  • Key: DMN15-108
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    Currently the positive unary tests support all relational operators but not the equality operators (= !=). We should support them for consistency. For example, all the above operators are supported in comparison expressions (rule 49).

    Business analysts have reported that they would like to have a consistent and more readable way to write rules and test cases with many comparison operators.

  • Reported: DMN 1.4b1 — Tue, 31 May 2022 08:40 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Allowed Values for collection item definitions

  • Key: DMN15-137
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    DMN ItemDefinitions metamodel (section 7.3.3) specifies that the allowedValues of a collection attribute are projected to its elements which prevents us from constraining collections.

    For example:

    • The collection size needs to be between 1-5 elements
    • The collection can’t contain duplicates

    Our proposal is to add an additional attribute to ItemDefinition named collectionAllowedValues to capture these constraints.

  • Reported: DMN 1.4b1 — Fri, 2 Dec 2022 14:23 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Another False, or at least ignored statement by most vendors

  • Key: DMN15-131
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    This statement was brought to my attention via DMN TCK email:

    "If a decision element requires more than one business knowledge element, its value expression must be a literal expression that specifies how the business knowledge model elements are invoked and how their results are combined into the decision's outcome. "

    This statement is either false or ignored by most vendors

  • Reported: DMN 1.4b1 — Wed, 30 Nov 2022 17:58 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

False, or at least ignored statement by most if not all vendors

  • Key: DMN15-130
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    This statement was brought to my attention via DMN TCK email:

    "If a decision does not require any business knowledge models, its value expression must be a literal expression or decision table that specifies the entire decision logic for deriving the output from the inputs."

    This statement is either false or ignored by most vendors

  • Reported: DMN 1.4b1 — Wed, 30 Nov 2022 17:55 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

UNused Requirements are considered invalid

  • Key: DMN15-88
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Executive summary: by the way the DMN specification stands, the description that Requirements SHALL (== "MUST") be referenced in the expression will nullify any CL1 DMN model and any DMN model not using FEEL, as not-conformant.

    In section 7.3.4 InformationItem metamodel we read:

    A variable representing an instance of Decision or InputData referenced by an InformationRequirement SHALL be referenced by the value expression of the decision logic in the Decision element that contains the InformationRequirement element. A parameter in an instance of BusinessKnowledgeModel SHALL be a variable in the value expression of that BusinessKnowledgeModel element.

    By side effect of this strict mandate in the specification, it is like saying an UNused requirement will fail conformance.

    Example: a decision enlist A, B, C as Requirements, but in the formula we use only A and B. According to the current spec, this makes the model failing conformance and invalid.

    Granted, it is always a best practice not only for BA but also for developers to avoid "unused requirements/variable"!
    But here is giving a strict mandate.

    Further, any DMN model which does not use FEEL "only DRG" automatically fail this constraint which is in Chapter 7.

    The DMN specification should follow best-practices of Modeling AND programming languages, where is NOT a blocking issue to have "unused requirements/variables", but of course warn when those are detected; this can be easily achieved by switching SHALL to SHOULD in the identified paragraphs in chapter 7.1 and 7.3.4 per proposal.

    This issue was detected in the TCK group (ref https://github.com/dmn-tck/tck/issues/487 )

  • Reported: DMN 1.4 — Sun, 27 Feb 2022 20:45 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

No built-in function to support Range conversion

  • Key: DMN15-99
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Current DMN Specification v1.4 does not define a Built-in function to support Range conversion.

    This capability can be useful in other use-cases beyond conversion itself. For example, but not limiting to: the need to have FEEL:range as an input of the model, the need for external REST-based invocation of externally defined (stateless, side-effect-free) decision services, etc.

  • Reported: DMN 1.4 — Wed, 13 Apr 2022 13:07 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT
  • Attachments:

Table 62 limited to "negative numbers"

  • Key: DMN15-86
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    In 10.3.2.15 Semantic mappings,
    Table 62: Semantics of negative numbers

    per its description is limiting to negative numbers, but by Table 59 it's possible to multiply a duration (years and months duration, days and time duration) by a number.

    Hence, it's already possible to do

    duration("PT1H")*-1
    

    but formally is not allowed to do

    -duration("PT1H")
    

    It should be easier to widen the semantic of Table 62 to negate numbers AND duration to allow the second case.

    This was identified in the TCK group, ref https://github.com/dmn-tck/tck/issues/482

  • Reported: DMN 1.4 — Sun, 27 Feb 2022 20:23 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Typo in "10.3.1.2 Grammar rules" 3rd bulletpoint in the bottom

  • Key: DMN15-94
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    With reference to DMNv1.4 dtc-21-12-01,
    section "10.3.1.2 Grammar rules",
    page 104 (PDF 120)
    the 3rd bulletpoint in the bottom is referring to the wrong grammar rule number.

    This is likely a typo originating from the need of additional grammar rules being added in previous version of the Spec.

    This can be trivially fixed editorially, with the associated proposal.

  • Reported: DMN 1.4 — Thu, 17 Mar 2022 17:22 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

No support for numbers in scientific notation

  • Key: DMN15-107
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    Currently the syntax of numeric literals does not support usage of exponents. This is quite useful when dealing with large numbers.

  • Reported: DMN 1.4b1 — Tue, 31 May 2022 07:59 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Precision on Allowed Values UnaryTests

  • Key: DMN15-135
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    DMN ItemDefinitions metamodel (section 7.3.3) specifies that and ItemDefinition can restrict its typeRef by using an allowedValues attribute that is defined as a UnaryTests:

    An ItemDefinition element may restrict the values that are allowed from typeRef, using the allowedValues attribute. The allowedValues are an instance of unaryTests that specifies the allowed values or ranges of allowed values within the domain of the typeRef. The type of the allowed values SHALL be consistent with the containing ItemDefinition element. If an ItemDefinition element contains one or more allowedValues, the allowedValues specifies the complete range of values that this ItemDefinition represents. If an ItemDefinition element does not contain allowedValues, its range of allowed values is the full range of the referenced typeRef. In cases where the values that an ItemDefinition element represents are collections of values in the allowed range, the multiplicity can be projected into the attribute isCollection. The default value for this attribute is false.

    This paragraph has a few contradictions with the spec:

    • The last phrase is not clear about which attribute defaults to false, this whole paragraph talks about allowedValues and the intention must be that it refers to isCollection but that certainly confused us.
    • The attribute allowedValues is a UnaryTests but its usage is not consistent with its usage in decision tables inputEntry. A UnaryTests is defined as an expression that evaluates to a boolean with an implicit argument to be tested (from its definition in section 7.3.2). However, this is not the way it is used here. Here it defines a range/enumeration of allowedValues and not an expression that is evaluated with an implicit argument.
      Our proposal would be to align the usage of UnaryTests with decision table inputs.
      This would allow extended use cases such as:
    •  A validation of an email address domain: allowedValues => ends with(?, “@trisotech.com”) 
    •  Validation that depends on sibling variables values: allowedValues => if OrderType = “Type A” then [“a”,”b”,”c”] else [“c”, “d”, “e”] 
    •  Or something even simpler like not null: allowedValues => ? != null 
    •  Length check on strings: allowedValues => string length(?) > 10 
  • Reported: DMN 1.4b1 — Fri, 2 Dec 2022 14:13 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT
  • Attachments:

Missing FEEL function to replace items in a list

  • Key: DMN15-143
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    There are currently FEEL functions to manipulate lists content: append, sublist, concatenate, insert before, remove, union, distinct values and flatten but it does not define a function to replace item(s) from a list.

    Our proposal is to introduce a new list replace function.

  • Reported: DMN 1.4b1 — Tue, 17 Jan 2023 02:33 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Lists and filters section does not provide a dot accessor "." example with null

  • Key: DMN15-125
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    The current para (below) does not provide an example with null which could lead to misinterpretations.

    For convenience, a selection using the "." operator with a list of contexts on its left hand side returns a list of
    selections, i.e. FEEL(e.f, c) = [ FEEL(f, c'), FEEL(f, c"), ... ] where FEEL(e) = [ e', e", ... ] and c' is c augmented with
    the context entries of e', c" is c augmented with the context entries of e", etc. For example,

    [ {x:1, y:2}, {x:2, y:3} ].y = [2,3]
    
  • Reported: DMN 1.4b1 — Fri, 21 Oct 2022 14:43 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

It is not possible to use a range of Dates as an iteration context

  • Key: DMN15-121
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    FEEL for iteration statement context limits the iteration context (Section of 10.3.2.14 ) to integers:
    "An iteration context may either be an expression that returns a list of elements, or two expressions that return integers connected by “..”. "

    It would be useful to augment the iteration context to also allow dates.

    This will allow to create simple decision logic that validates conditions for each date in the range and allows one to write decision logic that can validate the state on each day to calculate the number of days that meet a requirement.

    An general example use case could be, how many days in the range [2021-01-01..2022-01-01] meets a certain complex logic.

    A specific example of that would be to determine if the person and its spouse were both employed and living at the same address for at least the 3 of the last 5 years given a list of Job description for both (Date From, Date To, Employer) and a list of their declared residence for both (Date From, Date To, Address).

    This can of course be calculated in a different way, but the logic of iterating on a date range and checking if the condition is true for every day and summing the number of days for which its true makes the logic a lot simpler to follow for a business user.

  • Reported: DMN 1.4b1 — Tue, 18 Oct 2022 18:39 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Wording in section above does not match the rule 35 in grammar

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

    After adding support for scientific notation (https://issues.omg.org/browse/DMN15-107), there are incorrect parts in section 10.3.2.3.1:

    1. Literals consist of base 10 digits and an optional decimal point.
    2. FEEL does not support a literal scientific notation. E.g., 1 .2e3 is not valid FEEL syntax. Use 1.2*10**3 instead.

  • Reported: DMN 1.4b1 — Tue, 11 Oct 2022 08:45 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

DMN 1.4 updated XMI references external file DMN14.mdxml

  • Key: DMN15-98
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    The dtc/21-12-03 "DMN14.xmi updated" contains some references to a file DMN14.mdxml,

    252:        <type href="DMN14.mdxml#_17_0_5_1_a250249_1518651646564_243499_3956"/>
    655:        <type href="DMN14.mdxml#_17_0_2_3_ea50349_1435268843602_88699_2217"/>
    656:        <association href="DMN14.mdxml#_17_0_2_3_ea50349_1435269041753_841899_2676"/>
    666:        <type href="DMN14.mdxml#_17_0_2_3_ea50349_1435268832194_670602_2213"/>
    667:        <association href="DMN14.mdxml#_17_0_2_3_ea50349_1435269293045_464837_2775"/>
    677:        <type href="DMN14.mdxml#_17_0_2_3_ea50349_1435268824892_950814_2209"/>
    678:        <association href="DMN14.mdxml#_17_0_2_3_ea50349_1435269539220_831013_2875"/>
    2298:      <memberEnd href="DMN14.mdxml#_17_0_5_1_a250249_1518651855436_638563_4054"/>
    

    Please check whether those references are intended and if so, please clarify where to obtain that file.

  • Reported: DMN 1.4 — Mon, 4 Apr 2022 21:56 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Misprint in

  • Key: DMN15-142
  • Status: open  
  • Source: AMBESAS ( Thierry BIARD)
  • Summary:

    In this couple of chapters, "duration" is written "duraion" (without "t" - 2 occurrences)

  • Reported: DMN 1.4b1 — Sun, 18 Dec 2022 11:12 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Typo - "duraion"

  • Key: DMN15-149
  • Status: open  
  • Source: FICO ( Alan Fish)
  • Summary:

    Sections 10.3.2.3.7 and 10.3.2.3.8 have "duraion" instead of "duration"

  • Reported: DMN 1.4 — Wed, 18 Jan 2023 12:32 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Acknowledgements for DMN 1.4 and 1.5 contributors needed

  • Key: DMN15-104
  • Status: open  
  • Source: Camunda Services GmbH ( Falko Menge)
  • Summary:

    Section "4.1 Acknowledgements" is missing paragraphs to acknowledge the DMN 1.4 and 1.5 contributors, especially since some people left the task force.

  • Reported: DMN 1.4b1 — Tue, 24 May 2022 17:46 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

New Namespace URIs needed

  • Key: DMN15-159
  • Status: open  
  • Source: Camunda Services GmbH ( Falko Menge)
  • Summary:

    For tools to clearly identify the version of a DMN file or FEEL expression, the XML namespaces of DMN, DMN DI, and FEEL should be updated.

    Namespace URIs must be backwards compatible with the scheme applied in previous versions for tools that support multiple versions in parallel. See:

    DI and DC namespaces can stay the same as DMN 1.4 DI is still based on the same DI 1.1 specification and "OMG Policy for Versioning of Specification URIs, File URIs, and XML Namespaces in OMG Specifications", states explicitly:

    Note: if a spec has many machine readable files, and only some of them change at a given specification version, then only the changed files should get new URIs. That could mean a mixture of URI date segment values for a given specification version..

  • Reported: DMN 1.4b1 — Tue, 14 Feb 2023 16:15 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Superfluous spaces after "1"

  • Key: DMN15-155
  • Status: open  
  • Source: FICO ( Alan Fish)
  • Summary:

    Section 10.3 contains a number of instances where a space has appeared after the numeral 1. Sometimes this makes the syntax incorrect.

  • Reported: DMN 1.4 — Tue, 14 Feb 2023 10:11 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Copyright section needs update

  • Key: DMN15-157
  • Status: open  
  • Source: Camunda Services GmbH ( Falko Menge)
  • Summary:

    The copyright section needs to be updated.

  • Reported: DMN 1.4b1 — Tue, 14 Feb 2023 11:51 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Multiple empty imports using the order as a precedence is not allowed

  • Key: DMN15-153
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    The specification is not clear in section 6.3.3 if multiple imports into the default namespace are allowed and how the import precedence is managed.

  • Reported: DMN 1.4b1 — Tue, 31 Jan 2023 22:18 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Incorrect function name in example

  • Key: DMN15-119
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    There are 2 typos in the examples

    duraion("P0DT25H") and duraion("P0Y13M"))

    Should be

    duration("P0DT25H") and duraton("P0Y13M"))

  • Reported: DMN 1.4b1 — Tue, 11 Oct 2022 08:37 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

Typo in Table 66

  • Key: DMN15-118
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    With reference to DMN v1.4 dtc-21-12-01 pdf
    Table 66 list all the properties for duration FEEL value type, the property hours (plural) is inadvertently spelled with the capital H, but it should be lower case hours

  • Reported: DMN 1.4b1 — Mon, 10 Oct 2022 14:17 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT