DMNFTF — boxed function examples lack mandatory parameter lists

According to alpha version section 9.2.1.7, a boxed function (decision logic for a BKM) must have a parameters box and a body box.
Figure 8 is misleading or wrong, the boxed expression for Business knowledge 1 should be a boxed function (have a parameters box and body box instead of 'value expression' box.
All these examples - Figures 59, 61, 63, 65, 67, 69, 71, 74, 75, 77, need a parameters box beneath the name box. That is because these examples must be boxed functions, because they are invoked by the boxed invocations in Figures 58, 60, etc.

The consistency of the invocation logic, e.g. Figures 58, 60, etc. may be misleading. The actual parameters and formal parameters just happen to always be the same identifier. This is not required, and in fact is why it is important to list the formal parameters in the boxed function, so that the actual parameters can be substituted properly. For example, valid alternatives to Figure 66 include the following expression text in a box:

Application risk score model (Applicant Data . Age, Applicant Data . Marital Status, Applicant Data . Employment Status)

or the following:

Application risk score model (Marital Status: Applicant Data . Marital Status, Employment Status: Applicant Data . Employment Status, Age: Applicant Data . Age)

Note that Figures 74 and 77 desperately need parameter lists in order to know how to match actuals to formals in invocations.

One last example - a decision table dt1 with input x-y and some rules. There would be at least 2 ways to invoke dt1. E.g. dt1(x: 1, y: 2) and dt1(x-y: -1).The different invocations would result in different parses of the target function. In the first, x-y is a subtraction whereas in the second, x-y is a name. To avoid this problem,
you need a context, independent from any invocation, to indicate whether x-y is a name, or whether x and y are the names. Explicit parameter names attached to the boxed function definition provides such a context. Thus, the decision table needs to be the body in a boxed function definition, which is to say, there needs to be both the DT and the parameter list. The parameter list is a box containing (x,y) or (x-y). These are the parameters for all invocations.

Allow decision table notation to serve as a boxed function, i.e., not require parameter lists, if the input expressions are simple and can be interpreted as parameter names.