DMN 1.4 - 1145-feel-context-function

[StrayAlien]

No description provided.

[opatrascoiu]

@StrayAlien Thank you again!

I would use xsd:decimal instead of xsd:double in the test files xsd:decimal as is a better mapping for the number type in FEEL.

I think we should add extra tests to check the type of the value returned by context(). For example:

    <itemDefinition name="exactContextType" label="ExactContextType" id="_exactContextType">
        <itemComponent name="a" id="_a">
            <typeRef>number</typeRef>
        </itemComponent>
        <itemComponent name="b" id="_b">
            <typeRef>number</typeRef>
        </itemComponent>
    </itemDefinition>

    <itemDefinition name="superContextType" label="SuperContextType" id="_superContextType">
        <itemComponent name="a" id="_a">
            <typeRef>number</typeRef>
        </itemComponent>
    </itemDefinition>

    <itemDefinition name="otherContextType" label="OtherContextType" id="_otherContextType">
        <itemComponent name="a" id="_a">
            <typeRef>number</typeRef>
        </itemComponent>
        <itemComponent name="b" id="_b">
            <typeRef>number</typeRef>
        </itemComponent>
        <itemComponent name="c" id="_c">
            <typeRef>number</typeRef>
        </itemComponent>
    </itemDefinition>

    <decision name="decision018" id="_decision018">
        <variable name="decision018" typeRef="exactContextType"/>
        <literalExpression>
            <text>context(entries: [{key:"a", value:1}, {key:"b", value:2}])</text>
        </literalExpression>
    </decision>

    <decision name="decision019" id="_decision019">
        <variable name="decision019" typeRef="superContextType"/>
        <literalExpression>
            <text>context(entries: [{key:"a", value:1}, {key:"b", value:2}])</text>
        </literalExpression>
    </decision>

    <decision name="decision020" id="_decision020">
        <variable name="decision020" typeRef="otherContextType"/>
        <literalExpression>
            <text>context(entries: [{key:"a", value:1}, {key:"b", value:2}])</text>
        </literalExpression>
    </decision>

with expected results:

    <testCase id="018">
        <description>Value of context() equivalentTo the decision typeRef</description>
        <resultNode name="decision018" type="decision">
                <expected>
                    <component name="a">
                        <value xsi:type="xsd:decimal">1</value>
                    </component>
                    <component name="b">
                        <value xsi:type="xsd:decimal">2</value>
                    </component>
                </expected>
        </resultNode>
    </testCase>

    <testCase id="019">
        <description>Value of context() conformsTo the decision typeRef</description>
        <resultNode name="decision019" type="decision">
                <expected>
                    <component name="a">
                        <value xsi:type="xsd:decimal">1</value>
                    </component>
                    <component name="b">
                        <value xsi:type="xsd:decimal">2</value>
                    </component>
                </expected>
        </resultNode>
    </testCase>

    <testCase id="020">
        <description>Value of context() does not conformsTo the decision typeRef</description>
        <resultNode name="decision020" type="decision">
                <expected>
                    <value xsi:nil="true"/>
                </expected>
        </resultNode>
    </testCase>

We should probably discuss the expected values, value produces by context() or coversion to expected type ( e.g. add only members in super type) :)

[StrayAlien]

thanks @opatrascoiu - re 'double' oh yes, for sure. Apologies - that is an oversight. Good pickup. I'll amend.

Re the type checking - the context() function is not intrinsically typed, and we do have other tests for checking on context types, so my feeling here was just to prove it creates the desired contexts and leave the type checking to those other tests. Happy to discuss.

[StrayAlien]

doubles change to decimal on this PR, and the others with the same thing. Thanks again - nice pickup @opatrascoiu .

[StrayAlien]

Also, I see the TCK validation fails with Cannot find the declaration of element 'definitions'. .. not sure what is going on there ...

[opatrascoiu]

@StrayAlien
I believe the context() functions are typed - just like all the other builtin functions. The tests in this PR cover only the inputs. We need tests to cover the outputs as well for integration with other parts of the model.

These functions are new, we need to add these tests either here, in this file, or somewhere else to have the coverage.

Is there an existing test case that you have in mind that can be enhanced ? Adding the tests here will align us with the localization principle.

[StrayAlien]

Hi @opatrascoiu , thanks. The examples provided show type constraints at the decision/variable level, but (IMO) that is unrelated to asserting results of context function itself. The context() function just produces a context object based on inputs, so we can simply assert that it produces the output context we expect based on the inputs provided. No types are necessary to prove that context() is working as expected IMO. Types are orthogonal.

The test are asserting on an exact outcome. So, testing for the type of the outcome gains no value. If the exact expected outcome is not delivered then the type is moot.

I think we already have context types covered at the decision/variable level. Likely, also in the as-yet-ummerged PR for domain constraints. I'll have a dig to see if we have. If not, we can add context type checking to some type-specific tests (again, IMO).

[opatrascoiu]

@StrayAlien I am inclined to agree with you about the location. A good place is to have them in 0082-feel-coersion. Comments, thoughts?

Once we agree on the location, I'll create a PR.

[StrayAlien]

Apols for late reply @opatrascoiu - we dp have a few tests fr context types here: https://github.com/dmn-tck/tck/blob/master/TestCases/compliance-level-3/0070-feel-instance-of/0070-feel-instance-of-test-01.xml#L1207. And there are also some more in the 'allow values' PR, butm yes, we're a bit light - expecially around whern they're associated with a decision variable I think.

Let's discuss tonight at the DMN meeting.

[SimonRinguette]

I would argue that the test case 003 would not return null but the intention was to return only {a: 2}.

We can discuss that one!

[opatrascoiu]

According to 10.3.2.6 Context,

In the syntax, keys can be either names or strings. Keys are mapped to strings in the semantic domain.These strings are distinct within a context.

Based on this I think the test is correct.

[SimonRinguette]

@opatrascoiu All right, make sense to keep the test then.