Clarify FEEL `null` handling in `FilterExpression` about tck HOT 4 CLOSED

I brought this issue up in the DMN 1.5 RTF meeting today. We looked together into the specification and agreed that it's sufficiently specified. On page 109, one can read:

The filter expression is evaluated for each item in list, and a list containing only items where the filter expression is true is returned. E.g:
[ {x:1, y:2}, {x:null, y:3} ][x < 2] = [{x:1, y:2}]

So for the third element, the evaluated filter is:

{ b: 1 }.a < 3

// which is equal to
null < 3

// which results in
null

As null != true, the filter expression should drop the item.

As a follow-up, we should create a PR with a test case which ensures the behavior above between the implementations.

from tck.

Thanks for clarifying @barmac.

I can see if I can add a TCK test case to cover two topics that you mention:

// access of undefined members in a Context
{ x: 1 }.y = null

// filtering of lists on undefined members
[ { x: 1 } ][y > 1] = []

[ { x: 1 }, { y: 2 } ][y > 1] = [ { y: 2 } ]

from tck.

Before adding new tests please check if the existing ones do not cover your use case.

from tck.

Writing test cases for this you could argue that the spec is "underspecified", because each of the provided list member contexts have actual members with the given name.

#540 attempts to create test cases for all cases covered by the spec (10.3.2.5 Lists and filters), and also adds cases discussed in this issue (non-member access).

At the same time #541 asserts the behavior of non-member context access.

from tck.