DMN11 — XSD itemDefinition/typeRef and typeDefinition are underspecified and incorrect

itemDefinition is referenced to a base type defined by either a typeDefinition or typeRef. 7.3.2 says typeDefinition is "a String that defines the data structure", but it simply names a built-in type, does not define a structure. It also says typeRef is "a String that references a built-in data type... or a data structure defined at the top level in an external document", but those statements are incorrect as well. Built-in types are named by typeDefinition, typeRef is not String. Structured types are defined by itemComponent and referenced by typeRef, usually NOT in an external document. So this text is completely wrong. This issue also affects how external references are defined, via namespace prefix or filename, via ID or element name. Referenced typed by DMNElementReference are ambiguous and inadequate to cover the range of external references required.

simplify and correct MM and XSD for ItemDefinition

Proposal is to Merge and close DMN11-25, 56, 57, 71.

The latest MM diagram (attached) shows ItemDefinition containing itemComponents, which are also tItemDefinition. It also shows ItemDefinition has attribute typeRef and typeDefinition. It is better to have a consistent referencing scheme via typeRef, so typeDefinition should be removed from the MM. Otherwise, the MM is correct, but the XSD is not consistent with this.

The corrected XSD deletes tItemComponent and defines itemComponent as tItemDefinition. This makes ItemComponent recursive, which resolves and closes DMN11-56 and DMN11-71.

Also, to make ItemDefinition consistent with DMN11-67, allowedValue is renamed allowedValues, type tUnaryTests, maxOccurs=1.

It is important that types be referenced consistently via typeRef or itemDefinition, whether the type is:

(1) a base type (without restriction) in the ItemDefinition's typeLanguage; (2) a custom type (including base types with allowed values) defined in the current Definitions; (3) a custom type defined in an imported DMN model; or (4) a type defined in an imported XSD (or WSDL or other type language). Normally types have names unique in their namespace, and outside of DMN they do not have ids. Therefore tDMNElementReference, a pointer to id, will not work; the best way to reference types is by standard QName. This also resolves 11-25, since now Definitions/@namespace has a purpose.

A base type in the specified typeLanguage should not require ItemDefinition, nor should an imported type. ItemDefinition is required only for custom types defined in the current document.

QName is namespace-prefixed pointer to either ItemDefinition/@name (or, for imported XSD type, to xsd:simpleType/@name or xsd:complexType/@name). The prefix must be declared in DMN via xsd:schema/@xmlns:[prefix]="[namespace URI]". This means references to FEEL base types must use prefix for the FEEL namespace, just as references to XSD base types must use prefix for the XSD namespace. For imported DMN documents, the prefix must reference the Definitions/@namespace attribute of the import.