Open StrayAlien opened 4 months ago
@StrayAlien I could see =10
as a range but !=10
is two ranges: <10 and >10
. The way you have it there (10..10)
can't return true and does not represent != 10
.
Hi @SimonRinguette ... exactly, and now we're seeing some of the weirdness of it. :-). Two ranges?
A little more here: https://github.com/dmn-tck/tck/issues/667
FEEL supports a compact syntax for a range of values, useful in decision table test cells and elsewhere. Ranges can be syntactically represented either: a) as a comparison operator and a single endpoint (grammar rule 7.a.) b) .. etc
If a range can be expressed as a "comparison operator and a single endpoint", then by implication a "comparison operator and a single endpoint" should be able to be expressed as a range?
@StrayAlien The paragraph that you mentioned talks about syntactic representation (e.g. one object in the AST that contains the operator and the endpoint). The same section contains also references at the end to several tables that describe the semantics of ranges: boolean lambdas.
What the spec does not say in examples is the values of range properties for the != range (e.g. start included
and start
).
I don't think it makes sense to evaluate (!=10).start
and(!=).end
and hence treat them as errors (e.g. return null).
Thanks @opatrascoiu - if that is the case - cool - we should get it into the spec - perhaps the !=
comparison operator makes no sense to be described as a range.
From discussion on the meeting: (!=10) should be raised as a ticket to DMN OMG, asking for clarification or modification to the spec.
@StrayAlien I suggest commenting out test range_012 until the matter is clarified by RTF.
The rest of the other tests look good to me.
Also good with the test cases excluding range_012
@StrayAlien could you please take a look, based on the last comments from Simon and Octavian?
I have changed the structure of the tests to make then less spread out. In effect, each range test asserts on a context of its property values. Keeps stuff together. All the previous test assertions are still here.
The values I am asserting on here are:
This is not covered in the spec, so, comments welcome.