typeRef on Decision Services as FunctionItem

[StrayAlien]

hey @opatrascoiu. I hope you are well there. I see the UK is getting back under control. At least I hope so.

Regarding the PR for BKM typeRefs: #385. I would have thought this should also apply to decision services as both BKM and DSs have the same semantics and are both functions/invokables.

We have a test https://github.com/dmn-tck/tck/blob/master/TestCases/compliance-level-3/0082-feel-coercion/0082-feel-coercion.dmn#L410 which has variable with a typeRef: https://github.com/dmn-tck/tck/blob/master/TestCases/compliance-level-3/0082-feel-coercion/0082-feel-coercion.dmn#L13 that is a context type.

As a DS is a function should that be invalid? .. and it should be a FunctionItem?

If so, unlike a BKM there is no 'encapsulated logic' in a DS to type the result of the DS - it is FunctionItem on a variable typeRef or nothing.

So, IYO, do Decision Service typeRefs also only point to FunctionItems?

Comments welcome.

[opatrascoiu]

Hi @StrayAlien

Yes, DS are invocables just like BKMs, hence the typeRef have the same semantics.

[StrayAlien]

Thanks @opatrascoiu - I thought so. That test need fixing then. I'll do that.

Though, it does open another question and that is this:

If a DS has a typeRef (of a FunctionItem type) and the DS return value not match the DS typeRef return type, should the return value be coerced to null?

My feeling is yes, but always wise to consult ...

And also, it would seem the return type of the FunctionItem must be a context for DSs that have more than one output decision, and a must be a single value for those that return a single decision result (although, in theory, this could also be a context if that is what the single output decision returns)

Which also implies null coercsion when these two do not match.

Comments welcome.