I do not understand the following aspect about collections: Assume the input data node is a collection, but the decision is NOT a collection. From my understanding, the individual values of the input collection are passed iteratively to the decision. As the latter is NOT a collection in the example, it is my understanding there should be some form of aggregation(?).

I can understand how this should work for numerical values (e.g. "aggregate" by sum) however I am not clear of the aggregation method (is it always sum?). Furthermore, how should aggregation work if the output column of the decision contains strings?

Example: Two rules: "a"->"b", "c"->"d". Then an input collection {"a","c"} is passed. So the two outputs are "b", "d". As the decision is NOT a collection, we should not yield something like {"b","d"}, but should aggregate(?), yet, as stated, how to aggregate b,d?

There are many different Functions that are needed to make FEEL expressive enough for tackle the logic of various contexts/industries:
e.g Financial Functions, Healthcare Functions, etc. even advanced Mathematical functions or Matrix manipulation functions.

Currently these functions need to be imported in, and then all functions need to be prefixed with a namespace.
This not ideal as the business friendly name with space such as "annual interest rate" now becomes cryptic as "financial.annual interest rate"
or "discount as percentage" becomes "financial.discount as percentage"

Currently if a DMN model makes use of an external library of functions, the receiving tool may be challenged in also importing this library and execute on these new functions.

We should explore a way to make the interchanged model not only exchangeable but also executable.