DMN 1.5 - feel 'in' additions for '=' and '!='. Plus ...

[StrayAlien]

uncommenting null endpoint ranges tests as per: #393 (comment).

The '=' and '!=' get exercised for each data type.

Those null range tests were commented out due to pre-1.5 ranges not permitting expressions as endpoints. They may or may not be correct in the light of the new changes.

It is not clear to me whether [null..10] is the same as <=10, or a null endpoint should now be treated as an error condition.

[opatrascoiu]

I believe some tests involving ranges with null endpoints do not follow the semantics of DMN 1.5. For example,

null_001_a: 5 in (null..10]

According to 10.3.2.7 Ranges the operational semantics is delegated to the semantics of existing relational and boolean operators:

The semantics of comparison expressions involving ranges (grammar rules 49c and 49d) is defined in Table 55, Table 54, Table 52, and Table 50.

According to these tables

5 in (null..10] <=> 5 > null and 5 <= 10 <=> null and true <=> null (3-value logic)

According to Table 55, condition 5 in (null..10] is not equivalent with 5 in <=10.

[StrayAlien]

I have to admit ... I am now really pretty confused at to how null in ranges and the 'unary comparison' style psuedo-ranges are supposed to behave. And what is equal to what, and what 'undefined' is. And whether attempting to get a value that is undefined actually should be an error .. and give null .. etc.

Like, we have tests in the equivalence suite asserting that (<= 10) = (null..10]. In 1.4, the start range of <=10 was null. Now it is 'undefined' .. whatever that is.

Raised: #663 .. to discuss.

[opatrascoiu]

@StrayAlien I checked the latest status of the PR. We are very close to merging :)

I believe the expected value for tests null_001_a and null_001_b should be null based on the rationale above: #668 (comment)

All the others look good to me.