The new text for type conversions in "10.3.2.9.4 Type conversions" misses some use cases

[StrayAlien]

The new text in 10.3.2.9.4 Type conversions is a welcome addition, but some situations are missed and left undefined in behaviour. There are a lot of places in a model that can explicitly define a typeRef. Having an explicit typeRef (IMO) has implications for implicit conversion. And it doesn't matter where it is ... everywhere that has a typeRef should be subject to the same implicit conversion as defined in this section - not just filters, invocations and DRG variables.

Here are just a few examples:

• An InputData has a typeRef of (say) string, but the actual provided input value is a number. It should be coerced to null.

• An InputData has a typeRef of (say) a collection of string, but the actual input value is just a simple string value. It should be coerced a singleton string list.

• A boxed list has two elements. Element 2's expression has a typeRef of string. The executing expression actually returns a number. It should coerced to null with list being [, null]

• A context entry has an expression with a typeRef of string. The actual expression returns a number. The value of the entry should become null.

That make sense?

I would add another element to the "There are several kinds of contexts in which conversions may occur:" section.

Something like:

"Any DMN element that may specify a typeRef may be subject to implicit conversion. If the explicitly-typed DMN element may have a value bound to it such as a DRGs element's variable, or an InputData's value then implicit conversion occurs on binding of the value. If the explicitly-typed DMN element provides a value, such as any boxed expression or Decision Service or BusinessKnowledgeModel, then its return value is subject to implicit conversion."

 <list>
     <literalExpression><text>"foo"</text></literalExpression>
     <literalExpression typeRef="number"><text>someFunctionThatReturnsString()</text></literalExpression>
 </list>

gives :

["foo", null]

.. or a BKM

<businessKnowledgeModel name="bkm_001" id="_bkm_001">
    <variable name="bkm_001"/>
    <encapsulatedLogic>
        <formalParameter name="arg1"/>
        <literalExpression typeRef="string">
            <text>someFunctionThatReturnsNumber(arg1)</text>
        </literalExpression>
    </encapsulatedLogic>
</businessKnowledgeModel>

should return null.

or ...

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

But the actual input data is ["foo"] .... it should be unboxed to a single value.

[baldimir]

From discussion on the meeting - This needs to be transformed into an RTF proposal. @StrayAlien, could you please write a complete list of things you thing needs to be updated in the section? Or is the current description complete? We could then work together on a proposal.

[StrayAlien]

Raised here: https://issues.omg.org/issues/lists/unclassified#issue-55153. @opatrascoiu - I hope that makes sense.

[falko]

This became https://issues.omg.org/browse/DMN17-71