DMN - Check RangeFunction usage

[yesamer]

During #5 implementation, it appeared that some "range" expressions are not parsed by the RangeFunction class, with unexpected/inconsistent results. Some of them:

[..<2] or [<2] can't be parsed by RangeFunction.invoke() (>1) translates to (1..null) but does not goes through RangeFunction.invoke() both (<1) and (<=1) translates to (null..1)

For the latter two cases, it seems that the engine does some other evaluation elsewhere and keeps reference of the actual endpoints in a different object; it may also be possible that some cases are not test-covered. Those cases are present inside FeelRangesTest

Editor Impact

The DMN Modeler supports constraints for custom data types. It has three dedicated components for modeling:

• Range constraints
• Enum constraints
• Free-form constraints

The issue I see is that the Range component, doesn't allow the user to create sth like [..<2], the user needs to use the Free form component. Is that acceptable?

This needs to be check against definition of the range function in DMN 1.5 https://www.omg.org/spec/DMN/1.5/Beta1/PDF - Table 72: Semantics of conversion functions. RangeFunction is a class representing string conversion function mentioned in the linked Table from the DMN spec. It doesn't mean it can handle all range expressions. It is only a conversion function from a string type to range representation. However this needs to be still investigated, if the behaviour is 100% per specification as this string coversion function is a new feature defined in DMN 1.5.

[gitgabrio]

@yesamer @baldimir It seems there are two kinds of different implications. I did not thought about the editor itself, but it is another the consequence of an "inconsistency" inside the engine implementation (if my findings/doubts are correct).

[gitgabrio]

Range string

66. range literal = a. ( open range start | closed range start ) , range endpoint , ".." , range endpoint ( open range end | closed range end ) | b. open range start , ".." , range endpoint ( open range end | closed range end ) | c. ( open range start | closed range start ) , range endpoint , ".." , open range end ;
67. range endpoint = numeric literal | string literal | date time literal ;

The current implementation fullfill the specification. That funciont must not be confused with "10.3.2.7 Ranges", that are differents