Decision Model and Notation Avatar
  1. OMG Specification

Decision Model and Notation — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
DMN14-150 Collections are not shown on diagrams DMN 1.3 open
DMN14-164 More examples of replace() function needed DMN 1.3 open
DMN14-178 Are the names of boxed context entries unique in a given context ? DMN 1.3 open
DMN14-167 Sub-decisions are referenced but not defined DMN 1.3 open
DMN14-185 Incorrect figure reference DMN 1.3 open
DMN14-117 typo - incorrect indexing DMN 1.3 open
DMN14-143 instance of grammar does not support range , or context, or function DMN 1.3 open
DMN14-197 Underspecified when ranges may include a qualified name for the endpoint, which resolves to null DMN 1.3 open
DMN14-196 Typo Table55 row 7 DMN 1.3 open
DMN14-194 Missing boxed expression for iterator expression DMN 1.3 open
DMN14-192 Missing boxed expression for filter expression DMN 1.3 open
DMN14-190 Missing boxed expression for conditional statement DMN 1.3 open
DMN14-181 No function to add an entry to a context DMN 1.3 open
DMN14-182 New built-in function to merge/concatenate two or more contexts DMN 1.3 open
DMN14-183 New built-in function to create a new context DMN 1.3 open
DMN14-87 Wrong and Incomplete FEEL grammar rule 52 DMN 1.3 open
DMN14-142 DMNDiagram 'Size' attribute has capital 'S' in schema definition DMN 1.3 open
DMN14-156 the word 'decision' is misspelt. DMN 1.3 open
DMN14-126 Missing functions for rounding DMN 1.3 open
DMN14-141 The result of product([]) is not defined DMN 1.3 open
DMN14-136 Extend endpoints to support expressions DMN 1.3 open
DMN14-137 Typo in horizontal alignment label DMN 1.3 open
DMN14-116 DMN string join built-in function proposal DMN 1.3 open
DMN14-88 First (and priority) hit policy are unpredictable with partial input DMN 1.3 open
DMN14-125 Definitions of overlaps functions DMN 1.3 open
DMN14-166 New XML Namespace needed DMN 1.3 open
DMN14-163 Add an itemKind property to ItemDefinition DMN 1.3b1 open
DMN14-161 Missing semantics for multiple imports DMN 1.3 open
DMN14-160 Spec does not mandate that all user-defined function parameters are utilised DMN 1.3 open
DMN14-159 Spec does not mandate that all formal parameters are utilised. DMN 1.3 open
DMN14-158 DRG requirements only state am unused knowledge requirement is illegal DMN 1.3 open
DMN14-153 No way to show relative multiplicity of decisions and their information requirements DMN 1.3 open
DMN14-152 No way to tell that a Decision iterates over a collection DMN 1.3 open
DMN14-138 P0D == P0Y in SFEEL, but it is unclear if P0D == P0Y in FEEL DMN 1.3 open
DMN14-139 spec places unrealistic constraints on decision expressions and BKM parameter bindings DMN 1.3 open
DMN14-140 the operation of is() function is not well specified DMN 1.3 open
DMN14-135 Ambiguous named params for before() and after() range functions DMN 1.3 open
DMN14-134 FunctionItem `parameters` array attribute is plural, not singular in name DMN 1.3 open
DMN14-132 Allow for partial temporal values DMN 1.3 open
DMN14-131 Change to the "at literal" in FEEL DMN 1.3 open
DMN14-130 Adding a new interval built-in function DMN 1.3 open
DMN14-129 Allow input data to be of type Interval DMN 1.3 open
DMN14-124 Clarification on syntax of DMNReference DMN 1.3 open
DMN14-118 Incorrect typeRef for variables associated to BKMs DMN 1.3 open
DMN14-93 Wrong XSD for tDecisionService DMN 1.3 open
DMN14-86 Wrong example for is() built-in function DMN 1.3 open
DMN14-85 Wrong example for distinct values() built-in function DMN 1.3 open
DMN14-106 Links with other standards DMN 1.3 open
DMN14-95 The "schemaLocation" relative URLs are broken DMN 1.3 open
DMN14-94 Missing InformationItem Association? DMN 1.3 open
DMN14-70 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
DMN14-69 Figure 10.17 defines DMN Expressions and lists its specializations, but it does not list Unary Tests. DMN 1.3 open

Issues Descriptions

Collections are not shown on diagrams


More examples of replace() function needed

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

    for instance append a basic down-to-Earth example like:

    replace("banana","a","o") = "bonono"
    

    as already agreed on the DMN TCK.

    We found User enquiry about the behaviour of the function, and the only example listed currently is quite techy. Possibly adding a simple example first would help end-users

  • Reported: DMN 1.3 — Tue, 13 Apr 2021 10:16 GMT
  • Updated: Wed, 6 Oct 2021 00:49 GMT

Are the names of boxed context entries unique in a given context ?

  • Key: DMN14-178
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    The standard does not specify if a valid boxed context can contain several context entries with the same key or not.

    However, it does specify that if a FEEL context is described via text (see FEEL grammar and 10.3.2.6 Context) the keys are distinct.

    Also, how are the names overriden / shaded ?

  • Reported: DMN 1.3 — Tue, 8 Jun 2021 11:10 GMT
  • Updated: Wed, 6 Oct 2021 00:49 GMT

Sub-decisions are referenced but not defined

  • Key: DMN14-167
  • Status: open  
  • Source: Sapiens Decision NA ( Gil Segal)
  • Summary:

    The DMN 1.3 specification refers to "sub-decisions" in two places (sections 5.3.3 and 10.6.1) but this term is not defined.

  • Reported: DMN 1.3 — Thu, 27 May 2021 15:19 GMT
  • Updated: Wed, 6 Oct 2021 00:49 GMT

Incorrect figure reference

  • Key: DMN14-185
  • Status: open  
  • Source: Sapiens Decision NA ( Gil Segal)
  • Summary:

    On p. 155, section 10.6.1 incorrectly refers to Figure 10-2. The reference should be to Figure 10-18 which is found on p. 156.

  • Reported: DMN 1.3 — Tue, 29 Jun 2021 16:35 GMT
  • Updated: Wed, 6 Oct 2021 00:49 GMT

typo - incorrect indexing

  • Key: DMN14-117
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    Second paragraph from the bottom of page 173 contains

    have qualified names nbkmi and encapsulatedLogic bkmi.f.

    it should be

    have qualified names nbkmi and encapsulatedLogic fbkmi.

    where bkmi are formatted as indexes (see description of the of the syntax for FEEL function in the naext paragraph).

  • Reported: DMN 1.3 — Thu, 24 Dec 2020 10:23 GMT
  • Updated: Wed, 6 Oct 2021 00:49 GMT

instance of grammar does not support range , or context, or function

  • Key: DMN14-143
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The instance of grammar does not include the range type, so it is not possible to do `[1..10] instance of range<Any>`. Nor does it support either identifying something as simply a context, or simply as a function.

    Please add range<type> to the grammar.

    The grammar does support identifying something as simply a context. The list type can be accommodated by <Any>, such as `foo instance of list<Any>`, but the grammar for context currently requires at least one name and type, so simply checking that something is a context is not supported. That is, `foo instance of context<>` is not possible.

    Please change the context grammar from `'context' '<' name ':' type

    { ',' name ':' type }

    '>' to `'context' '<[' name ':' type

    { ',' name ':' type }

    ']>'` implying that `context<>` means a context with no entries and thus, all contexts conform to it. Though, a more preferable alternative is described below.

    Also, the grammar does not support identifying something as a function, only as a function of a given type - there is no equivalent to `foo instance of function<Any> -> Any`. The statement `foo instance of function<> -> Any` is testing for a function type with no params. This is different to testing purely for a function type.

    A grammar to support the above is simply to support the name of each of the types with no `<>` stuff afterwards. Such that `foo instance of list`, `foo instance of context`, `foo instance of function`, `foo instance of range` are all valid. This would be my preference.

  • Reported: DMN 1.3 — Sun, 21 Feb 2021 01:03 GMT
  • Updated: Tue, 5 Oct 2021 17:16 GMT

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

  • Key: DMN14-197
  • 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: Wed, 22 Sep 2021 13:11 GMT

Typo Table55 row 7

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

    From row 4 it is about syntax sugar for inequality, but is missing the >case (row7).

  • Reported: DMN 1.3 — Sun, 5 Sep 2021 07:10 GMT
  • Updated: Wed, 22 Sep 2021 13:08 GMT

Missing boxed expression for iterator expression

  • Key: DMN14-194
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    The current version of the spec is missing a boxed expression visualization and serialization for iterator expressions

  • Reported: DMN 1.3 — Tue, 7 Sep 2021 12:58 GMT
  • Updated: Tue, 7 Sep 2021 12:58 GMT

Missing boxed expression for filter expression

  • Key: DMN14-192
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    The current version of the spec is missing a boxed expression visualization and serialization for filter expression

  • Reported: DMN 1.3 — Tue, 7 Sep 2021 12:54 GMT
  • Updated: Tue, 7 Sep 2021 12:54 GMT

Missing boxed expression for conditional statement

  • Key: DMN14-190
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    The current version of the spec is missing a boxed expression visualization and serialization for conditional statement

  • Reported: DMN 1.3 — Tue, 7 Sep 2021 12:46 GMT
  • Updated: Tue, 7 Sep 2021 12:46 GMT

No function to add an entry to a context

  • Key: DMN14-181
  • Status: open  
  • Source: Camunda Services GmbH ( Philipp Ossler)
  • Summary:

    Currently, it is not possible to add an entry to a given context. A context can only be declared statically.

    We need to model a decision that gets a context, adds an entry, and returns the new context.

    Suggestions:

    • introduce a new built-in function similar to the add() function of lists but for contexts
    • it is named `put` (like Java's Map#put function)
    • it has three arguments: context (type: context<Any>), key (type: string), value (type: Any)
    • it returns a new context that includes the new entry
    • it might overwrite the value of an existing entry
    put({x:1}, "y", 2)
    // returns {x:1, y:2}
    
  • Reported: DMN 1.3 — Tue, 22 Jun 2021 03:45 GMT
  • Updated: Tue, 24 Aug 2021 17:25 GMT

New built-in function to merge/concatenate two or more contexts

  • Key: DMN14-182
  • Status: open  
  • Source: Camunda Services GmbH ( Philipp Ossler)
  • Summary:

    Currently, it is not possible to merge/concatenate two or more contexts. A context can only be declared statically.

    We need to model a decision that gets two or more contexts and returns a new context that includes all entries of the given contexts.

    Suggestions:

    • introduce a new built-in function similar to the concatenate() function of lists but for contexts
    • it is named `put all` (like Java's Map#putAll function)
    • it has one argument: contexts... (type: list<context<Any>>)
    • it returns a new context that includes all entries from the given contexts
    • it might override context entries if the keys are equal. The entries are overridden in the same order as the contexts are passed in the function
    put all({x:1}, {y:2})
    // returns: {x:1, y:2}
    
  • Reported: DMN 1.3 — Tue, 22 Jun 2021 03:56 GMT
  • Updated: Tue, 24 Aug 2021 17:22 GMT

New built-in function to create a new context

  • Key: DMN14-183
  • Status: open  
  • Source: Camunda Services GmbH ( Philipp Ossler)
  • Summary:

    Currently, it is not possible to create or modify a context dynamically. A context can only be declared statically.

    We need to model a decision that gets a context, adds or removes entries, and returns a new context. For example, by using the get entries() function of a given context and modifying the entry list with a filter expression or list functions.

    Suggestions:

    • introduce a new conversion built-in function for context as reverse function to get entries()
    • it is named `context`
    • it has one argument: entries... (type: list<context<Any>>) - each context must have two entries with the keys: "key" and "value"
    • it returns a new context that includes all given entries
    context([{"key":"a", "value":1}, {"key":"b", "value":2}])
    // returns: {a:1, b:2}
    
  • Reported: DMN 1.3 — Tue, 22 Jun 2021 04:11 GMT
  • Updated: Tue, 24 Aug 2021 17:18 GMT

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: Tue, 29 Jun 2021 16:32 GMT

DMNDiagram 'Size' attribute has capital 'S' in schema definition

  • Key: DMN14-142
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The DMNDI13 XML schema has element child element 'Size' for DMNDiagram. Note the capital 'S'. This is an anomaly as all other element names have a lower case first char.

    Additionally, the spec on page 238 incorrectly has the element as 'size' - with a lower case.

    Suggestion is deprecate 'Size' in the schema, support both for a time, then drop 'Size' to support only support 'size' - to align the naming in the schema with other elements. And update the spec accordingly.

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 10:44 GMT
  • Updated: Wed, 21 Apr 2021 00:53 GMT

the word 'decision' is misspelt.

  • Key: DMN14-156
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    In the following section, the world 'decision' is misspelt as 'decsion'.

    "- Binding contexts in which the value of an expression is bound to a variable with associated type information
    (e.g. binding actual parameters to formal parameters in an invocation, or binding the result of a decision’s logic
    to the decsion’s output variable). The expression is subject to conforms to conversion."

  • Reported: DMN 1.3 — Sun, 28 Feb 2021 07:02 GMT
  • Updated: Wed, 21 Apr 2021 00:53 GMT

Missing functions for rounding

  • Key: DMN14-126
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    Currently the existing functions support: ceiling, flooring and even rounding.

    There are uses cases where other type of rounding are needed.

  • Reported: DMN 1.3 — Wed, 20 Jan 2021 20:15 GMT
  • Updated: Wed, 21 Apr 2021 00:53 GMT
  • Attachments:

The result of product([]) is not defined

  • Key: DMN14-141
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    The product() function may take a list but it is not defined what the return value is when the list is empty.

    It could be zero, or could be null. Other list function return null like `median( [ ] ) = null`, and `stddev( [ ] ) = null`, so it seems reasonable to make `product([]) = null`, but likely more business friendly to make `product([]) = 0`. I'd go for the latte.

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 10:29 GMT
  • Updated: Wed, 21 Apr 2021 00:53 GMT

Extend endpoints to support expressions

  • Key: DMN14-136
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    Currently enpoints can be only simple values (e.g. simple literals such as 123 or qualified names).

    This proposal is about extending the endpoints to be expressions. For example ranges such as [x, x+2) would be supported.

    Proposal:

    Page 120 Section 10.3.1.2. Grammar rules

    Replace

    16. endpoint = simple value ;

    with

    16. endpoint = expression ;

  • Reported: DMN 1.3 — Tue, 9 Feb 2021 17:38 GMT
  • Updated: Wed, 21 Apr 2021 00:53 GMT

Typo in horizontal alignment label

  • Key: DMN14-137
  • Status: open  
  • Source: Montera Pty Ltd ( Greg McCreath)
  • Summary:

    Spec say "labelHorizontalAlignement". Should be "labelHorizontalAlignment". The corresponding vertical property is correct at "labelVerticalAlignment".

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 09:12 GMT
  • Updated: Wed, 21 Apr 2021 00:53 GMT

DMN string join built-in function proposal

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

    This is a proposal for a new DMN built-in function to join a list of strings, for which currently the specification does not offer any out-of-the-box support.

    This is partially connected to OMG DMN RTF https://issues.omg.org/browse/DMN14-34, but it focuses only on a specific one, between of those functions.

    Assessment

    As of DMNv1.3 the specification is not offering any built-in support for the use-case of concatenating a list of strings into a final string.

    Please notice this is not the use case of using the “+” operator as in:

    first name + " " + last name
    

    This is the use case of joining a list of strings, for example

    [ "product 1", "product 2", ... ]
    

    In the book “DMN Cookbook: 50 Decision Modeling Recipes to Accelerate Your Business Rules” by Bruce Silver and Edson Tirelli ISBN: 9780982368183, the authors are offering 3 working solutions in Chapter 4.2. This requires however the modeler to implement manually or in a “personal library” of BKMs the preferred solution.

    The Signavio platform is offering it as a custom function (https://documentation.signavio.com/suite/en-us/Content/process-manager/userguide/dmn-literal-expressions.htm#concat) which however is only available on that specific platform.

    It is likely other Vendors are offering this functionality in their own way.

    This is an opportunity for the RTF to standardize what different people are doing differently, and not currently covered in the DMN spec.

  • Reported: DMN 1.3 — Tue, 15 Dec 2020 12:35 GMT
  • Updated: Wed, 21 Apr 2021 00:53 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, 21 Apr 2021 00:53 GMT

Definitions of overlaps functions

  • Key: DMN14-125
  • Status: open  
  • Source: Goldman Sachs ( Octavian Patrascoiu)
  • Summary:

    It looks like the logic definitions of functions overlaps and overlaps before do not produce the results expected in the Example column.

    The expected results look correct to me. I believe we need to fix the second column for overlaps and overlaps before as follows:

    For overlaps before:
    (range1.start < range2.start or (range1.start = range2.start and (range1.start included and not(range2.start included))))
    and (range1.end > range2.start or (range1.end = range2.start and range1.end included and range2.start included))
    and (range1.end < range2.end or (range1.end = range2.end and (not(range1.end included) or range2.end included )))

    For overlaps:
    overlapsBefore(range1, range2)
    or overlapsAfter(range1, range2),
    or includes(range1, range2),
    or includes(range2, range1)
    and leave the implementation to optimize the formula if needed.

  • Reported: DMN 1.3 — Mon, 4 Jan 2021 11:36 GMT
  • Updated: Wed, 21 Apr 2021 00:53 GMT

New XML Namespace needed

  • Key: DMN14-166
  • 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.

    DI and DC namespaces can stay the same as DMN 1.4 DI is still based on the same DI 1.1 specification.

    Namespace URIs should be consistent with the scheme applied in DMN 1.2 and DMN 1.3

  • Reported: DMN 1.3 — Tue, 20 Apr 2021 18:49 GMT
  • Updated: Tue, 20 Apr 2021 18:49 GMT

Add an itemKind property to ItemDefinition

  • Key: DMN14-163
  • 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: Tue, 13 Apr 2021 16:00 GMT

Missing semantics for multiple imports

  • Key: DMN14-161
  • 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.

    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, let 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: Wed, 7 Apr 2021 10:53 GMT

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

  • Key: DMN14-160
  • 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, 1 Apr 2021 15:49 GMT

Spec does not mandate that all formal parameters are utilised.

  • Key: DMN14-159
  • 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, 1 Apr 2021 15:49 GMT

DRG requirements only state am unused knowledge requirement is illegal

  • Key: DMN14-158
  • 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, 1 Apr 2021 15:48 GMT

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

  • Key: DMN14-153
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor)
  • 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: Wed, 24 Feb 2021 05:44 GMT
  • Attachments:

No way to tell that a Decision iterates over a collection

  • Key: DMN14-152
  • Status: open  
  • Source: Decision Management Solutions ( James Taylor)
  • 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: Wed, 24 Feb 2021 05:44 GMT

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

  • Key: DMN14-138
  • 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: Tue, 23 Feb 2021 19:03 GMT

spec places unrealistic constraints on decision expressions and BKM parameter bindings

  • Key: DMN14-139
  • 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.

    // ****

    Therefore, in summary I suggest removing all of the following text:

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

    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.

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

    The binding of a business knowledge model's parameter is a value expression that specifies how the value passed to that
    parameter is derived from the values of the input variables of the invoking decision."

  • Reported: DMN 1.3 — Fri, 19 Feb 2021 10:01 GMT
  • Updated: Tue, 23 Feb 2021 19:03 GMT

the operation of is() function is not well specified

  • Key: DMN14-140
  • 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: Tue, 23 Feb 2021 19:02 GMT

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

  • Key: DMN14-135
  • 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: Wed, 3 Feb 2021 15:40 GMT

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

  • Key: DMN14-134
  • 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: Wed, 3 Feb 2021 15:40 GMT

Allow for partial temporal values

  • Key: DMN14-132
  • 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: Tue, 26 Jan 2021 22:17 GMT

Change to the "at literal" in FEEL

  • Key: DMN14-131
  • 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: Tue, 26 Jan 2021 22:11 GMT

Adding a new interval built-in function

  • Key: DMN14-130
  • 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: Tue, 26 Jan 2021 22:03 GMT

Allow input data to be of type Interval

  • Key: DMN14-129
  • 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: Tue, 26 Jan 2021 20:58 GMT

Clarification on syntax of DMNReference


Incorrect typeRef for variables associated to BKMs

  • Key: DMN14-118
  • 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: Mon, 28 Dec 2020 18:15 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: 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: Fri, 10 Jul 2020 21:55 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: 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: 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: 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: Mon, 6 Jan 2020 20:44 GMT