Minutes of the meeting 2021-05-13

[tarilabs]

agenda ref #429 (comment)

Opening round

Decision Camp: invitation to participate in the call for paper AND the conference!
Reminder: 1 month to deadline for CFP
Thanks Jacob for the reminder

InputData.variable.typeRef required on TCK DMN model under test

Matteo, summarising the conversation from
#430 (comment)

Octavian: also the Metamodel (XSD) give typeRef optional, for interchange.
Also, thinking at the type checking for typeRef variables of Decision, which would be nullified if the computation is not conforming to the expected type.
For those engine that do inference, at least having for the inputs is important in order to have the type inference work for the rest of the model.

Greg: a gap in TCK that InputData are not asserted for the type, ref PR #422 (gives input incorrect data and asserts).

Octavian: if you specify a typeRef for the InputData at least you can leave the freedom to implementer if to check it statically or dynamically
Less of a discussion of compilerVsinterpreter, and more about semantic rules that we can apply over the Models.

(and other comments)

Conclusion

ref #430 (comment)

For DMN model under test the InputData nodes in the model SHALL specify typeRef

The InputData typeRef SHOULD be as precise as possible (if the test is supplying a number as an input, the InputData should be typeRef="number")

There might be cases where:

• the test should work generically on the supplied inputs (the specific input maybe a number or maybe a string)
• and there might be other cases where the intention of the test is to leverage the typecheck/conversion/coercion.

In this and similar cases, it would be better for the DMN models under test to specify the InputData nodes typeRef="Any".

Action point: make some extension to the current Validator to ask to specify for the TCK DMN Model under test the typeRef for the InputData.variable.typeRef (fine to be "Any" where needed)

DRG Name

Matteo: for interchange XSD is the reference, so a node name can be anything the XSD allows.
It is different story is for Conformance Level 3.
CL3 requires FEEL. Of course the spec allows to use additional expression language in a non-specified behaviour (eg: how it would work with JS is out of scope of the spec).
So an engine may decide to support additional expression languages, but you SHALL support FEEL (not S-FEEL) for CL3.
Then, every DRG in the scope (informationRequirement, knowledgeRequirement) must be resolvable as a FEEL symbol (to be able to use it in a FEEL expression).
...and deriving from that any DRG name hence must be a valid FEEL name (a valid FEEL name may contain spaces, emojis, etc. but for instance it cannot start with a digit, per the FEEL grammar).

Within the TCK group we clarified this understanding.

Actions

Agreed in the meeting Greg will merge

• Addess #430 StrayAlien/tck#3
• Addess #430 StrayAlien/tck#4

which will automatically reflect on the respective TCK PRs

Agreed in the meeting Matteo will proceed with the remainders from #429 (comment) :

• Address #430 in TestCases/compliance-level-3/0092-feel-lambda #436
  and the TCK PRs at the time of the meeting on:
• https://github.com/dmn-tck/tck/milestone/4

Agreed in the meeting Matteo will add a validator GitHub Action CI extension for the InputData.variable.typeRef

AOB

We agreed in the TCK workgroup being a community effort, to proceed with the previously stated intention of moderate speed but constant pace (e.g.: GitHub Milestone) in order to be sure to reach agreement on the semantic of the tests --which is NOT to say that all engine must pass the test, it is to say how the DMN model should behave accordingly to the spec is a common understanding, and if there are doubts we can as always raise the precise question to the DMN RTF (potentially with a proposal of solution too)