Errata for the 3rd Edition

In the print version, page 124, the following text is incorrect:

In FEEL’s context literal format, mentioned earlier, you can model an entry as a two-component structure. The first component is named key, always type text; its value is the name of the component. The second component is named value, type Any.  A table is a comma-separated list of context literals enclosed in square brackets:
[{key: “key1Name”, value: val1}, {key: “key2Name”, value: val2}]
This describes a context with two components, key1Name and key2Name, with values val1 and val2, respectively.

It should say (corrected in the e-book version)

In FEEL’s context literal format, mentioned earlier, you can model an entry as a two-component structure.  The first component is named key, always type text; its value is the name of the component.  The second component is named value, type Any:
{“key1Name”: val1, “key2Name”: val2}
This describes a context with two components, key1Name and key2Name, with values val1 and val2, respectively.

Errata for the 2nd Edition

Thanks to Matteo Mortari of Red Hat for the following, some of which are based on changes in DMN 1.3:

  • p123 says “Built-in function names are reserved words in FEEL; a variable name may not start with the name of a built-in function.”
    Matteo: “I don’t concur the DMN spec forbids naming a variable even using in full the same name of a built-in function, but by doing so the name would now refer to the variable, not the built-in function so while not forbidden, it should be avoided.”
    My comment: I always trust Matteo’s reading of the spec.  So let’s just say it’s best practice not to start a variable name with the name of a built-in function.  In my own models, I go even further, avoiding FEEL keywords like and, in, or for anywhere in a variable name, because they confuse the code completion editor in Trisotech.
  • p127 re regular expressions
    Matteo: “The rexegg.com site looks nice, but you might want to also suggest regexr.com or regex101.com for some hands-on interactive tutorial.”
  • p128 says “the exponentiation operator ** only works with integers, i.e. a**b is defined only for integer values of b.”
    Matteo: “DMN 1.3 dropped the constraint… and allows b to be any number.”
  • p153 re filter expressions, says “[Since] lenderName is a primary key… it is allowable to write 
    Loan Amount * Loan Table 30[lenderName = "AimLoan"].rate

    instead of

    Loan Amount * Loan Table 30[lenderName = "AimLoan"].rate[1]"

    Matteo: “In DMN 1.3 this is no longer possible, because the target expression is a generic multiplication, not subject to implicit conversion….  You are required to write in full

    Loan Amount * Loan Table 30[lenderName = "AimLoan"].rate[1]"

    My comment: Hmmm… yes.  A filter always returns a list, and filtering on a unique key returns a singleton list, which can be coerced (implicitly converted) to an item – i.e., omitting the [1] – in certain circumstances.  For example, in the expression

    Loan Table 30[lenderName = "AimLoan"].rate < 0.038

    it is ok to omit the [1], since the singleton list is being compared to a number.  Such a comparison operation allows implicit conversion, but multiplication, as he notes, does not.