DMN12 — Problem with QName usage in typeRef

typeRef is a QName which has 2 parts, an optional namespace and a local name.
In XML local name is typed as an xsd:NCName and thus cannot have spaces in it.

In the CH11 example of the spec,
There is a serialization error that lead to confusion about Qname…
ex: line 447 there is a formal parameter with a typeRef to "ex:RiskCategory" but its definition at line 84 is:
<itemDefinition name="Risk Category" id="riskCategory_t">
RiskCategory does not reference neither name nor id (name has a space and id is wrong).

The idea of using prefix:name as QName for typeRef in DMN is problematic as name(s) may contain spaces.

It is recommended to use prefix:id as QName and specify this clearly in the spec so we do not run into the spaces in names problem.

typeRefs and ItemDefinition names are FEEL qualified names

In order that typeRef may reference an itemDefinition as prefixed name, as specified in 7.3.2 paragraph 9 and Table 23, the name of an itemDefinition must be a valid XML NCName, as opposed to the less stringent requirements for other NamedElements. That means it may not contain spaces and other characters used in “business-friendly” names. This is implied but not clearly stated in the spec text.

Abstract
• While this issue singles out typeRef, our proposal provides a common basis for representing both imported item definitions and variables (e.g., BKMs).
• Use name not id to reference item definitions (in typeRef) and variables (in FEEL expressions). Use of id-based references should be limited to DRG elements such as in information requirements or DI.
• To the import element, add the new attribute name, a business-friendly, easily remembered string used as a proxy for the namespace value. The name need be unique only in the importing model, not globally.
• Limit reference of target namespace (definitions/@namespace) to models that import other models. In DMN models without import, the target namespace must be declared but is never used in expressions or typeRef.
• For models that do not import other models, typeRef is just the item definition name or FEEL base type name; there is no change to FEEL expressions. For models that do import, both typeRef and FEEL variable references are [import element name].[local-name]. In DMN1.1 imported variables are referenced as [namespace value].[local-name]. Namespace values are typically URLs containing colon, which is disallowed in FEEL qualified names.

Justification
• Names are modeler-entered values, so they should be business-friendly and easily remembered. ids are tool-generated values, typically globally unique, not business-friendly, and not easily remembered. If typeRef is based on id, tool asks modeler to select item definition based on name but then uses id in the XML. This is OK, since modeler does not see the XML. But the same cannot be said for FEEL expressions referencing imported names, such as a BKM.
• Namespace prefixes in QNames are complicated, since the global declaration in definitions may be overridden locally within the model, so the prefix in effect depends on local scope. Import name is declared once in the importing model.
• Simpler is always better. This is much simpler.

Argument for backward compatibility
DMN 1.1 says that typeRefs are strings with the syntax of an XML QName.
DMN 1.2 says that typeRefs are strings with the syntax of a FEEL qualified name. Because QNames can contain the colon character but FEEL names cannot, isn't this a problem?
Not Really. QNames with a colon character are qualified using a namespace prefix, but in DMN 1.1, there is no standard way to define a namespace prefix for an imported type. DMN 1.2 adds the 'name' attribute to the 'Import' class to fix this problem. In DMN 1.1, only non-qualified typeRefs are specified well enough to work, and these will also work in DMN 1.2.