Mapping between DMN and test XML about tck HOT 14 CLOSED

Detailed description of correspondence between DMN model and XML test file is given on a page:
https://github.com/dmn-tck/tck/wiki/How-to-Create-a-Simple-Test-Case
All further discussion in this issue will relate to content of this page.

from tck.

5 - input node name
Will it be correct to add the following?

Every "inputData" entry from DMN model must have exactly one equally named "inputNode" in every test case present in test file.

from tck.

Does DMN standard require that a name of "inputData" must be unique per each DMN model? Example: DMN file defines 10 decision tables. Every decision table has 10 inputs. Do we have a requirement that inputs are named differently for every table or globally? For instance, is it possible that any two tables have any equally named input?

from tck.

Some test cases have more complex structure:
https://github.com/dmn-tck/tck/tree/master/TestCases/compliance-level-3/0004-lending

		<inputNode name="ApplicantData">
			<component name="Monthly">
				<component name="Income">
					<value>6000</value>
				</component>
				<component name="Expenses">
					<value>2000</value>
				</component>
				<component name="Repayments">
					<value>0</value>
				</component>
			</component>
			<component name="Age">
				<value>35</value>
			</component>
			<component name="ExistingCustomer">
				<value>true</value>
			</component>
			<component name="MaritalStatus">
				<value>M</value>
			</component>
			<component name="EmploymentStatus">
				<value>EMPLOYED</value>
			</component>
		</inputNode>

How relevant tree of "component" nodes should be constructed from an arbitrary DMN file?

from tck.

How many inputs has DMN model? Should test XML describe a test of the whole DMN model or its parts? Example: DMN file defines 10 decision tables. One decision table has all but one its inputs as information requirements for outputs from 9 other decision tables and one external input variable. How many inputs will have a test for this model? 10? 91? 100?

from tck.

I am planning another page about compound (structured) values. However, the short story is that in the case that you reference above, the DMN model defines the structure of the data item that you must submit:

You will see, once again, that there is a one-to-one mapping between the input data structure, and the inputNode structure.

from tck.

As for how many inputs you need ... that is up to the model itself. The model might require some inputs, and then of course it will fail if you don't supply them. Others might be able to default values and therefor they work with or without inputs. The TCK framework does not enforce anything with this regard, it merely presents all the inputs specified, and then receives the results back, and compares to what is expected.

from tck.

Aha.. It clarifies to some extent.. So, we are getting the following schema:

Element "inputData" may have type reference in attribute "typeRef". If type reference is "itemDefinition", then every "itemComponent" found in "itemDefinition" becomes "component" of XML with tree structure exactly replicating tree of item definitions in DMN. Is it correct?

from tck.

That is it. Some of the elements may or may not be required -- that depends on the model itself whether it requires everything. Here is a better way to put it: it can't have anything different from the defined type structure.

It is the same with output as well.

from tck.

Thank you so much! Things become getting clear. It was only a set of questions on inputs. I will now inspect structure of outputs in similar way. Maybe more questions will appear. I would say, original blog looks exactly as it is named "simple" example. Full specification of test XML definitely requires more details as established here. But we are gradually approaching complete formal description.

from tck.

Please write a description of what is missing from the description on https://github.com/dmn-tck/tck/wiki/How-to-Create-a-Simple-Test-Case

Much appreciated.

from tck.

In my attempt to infer test XML structure from DMN appeared the following logic (possibly incomplete):

Determining inputs for decision tables:

1. Find all entries of tag "decisionTable"
2. For each decision table find all tags "input"
3. In each "input" find "label" and "inputExpression"
4. Evaluate "inputExpression" for "typeRef"
   a. If "typeRef" is found, we have a simple type input, which expects input value.
   b. If "typeRef" is NOT found, we have complex type, which requires replication on nested components in XML based on referenced type structure.
   c. If "typeRef" is basic FEEL type, pass value of proper type.
   d. If "typeRef" is complex type, find this type by searching "itemDefinition" tags for properly named type. Then parse this item definition recursively to reconstruct nesting levels of components from it.

from tck.

Determining inputs for information requirements

1. Find all entries of tag "informationRequirement"
2. In each "informationRequirement" find tag "requiredInput"
3. Use value of tag "href" in "requiredInput" as the name of input reference
4. Search over all tags "inputData" in the model for one with "id" equal to input reference
5. Inside "inputData" find tag "variable" and get its attribute "typeRef"
6. Search over all tags "itemDefinition" for one with nested tag "name" equal to type reference (5)
7. If found item definition contains "itemComponent", process it recursively as described for nested component inputs in decision tables.
8. If not found , check for tag "variable" inside and interpret it as simple type same as in inputs in decision tables.

from tck.

I created a new wiki page with this information:

https://github.com/dmn-tck/tck/wiki/Test-Case-Generation-Strategy-Details

from tck.