Expected behavior for list built-in functions in combination with singleton lists? about tck HOT 21 CLOSED

Chapter 10.3.1.4 in the spec on page 110: "A singleton list is equal to its single item, i.e., [e] = e for all FEEL expressions e."

from tck.

@opatrascoiu @agilepro @etirelli @falko

Any thoughts / opinions / emotions on this?
From my point of view: If DMN/FEEL implementors do not agree on a consistent behavior for this, cross-runtime compatibility is theoretical for DMN. This is a crucial behavior to discuss.
The specification would allow both results - with potentially drastical impact on model behavior.

from tck.

from tck.

I agree with @arthware, that unless the semantics for this is clearly defined, it breaks interoperability between products.

Unfortunately I don't think there is a "solution" for this in DMN 1.1, because the "[a] = a" makes the whole semantics completely ambiguous.

There is also, to my knowledge, no proposal yet to fix this for DMN 1.2. So the only solution would be for us to make a proposal of what the semantics should be.

This might actually become worse in DMN 1.2 because there is a proposal to support heterogenous lists in DMN 1.2, while DMN 1.1 if I remember correctly only supports homogeneous lists.

So, I believe we could focus here on a proposal to submit for DMN 1.2, as the discussion of any function in particular would be a moot point. In particular, I believe the solution would be to constrain the "[a] = a" coercion to only the actual places where it would be applicable/safe.

from tck.

Some FEEL puzzles:

• insert before(distinct values(["a", ["a"],[]])[1],1,["a"])
• count(insert before(distinct values(["a", ["a"],[]]),1,["a"]))
• count(append(distinct values(["a", [["a"]]]),[["a"],"a"]))

@brsilver
The result type is relevant if results of list functions are nested. Therefore, allowing all 3 results in the first example could end up in different runtime behaviors once invocation results are nested (I believe).

The count([[“a”]])=1 example was wrong in the original post. We meant count([[]])

from tck.

from tck.

@arthware yeah, there are plenty of problems like the ones you mentioned. There is no answer in DMN 1.1.

Would you like to try and come up with a proposal for DMN 1.2? I can help get it through the RTF process.

from tck.

@brsilver @etirelli

I have created a new ticket at the OMG with a proposal for DMN 1.2. It is not a change of the spec, but a clarification of the expected behavior. If the OMG solution for DMN 1.2 is compatible with 1.1 we can choose this way in DMN TCK, too (unless 1.2 is released).

(http://issues.omg.org/browse/INBOX-556)

from tck.

from tck.

@DanielThanner thank you! as soon as the issue pass the triage, we can bring it up on the RTF meeting.

from tck.

@brsilver
The specification says for filters: "... and a list containing only items where the filter expression is true is returned.". This means a filter always returns a list. In case only a single element is returned, it is inside a list, a singleton list.

You can use [1] to access the first element. But I don't think that this is necessary, because the spec says that "e = [e] for all FEEL expressions e". Therefore, if you are sure that the filter matches a single element, you will get a singleton list as result. You can pass the result of the filter to any FEEL expression. It doesn't makes a difference if you work with the singleton list [e] or the singleton e itself (some exceptions for built-in functions list contains(), index of() and count()).

from tck.

from tck.

@brsilver just to clarify, what I said is that the conversion sometimes is ambiguous, specially when you compose a filter into another filter or as a parameter to a function, very similar to the examples raised by @DanielThanner and @arthware .

For instance:

append( someList, MyTable[id=”abc”].x )

Lets say the filter in the example above returns ["foo"] . Are you appending ["foo"] to someList or are you appending "foo" ?

What if, because of a problem in the MyTable data, the result for x is ["foo","bar"], but someList is a list of Strings. Now it is an invalid list and in the best case raises an error at runtime. Worst case, silently fails.

from tck.

from tck.

For the filter topic there is already a JIRA issue at OMG: http://issues.omg.org/browse/DMN12-115

The text in the spec does not match the FEEL example in the spec.

from tck.

from tck.

At Camunda we agree with Edson and would like to limit the rule or clearly define when it applies. Ideally, we would like to remove the rule to prevent ambiguities completely. But that is probably not up for debate.

from tck.

@etirelli Can you please add example(s) of nested filters that have problems with singleton lists?

from tck.

Reminder RTF ticket is http://issues.omg.org/browse/DMN12-115

from tck.

Linking the ticket with the proposal: https://issues.omg.org/browse/DMN12-210

from tck.

Approved by RTF. Nothing we can do in short term. When this gets implemented, we might run into problems that need addressing. We probably will need a set of tests on this.

from tck.