Source: Montera Pty Ltd ( Greg McCreath)
Section 7.1 specifies that under certain circumstances relating to BKMs a decision must have a literal expression, and BKM parameter bindings relate to decision inputs. For example:
"If a decision element requires more than one business knowledge element, its value expression must be a literal expression that specifies how the business knowledge model elements are invoked and how their results are combined into the decision's outcome."
So, in essence dictating that if a decision uses more than 1 BKM its expression must be a literal expression. In practice, a decision may use its BKMs in various ways - to populate a boxed context entry, or even not to invoke it at all and (say) pass the BKM to another BKMN or function accepting as function type parameter.
This statement should be removed from the spec.
Next: "If a decision does not require any business knowledge models, its value expression must be a literal expression or decision table that specifies the entire decision logic for deriving the output from the inputs."
Again, whether a decision uses a BKM or not has no bearing on the type of expression a decision has. A decision with no BKM may have any expression including (say) a boxed context, or a list, or indeed may return a function definition - not just a literal expression or a decision table . The above text should be removed from the spec.
Next: "Similarly, if a decision element requires only one business knowledge model element, but the logic of the decision elaborates on the logic of its required business knowledge model, the decision element must have a literal expression that specifies how the business knowledge model's value expression is invoked, and how its result is elaborated to provide the decision's outcome."
The same - this text should be removed from the spec.
Next: "In all other cases (i.e., when a decision requires exactly one business knowledge model and does not elaborate the logic), the value expression of a decision element may be a value expression of type invocation. In a value expression of type invocation, only the bindings of the business knowledge model parameters to the decisions input data need be specified: the outcome of the decision is the result returned by the business knowledge model's value expression for the values passed to its parameters."
Again, this is unnecessarily limiting how a decision may use a BKM. For example, a decision may actually return the BKM as its value. The above text should be removed from the spec.
Additionally, the following should be removed:
"At the decision logic level, a decision invokes a required business knowledge model by evaluating the business knowledge model's value expression with the parameters bound to its own input value. How this may be achieved depends on how the decision logic is partitioned between the decision and business knowledge models:"
A decision does not have to bind its input values to a BKM parameters. As a decision may have (say) contexts that evaluate in a top down manner and the binding to a BKMs parameters could be any manner of calculations in that context or results of other BKM invocations that do not strictly relate to the inputs of a decision.
Reported: DMN 1.3 — Fri, 19 Feb 2021 10:01 GMT
Updated: Tue, 28 Mar 2023 17:39 GMT
DMN15 — spec places unrealistic constraints on decision expressions and BKM parameter bindings
- Key: DMN15-65
- OMG Task Force: Decision Model and Notation 1.5 RTF