Debatable / incorrect test case CL3 / 0089-nested-inputdata-imports

[opatrascoiu]

I believe the test case below is incorrect - same variable associated to 'Person name' InputData is bound to two different values.

  <testCase id="001" invocableName="Evaluation DS" type="decision">
    <description>Nested imports of InputData following GITHUB DMN TCK 274</description>
    <inputNode name="Model B">
      <component name="modelA">
        <component name="Person name">
          <value xsi:type="xsd:string">B.A.John</value>
        </component>
      </component>
    </inputNode>
    <inputNode name="Model B2">
      <component name="modelA">
        <component name="Person name">
          <value xsi:type="xsd:string">B2.A.John2</value>
        </component>
      </component>
    </inputNode>

Here is my rationale based on what I found so far in Chapter 6 & 7.

1. InputDatas are uniquely identified by the namespace of the model in which they are defined and their name (unique in the model that defines it).
2. Each InputData has one one variable associated with (see metamodel and Chapter 7)
3. A variable is bound at runtime to a value.
4. When same InputData is imported multiple times, the definition & variable are resolved by navigating the models, starting from the root model and using the importNames. Hence the imports reference the same variable.

I am not aware of any PL or DSL that allows one variable to be bound to more than one value in the same runtime context. This is the rationale behind #ifdef macros in C/C++.

[StrayAlien]

hey @opatrascoiu - If I read you right, that implies there is one big global variable 'soup' that all imported models share, no matter how deep the imports tree goes. ? If so, not sure I agree.

By extension this would mean that decisions that are named the same though in separate imported models also would share the same variable?

The 'context entry namespacing' of the input data above is a means to isolate the data required by imported models, but not necessarily used by the importing model. It is 'pass through data' I guess.

If an importing model, and an imported model both have an input called 'amount' then assuming they both mean the same thing seems a little dangerous to me. Hence the 'context entry namespacing' of the input data in your snippet above.

In practical terms, when an importing model uses logic in an imported model, the execution of that imported model logic takes place in a fresh new scope, and if an input context exists in the importing model named the same as the imported model 'import name', then that context's data is passed into the new scope for execution. In that way, two 'amount' inputs are treated differently.

I think what you're saying is that, simply, you believe the import data for the new execution scope is populated by the input data values in the importing model by name .. no 'context entry namespacing'. And therefore, if an imported model needs an input called 'amount', and the importing model has an 'amount', then it should be passed in. Maybe .. (?).

Btw, the above stuff is by 'agreement' I believe between vendors, not really covered in the spec. #274.

[opatrascoiu]

AFAIK not all the vendors were part of the discussion. As usual, when the behaviour is not fully specified, it has to be discussed in the RTF. I raised an issue https://issues.omg.org/browse/INBOX-1171

[opatrascoiu]

The issue has been moved from inbox to https://issues.omg.org/browse/DMN14-161

[DanielP-Mat]

Hello together,
i started using DMN last year and found that issue because, i had the same question as @opatrascoiu. Because i have no user in the OMG Issue Board, i just wanted to ask, what is the current state for this discussion?

[baldimir]

Deferred to DMN 1.6 discussions in the OMG group.

[opatrascoiu]

Here are some updates after looking into the history:

1. The following was raised in DMN 1.5 https://issues.omg.org/browse/DMN15-58
2. It was discussed in several RTF meetings and the agreed proposal is here https://issues.omg.org/browse/DMN15-114 (see minutes of discussion)
3. Somehow the proposal did not go into the DMN 1.5 release and was transferred to DMN 1.6 https://issues.omg.org/browse/DMN16-50

I will comment on the DMN 1.6 to move forward on this.

[baldimir]

The OMG ticket https://issues.omg.org/browse/DMN16-50 got approved. We need to check the PR now.