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

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

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

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

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

• example: inputData typeRef

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

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

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

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

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

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

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

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

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

• example: a typed context entry:

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

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

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

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

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

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

• example: An BKM typeRef defines an outputTypeRef.

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

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

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

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

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

• Where should conversion occur?

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

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

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

The spec model defines typeRefs for the following:

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

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

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

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

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

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

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

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

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

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

• 8.3.2 Decision Table Input and Output metamodel. "A RuleAnnotationClause SHALL have a name." The models have a number of decision table rule annotations that do not have names and are simply `<semantic:annotation/>`. Names are required. I suggest removing the annotations on all models.

• typeRef on EncapsulatedLogic and invokables may only be a function type. The chapter 11 models have primitives as typeRefs (as well as "Any" in financial.dmn) on a number of BKM encapsulated logic expressions and variables.

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

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

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

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

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

```

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

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

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

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

Examples:

date("2023-02-29") 
// expected: null (2023 is not a leap year)

date("2023-06-31")
// expected: null (June has only 30 days)

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

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

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

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

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

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

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

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

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

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

• DMN 1.1 had to legitimately change the namespace because the XML serialization from DMN 1.0 was unimplementable and required breaking changes
• DMN 1.2 had to change the namespace because the one from DMN 1.1 did not conform to OMG's policy (due to last-minute bad advice from the technical director at the time)
• DMN 1.3 jumped on that to abuse it as a version indicator
• DMN 1.4 and DMN 1.5 followed to be "consistent with the scheme"

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

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

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

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

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

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

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

The issue was discovered in TCK when testing function invocations.

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

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

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

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

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

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

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

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

Possible solution:

• deprecate the attributes (e.g. DMNElement.label)
• add a constraint (e.g. DRGElement.name == DRGElement.variable.name)