Source: Oracle ( Gary Hallmark)
It is possible for a FEEL expression to generate a value with no possible datatype (as they are currently defined). Here are some examples:
1. If x>0 then x else ‘value must be greater than 0’
In the first case the result is either a string or a number. In the second case it is a list (collection) where the items are of different types. In the third case, which is more borderline, the collection items include a number and a list, again not the same type. The third case also relates, I believe, to
The rules for item definition, in combination with FEEL base types, do not support any of these cases. That means a variable with these values cannot have a typeRef. Some implementations may depend on the typeRef to compile the expression properly, and/or may prevalidate to ensure that a typeRef is provided.
I suggest one or more of these as possible solutions:
1. Allow item definition to include a union of existing types, e.g. number or string
2. Allow typeRef to be a list, e.g. feel:number, feel:string
3. Add new base type, anyAtomicType, meaning any of the FEEL base types.
Reported: DMN 1.1 — Thu, 3 Nov 2016 14:54 GMT
Disposition: Closed; No Change — DMN 1.3
We support homogeneous list types. Need better justification for heterogeneous list or union types.
DMN 1.2 adds type lattice, supports homogeneous list types like list<string>, promotes heterogeneous list types to list<Any>, which is good enough, unless more evidence to the contrary is presented.
Updated: Mon, 30 Mar 2020 19:50 GMT