DMN11 — XSD; modify tItemDefinition by changing tItemComponent

ItemDefinition defines the datatype of each variable used in DMN expression. As currently defined, it "works" for FEEL base types, although inefficiently (since it has both @name and typeDefinition, two strings that both name the type). It "sort of works" for imported XSD complex types, as long as you ensure the FEEL elements have valid XML element names (e.g. no spaces, etc.) In that case ItemDefinition/@name names the FEEL type and typeRef is a QName pointer to complexType defined in imported XSD. In the general case, for FEEL complex types defined inside the DMN model, it doesn't work very well.

It is clumsy for defining data structures more than 2 levels deep. ItemDefinition may contain a list of itemComponents, each with a name and pointer to another ItemDefinition. So to define a type that is 3 levels deep, you would have to define one or more 2-level ItemDefinitions, and then the top-level ItemDefinition would use those as itemComponents and point to their ItemDefinitions. Also, the current schema is missing cardinality information (in xsd, @minOccurs and @maxOccurs), important in the definition of a complex type:

I propose a change to tItemDefinition by changing tItemComponent. Child itemComponents are now contained in a parent itemComponent, not referenced, just like a complexType in XSD. I would like to make ItemDefinition/@name a required attribute, since it names the type, but am unable to do this without making it required for all tDMNElement. So the spec should just say, even though optional in schema, ItemDefinition/@name is required.

See attached doc with diagram. I will provide also revised dmn.xsd.

no longer relevant

no longer relevant