Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — Open Issues

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

Issues Descriptions

Wrong and Incomplete FEEL grammar rule 52

  • Key: DMN14-87
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    Grammar rule 52 is using single quote notation, and I believe this is just a typo when submitting the original change.

    However DMNv1.3 also missed to exclude grammar 52 from defining Literal terminal symbol.
    This is a concerning problem.
    This implies rule 52 as defined in DMNv1.3 is defining additional Literal terminal symbol(s) and therefore with DMNv1.3 it is no longer formally possible to name a DRGElement for example: "list of products" or "context of business".
    I believe this is an oversight in backward compatibility:

    • rule 52 is only used for the technical “instance of” operator which may find limited use by business analysts
    • using as a name “list …” or “context …” might be more relevant and wide-spread used, ref examples above

    The proposal below addresses this problem as well, making DMNv1.3+ backward compatible again

    Proposal

    A total of 2 changes.

    With reference to DMNv1.3 dtc-19-12-06

    Chapter 10.3.1.2 Grammar rules Page 121
    replace:

    52. type =
    qualified name |
    'list' '<' type '>' |
    'context' '<' name ':' type { ',' name ':' type } '>' | 'function' '<' [ type { ', ' type } ] '>' '->' type
    ;
    

    with:

    52. type =
    qualified name |
    "list" "<" type ">" |
    "context" "<" name ":" type { "," name ":" type } ">" | "function" "<" [ type { ", " type } ] ">" "->" type
    ;
    

    Chapter 10.3.1.4 Tokens, Names, and White space Page 122
    before bullet point:

    * A sequence conforming to grammar rule 28, 29, 35, or 37

    insert new bullet point:

    * for backward compatibility reasons, “list” and “context” from grammar rule 52 are not considered Literal terminal symbols.

  • Reported: DMN 1.3 — Wed, 8 Apr 2020 07:20 GMT
  • Updated: Wed, 18 Nov 2020 00:45 GMT

Wrong XSD for tDecisionService

  • Key: DMN14-93
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    With refererence to DMNv1.3 dtc-19-12-06
    Chapter 6.3.10 Decision service metamodel
    page 64

    the table
    Table 17: DecisionService attributes and model associations

    reports:

    outputDecisions: Decision [1..*]

    but the XSD schema:

    <xsd:element name="outputDecision" type="tDMNElementReference" minOccurs="0" maxOccurs="unbounded"/>
    

    Proposal

    change XSD from:

    <xsd:element name="outputDecision" type="tDMNElementReference" minOccurs="0" maxOccurs="unbounded"/>
    

    to

    <xsd:element name="outputDecision" type="tDMNElementReference" minOccurs="1" maxOccurs="unbounded"/>
    

    (minOccurs to 1)

  • Reported: DMN 1.3 — Fri, 5 Jun 2020 06:49 GMT
  • Updated: Wed, 18 Nov 2020 00:45 GMT

Wrong example for is() built-in function

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

    Executive summary

    I believe the last example for the is() built-in function of DMNv1.3 is wrong.

    Details

    The example from DMNv1.3 which I believe is wrong is:
    is(time("23:00:50z"), time("23:00:50+00:00”)) is false

    Besides that is not FEEL and not consistent with the other examples, but likely it is meant to be humanly interpreted as is(time("23:00:50z"), time("23:00:50+00:00”)) = false which I argue is wrong semantically.

    Accordingly to 10.3.2.3.4 time:

    A time in the semantic domain is a value of the XML Schema time datatype. It can be represented by a sequence of numbers for the hour, minute, second, and an optional time offset from Universal Coordinated Time (UTC).

    Understanding from this first sentence is that in the FEEL semantic domain time is defined by time: H, M, S, OFFSET?

    it continues with:

    If a time offset is specified, including time offset = 00:00, the time value has a UTC form and is comparable to all time values that have UTC forms.
    If no time offset is specified, the time is interpreted as a local time of day at some location,

    So we can have in the FEEL semantic domain a

    • time: H, M, S, no offset specified "local time of day at some location"
      or
    • time: H, M, S, OFFSET

    This is consistent with 10.3.4.1 Conversion functions:

    time string – either
    a string value in the lexical space of the time datatype specified by XML Schema Part 2 Datatypes; or
    a string value that is the extended form of a local time representation as specified by ISO 8601, followed by the character "@", followed by a string value that is a time zone identifier in the IANA Time Zones Database (http://www.iana.org/time-zones)

    Therefore:
    if we are in the first case by XML Schema Part 2 Datatypes we will have an offset if something follow the ":ss" seconds part in the string,
    otherwise,
    if we use the second case "hh:mm:ss@location" form, we will not have an XML Schema Part 2 Datatypes offset, but we will interpret the time at some geographical location offset based on IANA.

    Follows interpretation of a few examples of time strings, and their FEEL semantic domain projection:

    time string 10.3.4.1 Conversion functions time string first or second case? H M S specified OFFSET? OFFSET because XML Schema Part 2 OFFSET because IANA Time Zones Database
    "23:00:50" first case 23 0 50 no null null
    "23:00:50@Europe/Rome" second case 23 0 50 yes null Europe/Rome
    "23:00:50@Europe/Paris" second case 23 0 50 yes null Europe/Paris
    "23:00:50+02:00" first case 23 0 50 yes +2 null
    "23:00:50+00:00" first case 23 0 50 yes +0 null
    "23:00:50Z" first case 23 0 50 yes +0 null

    Accordingly to DMNv1.3 they will be all equals as in a=b (as valuet() does return the same for all of them).

    Accordingly to DMNv1.3 they are all FEEL semantically domain different expect the last two, because once projected to the semantic domain they represent the same hour, minute, second, AND offset quantity, accordingly to a string value in the lexical space of the time datatype specified by XML Schema Part 2 Datatypes.

    Hence, resulting in

    is(time("23:00:50z"), time("23:00:50+00:00")) = true
    

    instead.

    Proposal

    change last line example from:

    is(time("23:00:50z"), time("23:00:50+00:00”)) is false
    

    to

    is(time("23:00:50z"), time("23:00:50+00:00")) = true
    
  • Reported: DMN 1.3 — Tue, 7 Apr 2020 12:58 GMT
  • Updated: Wed, 18 Nov 2020 00:45 GMT

Wrong example for distinct values() built-in function

  • Key: DMN14-85
  • Status: open  
  • Source: Red Hat ( Matteo Mortari)
  • Summary:

    this is a typo fix: the example is missing a closed round paren.

    Proposal

    with reference to DMNv1.3 dtc/19-12-06 in chapter 10.3.4.4 List functions page 161 replace:

    distinct values([1,2,3,2,1] = [1,2,3]
    

    with

    distinct values([1,2,3,2,1]) = [1,2,3]
    
  • Reported: DMN 1.3 — Tue, 7 Apr 2020 08:17 GMT
  • Updated: Wed, 18 Nov 2020 00:45 GMT

Links with other standards

  • Key: DMN14-106
  • Status: open  
  • Source: FICO ( Alan Fish)
  • Summary:

    A "bucket" for collecting related issues around external links

  • Reported: DMN 1.3 — Tue, 3 Nov 2020 18:17 GMT
  • Updated: Tue, 3 Nov 2020 18:18 GMT

The "schemaLocation" relative URLs are broken

  • Key: DMN14-95
  • Status: open  
  • Source: Mayo Clinic ( Davide Sottara)
  • Summary:

    In DMNDI13.xsd:

    <?xml version="1.0" encoding="UTF-8"?>
    <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:dmndi="https://www.omg.org/spec/DMN/20191111/DMNDI/"
    xmlns:dc="http://www.omg.org/spec/DMN/20180521/DC/"
    xmlns:di="http://www.omg.org/spec/DMN/20180521/DI/"
    targetNamespace="https://www.omg.org/spec/DMN/20191111/DMNDI/"
    elementFormDefault="qualified" attributeFormDefault="unqualified">

    <xsd:import namespace="http://www.omg.org/spec/DMN/20180521/DC/"
    schemaLocation="DC.xsd"/>
    <xsd:import namespace="http://www.omg.org/spec/DMN/20180521/DI/"
    schemaLocation="DI.xsd"/>

    The schemaLocations for the DC/DI schemas that were introduced in DMN1.2 have not been upgraded to take into account the new URL for DMN 1.3
    While the relative location worked for DMN 1.2 (v20180521), the relative URLs resolve to https://www.omg.org/spec/DMN/20191111/DC.xsd (resp DI.xsd)

    This causes issues with tools such as IDEs and schema validators that try to resolve the URLs of the imports.
    The schemaLocations should be updated to use full URLs

  • Reported: DMN 1.3 — Mon, 14 Sep 2020 22:04 GMT
  • Updated: Tue, 22 Sep 2020 19:23 GMT

Missing InformationItem Association?

  • Key: DMN14-94
  • Status: open  
  • Source: Department of Veterans Affairs ( 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, 10 Jul 2020 21:55 GMT

First (and priority) hit policy are unpredictable with partial input

  • Key: DMN14-88
  • Status: open  
  • Source: Moxio ( Merijn Wijngaard)
  • Summary:

    A decision table with a hit policy of FIRST uses rule order to decide its output, but only among those rules which have an output. This works fine when the input is complete, but becomes unpredictable when input is partial. Higher priority rules (earlier in the order) may not have an output yet while lower priority rules do, even when higher priority rules may generate an output in the future when more input become available. This makes the FIRST hit policy (the same goes for PRIORITY) not usable in a context where the decision logic will be run on partial, incrementally expanded input (e.g. an interactive expert system).

    When reading the description for the FIRST hit policy in the spec, I get the feeling that the OMG is opposed to having rule order play a role in the evaluation of a decision table. I realize there are ways around using rule order by using different hit policies and separating the logic into multiple decision tables, but I do believe that that would not improve the understandability of the logic. Having the rule order play a role in the evaluation of a decision table can definitely make them more self-contained (decision tables are smaller and/or logic is less spread out), and therefore easier to write and understand in some cases. But an implementation that uses rule order needs to be predictable, even on partial input.

    Therefore I would like to propose an addition to the existing hit policies: ELIMINATE (or at least i think that term describes it well).

    The ELIMINATE hit policy evaluates a decision table's rules in order:

    • If a rule is validated (it matches), it produces an output and evaluation is stopped
    • If a rule is invalidated (it will never match, even as more input becomes available), evaluation continues with the next rule (i.e. it is eliminated)
    • If a rule cannot be invalidated (because input is partial), evaluation is stopped and the table produces no output
    • A decision table with a hit policy of ELIMINATE can only ever produce a single output

    I hope you will consider adding this to the spec in some form or another, since it would make working with dmn in a context of incrementally expanding input a lot easier.

  • Reported: DMN 1.3 — Fri, 29 May 2020 08:30 GMT
  • Updated: Wed, 24 Jun 2020 18:38 GMT

Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression

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

    Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression. The figure should be updated.
    This is similar to the issue for Figure 6-10, which has the same problem.

  • Reported: DMN 1.3 — Wed, 1 Jan 2020 00:21 GMT
  • Updated: Mon, 6 Jan 2020 20:44 GMT

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

  • Key: DMN14-69
  • Status: open  
  • Source: Department of Veterans Affairs ( 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: Mon, 6 Jan 2020 20:44 GMT