1 + 123 / > 3 parsed as valid

[gustavomick]

1. title above is parsed as valid, confirming if this is valid.
2. also as and addendum to this, while testing alternatives i realized that "1 + 123 > 3" and its ok, but wondering if there should be a way to specify expected result type, so in case this is expecting number/arithmetic, this first > is marked as invalid.
   2b) (thinking out loud here) having an expected result type may be could have a extra benefit of make parsing grammar simpler

thanks!

[pragyandas]

The FEEL grammar for division or for that matter any Arithmetic Expression is specified in a generic way as : expression , "operator" , expression , and "Simple Positive Unary Test" is an expression, so technically "1 + 123 / > 3" is a valid FEEL expression even if it doesn't make any sense. I think some deliberation is required before we can invalidate this case.

[gustavomick]

ok, thanks for the insight.

if we can talk more about that here ..

considering dmn scope "to provide a common notation that is readily understandable by all business users"

i think any dmn/feel implementation must be above spec maturity, and tools cant wait for that maturity so needs to be fixed / evolved when spec definition / maturity its against usability or natural use.

considering dmn final goal is to be user friendly, i think having parser that works as user needs / expects is part of that goal and more important that spec itself.

For example this "1 + 123 / [ 0 .. 3 ]" you mentioned is valid but there is a real user / business context where this is valid? would user even understand that or this "1 + 123 / > 3"

Sorry for the long comment, finally, since there are, i guess, two different approaches here (be strictly aligned to dmn literal spec or be flexible in order to prioritize user) it would be very important if you can define js-feel library position on this matter.

well again thanks for your thoughts on that. great work!

[pragyandas]

@gustavomick I completely understand your concern. There are compromises in either of the mentioned approaches. As the library is not at a very mature state, we are trying to adhere to DMN 1.1 specs in a much stricter way to make most out of the specifications. I must also mention that we will be looking at expanding the library beyond DMN specs as business cases crop up eventually. In a way you can say that at the moment we are not that flexible to move beyond DMN specs but eventually to accommodate usability we will be making proper justified deviations.