Confused about decision service encapsulatedDecisions - ambiguous - is ch11 example correct? about tck HOT 5 CLOSED

Glad to help 🚀 👍

If you think there could be an additional paragraph which would clarify, if needed, in the spec, I believe is worthy to raise a ticket once others have also replied, so you could have the broadest picture.
I suggest adding (if needed) only a new paragraph, as changing terminology or the metamodel would be too difficult at this point.

from tck.

Hi @StrayAlien fwiw I've always intended to be disjoint.

I believe the confusion might be the conflation of the term "encapsulated decisions" used to describe what is ~captured by the decision service boundary, and the encapsulatedDecisions which is actually a metamodel attribute.

btw the spec also says:

The requirement subgraph of a DecisionService element is the directed graph composed of the DecisionService element itself and the union of the requirement subgraphs of all the Decision elements that are referenced by its encapsulatedDecisions and outputDecisions.

If they were not disjoint, it would have sufficed to say encaspulatedDecisions (without mentioning outputDecisions).

Hope this helps

from tck.

hey @tarilabs - nice to hear from you. I hope you're doing well there. Phew, okay. Yes, I think that bit nails it. Thank you.

Yes, the term 'encapsulated' suggests the decision service (shape) boundary enclosing things. I have to say, I must have read it all 30 times and still came away wondering. The 'union' thing says it.

Thanks again.

I'll leave this open for a few days for others to read.

from tck.

@StrayAlien We should probably raise an issues, discuss it in the RTF and clarify the spec. The main questions is: are the sets disjoint or not.

From the execution point of view only the inputs and outputs are needed, the other sets of decisions can be inferred.

from tck.

Thanks @opatrascoiu, @tarilabs quoted reference looks pretty concrete. According to that, they are disjoint, but certainly the use of 'encapsulated' is misleading. Especially with regards with the decisions 'encapsulated' within the decision service diagram overlay.

I guess maybe, again as suggest by tarilabs, we could consider some wording to assist in understanding the relationship between the DS arrays.

Agree, only the inputs and outputs are needed for execution, but, from a UI perspective, a full understanding of what-goes-where is needed to create a valid model.

from tck.