Boxed Invocation - BKM only? Not using named-param invocation semantics?

[StrayAlien]

Hi all,

I noticed all usages of boxed Invocation in the TCK were a LiteralExpression naming a BKM. Fair enough - that is the most common use case so no stress there. But, I started to write some tests to exercise it a little more than that - using other expression types than a literal expression and other function types than a BKM. However, the spec section 7.3.6 Invocation metamodel is a little confusing - and I suspect written before lambdas and decision services entered the picture. It suggests the calledFunction is an expression which must return a function - all good. It says:

Most commonly, it is a LiteralExpression naming a BusinessKnowledgeModel.

So it seems it does not have to be a 'LiteralExpression naming a BusinessKnowledgeModel'. But then it goes on to say:

The calledFunction that is associated with the Invocation element SHALL be the encapsultedLogic of
the BusinessKnowledgeModel element that is required by the Decision element that contains the Invocation.
The Invocation element SHALL have exactly one binding for each parameter in the BusinessKnowledgeModel's encapsulatedLogic.

(side bar: encapsultedLogic ? - maybe nobody has visited this part of the spec for a while! ....)

But .. does that mandate that it MUST be a BKM, and furthermore, that all parameters shall be provided?

This is confusing as it denies that other function types, like decision services, or even built in functions can be invoked. Also, my take on an Invocation was that it is a boxed function call passing named arguments. The function invocation semantics for named arguments is that any un-supplied arguments are treated as null - for BKM, decision services and built-in functions. But .. this seems not to be the case for a boxed invocation. That is counter to this (though, I concede it is in the FEEL section):

10.3.2.13.5 Positional and named parameters
An invocation of any FEEL function (built-in, user-defined, or externally-defined) can use positional parameters or
named parameters. If positional, all parameters SHALL be supplied. If named, unsupplied parameters are bound to null.

So, looking for some clarification - the tests I have written permit any function (bkm/ds/lambda/funcdef/built-in) as the calledFunction and, as per function-invocation semantics, any unsupplied argument are considered null. But, the maybe spec seems counter to this. Unsure.

All comments and advice welcome.

[StrayAlien]

bump

[StrayAlien]

@tarilabs - I think drools does named-param semantics for invocation? Looking at compileInvocation it seems to not check:

The Invocation element SHALL have exactly one binding for each parameter in the BusinessKnowledgeModel's encapsulatedLogic.

And the actual evaluation looks to be named param semantics. It also seems not to care whether it is a BKM or not. I'm no expert on drools code though.

[tarilabs]

I think drools does named-param semantics for invocation?

If you are asking if Drools DMN Engine supports for FEEL function invocation to be "named parameters" in addition to "Positional [parameters]" eg: you can invoke abs( n: 10 ) in addition to the positional abs(10), then yes. The FEEL implementation inside Drools DMN Engine does indeed support both since it's a Conformance Level 3 implementation.

Looking at compileInvocation it seems to not check: [...] It also seems not to care whether it is a BKM or not. I'm no expert on drools code though.

I believe you might be confusing Conformance Levels across the DMN Specification.

Since Drools DMN Engine conforms to CL3, we SHALL (allcaps as in RFC 2119) comply with 10 (Expression language).
In Chapter 10, you can find 10.2.1.3 Boxed Invocation.
There, the DMN Specification states:

The boxed syntax maps to the textual syntax defined by grammar rules 38, 39, 40, 41. Boxed invocation uses named parameters.

So if you are in CL3 and you use a Boxed Invocation, you SHALL conform to this requirement.
In layman terms, a Boxed Invocation is just a visual way to represent a named parameter invocation, such as abs(n:10)

Further still in Chapter 10, you can find 10.3.2.13.5 Positional and named parameters.
There, the DMN Specification states:

An invocation of any FEEL function (built-in, user-defined, or externally-defined) can use positional parameters or named parameters. If positional, all parameters SHALL be supplied. If named, unsupplied parameters are bound to null.

Please notice the If named, unsupplied parameters are bound to null.
In layman terms, it means that in a CL3 if your FEEL function invocation is missing to supply a named parameter it will be bound to null, as I believe we did concur in the past also during TCK discussion we had this common understanding.

This should fully address your question which seemed to me a bit Drools-oddly-specific?
Since we do comply with CL3, our base reference is Chapter 10 for full FEEL semantics.

Beyond Drools, and in TCK terms.

It seems to me you might have identified a sentence in the spec which seems contradictory (eg: Chapter 10 gives a different set of semantics not fully compatible with those provided in Chapter 7).
I believe this could raise this to the OMG DMN RTF group, it's a good catch.
I believe while raising this, it could be worthy to specify we naturally lean towards the Chapter 10 (full) FEEL semantics, as a pragmatical proposal in the ticket.

In conclusion:

I don't think Boxed Invocation pertains to BKM only.
I believe the chapter you want to base as reference is 10.2.1.3 Boxed Invocation.
I am happy to support in raising the JIRA to the OMG DMN RTF group, per the discussion in the previous section, or you could raise it directly yourself; whichever you prefer.

Hope this helps,
MM

[StrayAlien]

Hi @tarilabs - thanks. Specifically I was referring to boxed invocation, not any FEEL function invocation - we have plenty of tests for FEEL invocations. One part of the spec says boxed invocation has named param semantics, another part says that all params for a boxed invocation SHALL be supplied - which is not FEEL named-param semantics. Plus the oddness re BKM. Hence the confusion.

My reason for peeking at drools code was to clarify whether drools boxed invocations followed FEEL named invocation semantics, or narrowed things to BKM only. It seems it is straight-up FEEL semantics - which you have clarified. Thanks.

I'll raise an issue re the spec contradiction.

Thanks again.

[tarilabs]

I can indeed confirm you Drools DMN Engine complying with Conformance Level 3 follows the semantics of

• 10.2.1.3 Boxed Invocation
• and 10.3.2.13.5 Positional and named parameters

as detailed in #497 (reply in thread) 👍

[StrayAlien]

closing