Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN16-64 Clarification on syntax of DMNReference DMN 1.3 open
DMN15-73 Clarification on syntax of DMNReference DMN 1.3 open
DMN15-77 Missing InformationItem Association? DMN 1.3 open
DMN16-66 Missing InformationItem Association? DMN 1.3 open
DMN15-75 Links with other standards DMN 1.3 open
DMN16-65 Links with other standards DMN 1.3 open
DMN15-69 Allow for partial temporal values DMN 1.3 open
DMN15-68 FunctionItem `parameters` array attribute is plural, not singular in name DMN 1.3 open
DMN16-59 FunctionItem `parameters` array attribute is plural, not singular in name DMN 1.3 open
DMN15-70 Change to the "at literal" in FEEL DMN 1.3 open
DMN16-61 Change to the "at literal" in FEEL DMN 1.3 open
DMN15-71 Adding a new interval built-in function DMN 1.3 open
DMN16-62 Adding a new interval built-in function DMN 1.3 open
DMN15-72 Allow input data to be of type Interval DMN 1.3 open
DMN16-63 Allow input data to be of type Interval DMN 1.3 open
DMN16-60 Allow for partial temporal values DMN 1.3 open
DMN15-64 P0D == P0Y in SFEEL, but it is unclear if P0D == P0Y in FEEL DMN 1.3 open
DMN16-56 P0D == P0Y in SFEEL, but it is unclear if P0D == P0Y in FEEL DMN 1.3 open
DMN15-66 the operation of is() function is not well specified DMN 1.3 open
DMN16-57 the operation of is() function is not well specified DMN 1.3 open
DMN15-67 Ambiguous named params for before() and after() range functions DMN 1.3 open
DMN16-58 Ambiguous named params for before() and after() range functions DMN 1.3 open
DMN15-63 No way to tell that a Decision iterates over a collection DMN 1.3 open
DMN16-55 No way to tell that a Decision iterates over a collection DMN 1.3 open
DMN15-61 DRG requirements only state am unused knowledge requirement is illegal DMN 1.3 open
DMN16-53 DRG requirements only state am unused knowledge requirement is illegal DMN 1.3 open
DMN15-59 Spec does not mandate that all user-defined function parameters are utilised DMN 1.3 open
DMN15-62 No way to show relative multiplicity of decisions and their information requirements DMN 1.3 open
DMN15-60 Spec does not mandate that all formal parameters are utilised. DMN 1.3 open
DMN16-51 Spec does not mandate that all user-defined function parameters are utilised DMN 1.3 open
DMN16-52 Spec does not mandate that all formal parameters are utilised. DMN 1.3 open
DMN16-54 No way to show relative multiplicity of decisions and their information requirements DMN 1.3 open
DMN15-58 Missing semantics for multiple imports DMN 1.3 open
DMN15-57 Add an itemKind property to ItemDefinition DMN 1.3b1 open
DMN15-55 Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression DMN 1.3 open
DMN16-49 Add an itemKind property to ItemDefinition DMN 1.3b1 open
DMN16-48 Figure 8-20 shows UnaryTests as being a specialization of DMNElement when it has been changed to be a specialization of Expression DMN 1.3 open
DMN16-50 Missing semantics for multiple imports DMN 1.3 open
DMN15-54 Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests. DMN 1.3 open
DMN16-47 Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests. DMN 1.3 open
DMN15-78 Underspecified when ranges may include a qualified name for the endpoint, which resolves to null DMN 1.3 open
DMN15-65 spec places unrealistic constraints on decision expressions and BKM parameter bindings DMN 1.3 open
DMN15-76 The "schemaLocation" relative URLs are broken DMN 1.3 open
DMN15-74 Incorrect typeRef for variables associated to BKMs DMN 1.3 open

Issues Descriptions

Clarification on syntax of DMNReference


Clarification on syntax of DMNReference


Missing InformationItem Association?

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

Missing InformationItem Association?

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

Links with other standards

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

Links with other standards

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

Allow for partial temporal values

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

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

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

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

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

Change to the "at literal" in FEEL

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

    Currently the at literal = "@", string literal
    Rather than a string following the @ symbol we would use the ISO 8601 format.
    For date : @YYYY-MM-DD e.g. @2019-09-17
    For time : @THH:MM:SS e.g. @T09:55:00
    For date and time : @YYYY-MM-DDTHH:MM:SS e.g. @2019-09-17T09:55:00
    For duration : @P[n]Y[n]M[n]DT[n]H[n]M[n]S where [n] is a number
    e.g. @P18M, @P365D, PT48H

  • Reported: DMN 1.3 — Tue, 26 Jan 2021 22:11 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Change to the "at literal" in FEEL

  • Key: DMN16-61
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    Currently the at literal = "@", string literal
    Rather than a string following the @ symbol we would use the ISO 8601 format.
    For date : @YYYY-MM-DD e.g. @2019-09-17
    For time : @THH:MM:SS e.g. @T09:55:00
    For date and time : @YYYY-MM-DDTHH:MM:SS e.g. @2019-09-17T09:55:00
    For duration : @P[n]Y[n]M[n]DT[n]H[n]M[n]S where [n] is a number
    e.g. @P18M, @P365D, PT48H

  • Reported: DMN 1.3 — Tue, 26 Jan 2021 22:11 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Adding a new interval built-in function

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

Adding a new interval built-in function

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

Allow input data to be of type Interval

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

Allow input data to be of type Interval

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

Allow for partial temporal values

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

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

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

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

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

the operation of is() function is not well specified

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

the operation of is() function is not well specified

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

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

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

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

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

No way to tell that a Decision iterates over a collection

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

    There is no visual way to show that a decision iterates over a collection at the top level.

  • Reported: DMN 1.3 — Wed, 24 Feb 2021 05:31 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

No way to tell that a Decision iterates over a collection

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

    There is no visual way to show that a decision iterates over a collection at the top level.

  • Reported: DMN 1.3 — Wed, 24 Feb 2021 05:31 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

DRG requirements only state am unused knowledge requirement is illegal

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

DRG requirements only state am unused knowledge requirement is illegal

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

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

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

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

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

Spec does not mandate that all formal parameters are utilised.

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

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

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

Spec does not mandate that all formal parameters are utilised.

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

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

  • Key: DMN16-54
  • 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: Thu, 6 Apr 2023 14:59 GMT
  • Attachments:

Missing semantics for multiple imports

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

    The semantics of Import is not fully specified.

    In certain use cases the same DMN element (e.g. ItemDefinition or DRGElement) can be imported multiple times (e.g. transitive imports).

    Lets consider the following use case:

    • Model A contains the definition of an InputData for a Person (e.g. name, age etc)
    • Model B imports model A. Model B contains a decisions DB that uses the Person as input
    • Model C imports models A and B. Model C contains a decision DC that uses Person and DB as input

    In this situation model C imports Person twice due to transitive import.

    In order to evaluate DC the Person InputData has to be bound to a value. The question is how many values is the user going to provide, lets say in a Web form? A single value or one value for each import path (in this case 2)?

    I am inclining towards the first option - one single value per input data. Here is my rationale:

    • InputDatas / DRGElements are uniquely identified by model namespace and DRGElement.name
    • InputDatas own one single variable (see 6.3. Metamodel). The semnatics for InputData.variable is in Table 18:
      The instance of InformationItem that stores the result of this InputData.
    • Consistency with the import of other DMN Elements: it does not make any sense for ItemDefinitions, BKMs and DSs to have multiple variables / values when imported several times.
    • If we choose the second option and the model is refactored (e.g. models are merged), but the logic does not change, the user has to fill-in different input forms. It is not very user friendly.
    • I am not aware of any PL/DSL that uses the second option

    Lets discuss.

  • Reported: DMN 1.3 — Tue, 30 Mar 2021 08:28 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

Add an itemKind property to ItemDefinition

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

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

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

Add an itemKind property to ItemDefinition

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

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

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

Missing semantics for multiple imports

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

    The semantics of Import is not fully specified.

    In certain use cases the same DMN element (e.g. ItemDefinition or DRGElement) can be imported multiple times (e.g. transitive imports).

    Lets consider the following use case:

    • Model A contains the definition of an InputData for a Person (e.g. name, age etc)
    • Model B imports model A. Model B contains a decisions DB that uses the Person as input
    • Model C imports models A and B. Model C contains a decision DC that uses Person and DB as input

    In this situation model C imports Person twice due to transitive import.

    In order to evaluate DC the Person InputData has to be bound to a value. The question is how many values is the user going to provide, lets say in a Web form? A single value or one value for each import path (in this case 2)?

    I am inclining towards the first option - one single value per input data. Here is my rationale:

    • InputDatas / DRGElements are uniquely identified by model namespace and DRGElement.name
    • InputDatas own one single variable (see 6.3. Metamodel). The semnatics for InputData.variable is in Table 18:
      The instance of InformationItem that stores the result of this InputData.
    • Consistency with the import of other DMN Elements: it does not make any sense for ItemDefinitions, BKMs and DSs to have multiple variables / values when imported several times.
    • If we choose the second option and the model is refactored (e.g. models are merged), but the logic does not change, the user has to fill-in different input forms. It is not very user friendly.
    • I am not aware of any PL/DSL that uses the second option

    Lets discuss.

  • Reported: DMN 1.3 — Tue, 30 Mar 2021 08:28 GMT
  • Updated: Thu, 6 Apr 2023 14:59 GMT

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

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

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

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

Underspecified when ranges may include a qualified name for the endpoint, which resolves to null

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

    It is underspecified when the ranges may include a qualified name for the endpoint, which resolves to null.

    This was identified by Greg McCreath and Octavian Patrascoiu during TCK contributions.

    Ranges' Endpoints can be either a literal or a qualified name. If the qualified name resolves to null, and the endpoint inclusivity flag is false, it is semantically equivalent to the case of single-endpoint-range. This leads to ambiguity in Table 55: Semantics of decision table syntax

    This also requires the typo fix in https://issues.omg.org/browse/INBOX-1337

    Example

    With reference to examples in Table 42: Examples of range properties values

    Instead of (1..10]
    do consider (x..10]
    if x resolves to null
    then this is semantically equivalent to <=10.

    However, Table 55, row 9, cites:

    e1 in (e2..e3] is equivalent to e1 > e2 and e1<=e3
    
    // exercise by hand..
    e1 in (x..10] is equivalent to e1 > x and e1<=10
    // if x resolves to null..
    e1 in (null..10] is equivalent to e1 > null and e1<=10
    e1 > null and e1<=10
    

    which is NOT equivalent to e1<=10, hence the ambiguity.

  • Reported: DMN 1.3 — Sun, 5 Sep 2021 07:18 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

spec places unrealistic constraints on decision expressions and BKM parameter bindings

  • Key: DMN15-65
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    Section 7.1 specifies that under certain circumstances relating to BKMs a decision must have a literal expression, and BKM parameter bindings relate to decision inputs. For example:

    "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."

    So, in essence dictating that if a decision uses more than 1 BKM its expression must be a literal expression. In practice, a decision may use its BKMs in various ways - to populate a boxed context entry, or even not to invoke it at all and (say) pass the BKM to another BKMN or function accepting as function type parameter.

    This statement should be removed from the spec.

    Next: "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."

    Again, whether a decision uses a BKM or not has no bearing on the type of expression a decision has. A decision with no BKM may have any expression including (say) a boxed context, or a list, or indeed may return a function definition - not just a literal expression or a decision table . The above text should be removed from the spec.

    Next: "Similarly, if a decision element requires only one business knowledge model element, but the logic of the decision elaborates on the logic of its required business knowledge model, the decision element must have a literal expression that specifies how the business knowledge model's value expression is invoked, and how its result is elaborated to provide the decision's outcome."

    The same - this text should be removed from the spec.

    Next: "In all other cases (i.e., when a decision requires exactly one business knowledge model and does not elaborate the logic), the value expression of a decision element may be a value expression of type invocation. In a value expression of type invocation, only the bindings of the business knowledge model parameters to the decisions input data need be specified: the outcome of the decision is the result returned by the business knowledge model's value expression for the values passed to its parameters."

    Again, this is unnecessarily limiting how a decision may use a BKM. For example, a decision may actually return the BKM as its value. The above text should be removed from the spec.

    Additionally, the following should be removed:

    "At the decision logic level, a decision invokes a required business knowledge model by evaluating the business knowledge model's value expression with the parameters bound to its own input value. How this may be achieved depends on how the decision logic is partitioned between the decision and business knowledge models:"

    A decision does not have to bind its input values to a BKM parameters. As a decision may have (say) contexts that evaluate in a top down manner and the binding to a BKMs parameters could be any manner of calculations in that context or results of other BKM invocations that do not strictly relate to the inputs of a decision.

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 10:01 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT

The "schemaLocation" relative URLs are broken

  • Key: DMN15-76
  • 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, 28 Mar 2023 17:39 GMT

Incorrect typeRef for variables associated to BKMs

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

    The typeRef attribute in the variable attribute of Business Knowledge Models in file 'Chapter 11 Example.dmn' from the examples archive is incorrect. The values references the output type (e.g. an item definition) and not a function item (introduced in DMN 1.3).

    According to DMN 1.3 (Table 14, page 57), the semantic of variable attribute is:

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

    Hence, the typeRef attribute has to reference a FunctionItem, Any or no type at all.

    The issue was reported initially by Daniel Thanner in the TCK group (https://github.com/dmn-tck/tck/issues/376) and lead to the introduction of FunctionItems.

    Proposal:

    There are 3 ways to address this:
    1. Remove typeRef from variables in BKMs
    2. Change value to Any
    3. Create FunctionItems for every BKM in the dmn file and reference them

  • Reported: DMN 1.3 — Mon, 14 Dec 2020 18:07 GMT
  • Updated: Tue, 28 Mar 2023 17:39 GMT