[incubator-kie-issues#1742] DMN: B-FEEL implementation

[gitgabrio]

Fixes apache/incubator-kie-issues#1742

The B-FEEL proposal simply define a list of "default" values to return when the standard FEEL would return null

This PR:

1. create the FEELDialect enum to define different feel dialects, for the moment being the "standard" one and the B-FEEL one
2. populate the evaluation context with the current feel dialect
3. define Object defaultValue() and List emendedList(List toEmend) inside FEELFunction, to be override on specifc needs by concrete implementation
4. returns the result of the above methods in when the original result is null and the dialect is B-FEEL
5. add a specific BFEELTest to verify the cases listed in the B-FEEL proposal

The PR touched lot of files due to the pervasiveness of the logic, but the design itself seems clear, at least to me.

@AthiraHari77 @bncriju

How to replicate CI configuration locally?

Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.

build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.

How to retest this PR or trigger a specific build:

• for pull request and downstream checks

  • Push a new commit to the PR. An empty commit would be enough.

• for a full downstream build

  • for github actions job: add the label run_fdb

• for Jenkins PR check only

  • If you are an ASF committer for KIE podling, login to Jenkins (https://ci-builds.apache.org/job/KIE/job/drools/), go to the specific PR job, and click on Build Now button.

[jomarko]

Thank you for the PR @gitgabrio , especially for massive test coverage. I put some comments inline, some of them just for my better understanding.

Formatting

One general observation is about formatting changes, that I ma not sure are expected as part of this PR:

• on some places we add `

  tag into Apache license header, while some licenses do not contain it

• on some places we split long string into concatenation, however not sure why it seems in codebase we have lines that are longer than places I have in mind, so not sure, is there some line length limit for the drools repository?

FEELDialect.java

Do I understand correctly that B-FEEL is always represented by single value "https://www.omg.org/spec/DMN/20240513/B-FEEL/" while FEEL can be represented by multiple values, depending on the DMN version? My guess would be also for B-FEEL may appear more values/version in future? If that is true maybe the FEELDialect could be somehow refactored? Not saying this is somehow blocking from merge, just wanted to hear your opinion.

[gitgabrio]

@jomarko
thanks for the carefull check of this PR!
About formatting, my bad, sorry.

About BFEEL multiple definitions, I also share some doubts, TBH.
The proposal doc does not mention any other possible identifier and syasy that the scope of BFEEL is only to manage the null values (without any reference to a specific FEEL version)

B-FEEL shares the same grammar as FEEL but alters the semantics to be friendlier and more intuitive toward non-IT users.
In FEEL, the null value is used to both represent missing data or an execution error. In B-FEEL, null is used only to represent missing data. All operations and built-in functions that returns null in FEEL when an error occurs have their semantics modified in B-FEEL to return a non-null value. A warning message should still be produced when an error occurs.

So, my interpretation is that, regardless of the FEEL expression language used, whenever the "standard" version would return null, having defined the BFEEL dialect should replace it with "default" values.

[jomarko]

Thank you for the PR @gitgabrio. I have one more question about the package org.kie.dmn.feel.runtime.functions tests. There we basically have tests for evaluation of expressions for each DMN built in function - using FEEL dialect. We do not use B-FEEL dialect there is that correct? And we are safe to keep it as it, because B-FEEL affect evaluation only for small amount of cases? For example when function is invoked with some invalid argument, then returned default value is different in FEEL vs B-FEEL and these default values we test in BFEELValueFunctionTest ? Is my understanding correct?

[jomarko]

Thank you for updates

[yesamer]

Thank you @gitgabrio, please consider my comments: