DMN11 — DMN needs to provide a standard way for vendors to serialize extensions (Vendor Extensions)

DMN nees to provide a standard way for vendors to serialize extensions (Vendor Extensions). It is proposed that a schema resembling what was done in BPMN and CMMN be used.

Why DMN should be extensible

The extension mechanism allows adding Custom Metadata to models in a way that it MAY be interchanged between vendors. Concretely this means that it is possible to add custom attributes and elements in a custom namespace to the XML interchange format.

Example of a custom attribute

<DecisionTable id="table1" custom:audit="true" xmlns:custom="http://custom.org/auditing" ...>

Example of a custom element

<DecisionTable id="table1" ...>
  ...
  <extensionElements>
  <custom:audit xmlns:custom="http://custom.org/auditing">
    <custom:audit-level>full</custom:audit-level>
    <custom:retention>unlimited</custom:retention-level>
  </custom:audit>
  </extensionElements>
  ...
</DecisionTable ...>

Vendors need to be able to add custom Metadata

Vendors need to be able to decorate the model with additional metadata. Vendors may implement additional usecases which the standard as such does not address like historization, reporting, fine-grained editing authorizations amd restrictions, ...
Having the possibility to put this directly into the interchange format allows vendors to roundtrip models. If all vendors participating in the roundtrip re-export the other vendor's extensions than they are not lost during roundtrip which leads to a better inter-operatbility experience for the user.

Users need to be able to add custom Metadata

The possibility to extend the model with custom metadata has also proven to be vital to camunda users and customers in the past.
Many users extend the model with their custom attributes and elements to be able to implement custom extensions.
Some have custom metadata for their execution environment others for auditing and reporting.
It is very important at users are able to put custom metadata into the xml file.

FAQ

Is BPMN's extension mechanism perfect?

Probably not. At the XML level it works extremely well. At the Meta Model level it could certainly be improved.
But the question is whether the practical advantages of a "slightly better approach" would outweigh the advantages of consistency among these standards.

Does that mean that Vendors can just ignore the Standard?

No. In order to be compliant, vendors need to implement the standard in the way mandated by the standard.
If they use custom extensions for realizing non-compliant behavior then they are non-compliant.

Do tools need to understand the extensions created by other vendors?

No. Tools do not need to understand extensions created by other vendors. What's more, the specification text explicitly states that tools do not event need to round-trip extension elements by other vendors while still being compliant. There is also no compliance level at which a tool is required to support this. A tool is fully compliant if it is not able to round-trip extension elements.

Has this actually been successful in BPMN?

Yes. Extension mechanisms are heavily used and there is ample empiric evidence of this being a successful concept. To see it in action have a look at the demos and test cases of the BPMN Model Interchange Working Group (MIWG) at the OMG.

For comparison see also the CMMN 1.1 proposal CR-20.

Add new extension capability to DMN as per that of BPMN and CMMN

Based on the extension capabilities of BPMN and CMMN the following changes need to be done:

1. Add two rows to table 3
2. Add a new figure of the metamodel showing the relation between DMNElement and the extension mechanism in section 6.3
3. Figure 15 - DMNElement class diagram needs to be updated with ExtensionElements and ExtensionAttribute depiction.
4. A complete new section 6.3.14 Extensibility needs to be added. This will have a ripple effect on table and figure numbering. Figure of the metamodel should be inserted after the first paragraph of section 6.3.14, in the metamodel we need to add the two classes described
5. Some changes needed to DMN.xsd, which already contains this mechanism