Only verify FEEL expressions; warn that others are currently unsupported

[pSub]

Currently, dmn-check only supports analysis of FEEL expressions. With this
commit the expression language that is specified in the DMN file is honored and
a warning is issued for all other expression languages.

Support for other expression languages is on the roadmap but with no schedule so
far. This feature makes dmn-check useable if other expression languages are
used in a DMN file, see issue #88.

Closes issue #83.

[codecov]

Codecov Report

Merging #98 (3bf6980) into master (4fc4d15) will increase coverage by 2.03%.
The diff coverage is 98.41%.

@@             Coverage Diff              @@
##             master      #98      +/-   ##
============================================
+ Coverage     84.88%   86.92%   +2.03%     
- Complexity      430      523      +93     
============================================
  Files            45       47       +2     
  Lines           900     1063     +163     
  Branches         46       55       +9     
============================================
+ Hits            764      924     +160     
- Misses          100      101       +1     
- Partials         36       38       +2     

Impacted Files	Coverage Δ
.../main/java/de/redsix/dmncheck/feel/FeelParser.java	99.11% <85.71%> (-0.89%)	⬇️
.../main/java/de/redsix/dmncheck/util/Expression.java	100.00% <100.00%> (ø)
...dsix/dmncheck/util/TopLevelExpressionLanguage.java	100.00% <100.00%> (ø)
...validators/ConnectedRequirementGraphValidator.java	92.04% <100.00%> (+4.11%)	⬆️
...x/dmncheck/validators/InputEntryTypeValidator.java	100.00% <100.00%> (+6.25%)	⬆️
.../dmncheck/validators/InputValuesTypeValidator.java	94.44% <100.00%> (+3.53%)	⬆️
...tors/ItemDefinitionAllowedValuesTypeValidator.java	97.14% <100.00%> (+0.98%)	⬆️
.../dmncheck/validators/OutputEntryTypeValidator.java	100.00% <100.00%> (+6.66%)	⬆️
...dmncheck/validators/OutputValuesTypeValidator.java	94.44% <100.00%> (+3.53%)	⬆️
...six/dmncheck/validators/ShadowedRuleValidator.java	88.09% <100.00%> (-0.80%)	⬇️
... and 10 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4fc4d15...3bf6980. Read the comment docs.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
11 Code Smells

98.2% Coverage
0.0% Duplication

[nairagit]

Hi @pSub,

Could you please provide an update if the validation is enabled for javascript as well or is there a plan for it?

Regards

[pSub]

Hi @nairagit, personally I haven't used JavaScript in DMN. I'll try to look into possible validations and create a ticket specifing what needs to be done to support basic JavaScript analysis.

Do you have any requirements on what should be validated / analyzed?

[nairagit]

hi @pSub ,

In the current dmn validator, if we have javascript in any of the columns in the DMN, the plugin errored out.
Then you updated the validator to provide warnings instead of errors.

The requirement is to validate the dmn even if it has javascript in any of the columns in the DMN

Please let me know if I need to open a separate ticket for this or it can be tracked here

[pSub]

Alright, I think I understand. If you have javascript all the way nearly every validation will back out with the warning that currently only FEEL is supported. That is not a helpful result.

The thing is, that javascript is much more expressive, which makes certain validations (that are implemented for FEEL) impossible or at least very hard. But I can think of some that would be helpful and not too hard to implement.

For example checking that the variables used in the javascript expression are bound by DMN Inputs. In this example the validation would check that the variables Mass and Height are indeed inputs to the literal expression.

An other thing that seems reasonable is to do static analysis of the javascript (eg. with https://github.com/cs-au-dk/TAJS or https://github.com/wala/WALA). I suspect this should be fairly straightforward as well.

Do those two validations sound helpful to you? Could you share a DMN file with a lot of javascript (either publicly or privately) so that I can see what a real world example looks like? As I said, I have no real experience with javascript inside DMN.

If those options sound good to you, please open a separate ticket in which we can document the requirements.

By the way: Thank you for using dmn-check and providing feeback! ❤️ 😍

For the sake of completeness: A validation that would certainly be hard to implement is the ShadowedRuleValidator. In this validation we have to check if the codomain (the range of values the expression potentially evaluates to) of an expression is included or equal to the codomain of an other expression. Solving this for javascript in general would lead to solving the halting problem (I think), which is impossible, so we would have to restrict ourselves to some non-touring complete subset of javascript for those validations. That is certainly doable, but sounds like a lot of work.