DMN15 — Precision on Allowed Values UnaryTests

DMN ItemDefinitions metamodel (section 7.3.3) specifies that and ItemDefinition can restrict its typeRef by using an allowedValues attribute that is defined as a UnaryTests:

An ItemDefinition element may restrict the values that are allowed from typeRef, using the allowedValues attribute. The allowedValues are an instance of unaryTests that specifies the allowed values or ranges of allowed values within the domain of the typeRef. The type of the allowed values SHALL be consistent with the containing ItemDefinition element. If an ItemDefinition element contains one or more allowedValues, the allowedValues specifies the complete range of values that this ItemDefinition represents. If an ItemDefinition element does not contain allowedValues, its range of allowed values is the full range of the referenced typeRef. In cases where the values that an ItemDefinition element represents are collections of values in the allowed range, the multiplicity can be projected into the attribute isCollection. The default value for this attribute is false.

This paragraph has a few contradictions with the spec:

• The last phrase is not clear about which attribute defaults to false, this whole paragraph talks about allowedValues and the intention must be that it refers to isCollection but that certainly confused us.
• The attribute allowedValues is a UnaryTests but its usage is not consistent with its usage in decision tables inputEntry. A UnaryTests is defined as an expression that evaluates to a boolean with an implicit argument to be tested (from its definition in section 7.3.2). However, this is not the way it is used here. Here it defines a range/enumeration of allowedValues and not an expression that is evaluated with an implicit argument.
  Our proposal would be to align the usage of UnaryTests with decision table inputs.
  This would allow extended use cases such as:

•  A validation of an email address domain: allowedValues => ends with(?, “@trisotech.com”) 

•  Validation that depends on sibling variables values: allowedValues => if OrderType = “Type A” then [“a”,”b”,”c”] else [“c”, “d”, “e”] 

•  Or something even simpler like not null: allowedValues => ? != null 

•  Length check on strings: allowedValues => string length(?) > 10 

Align the usage of UnaryTests with decision table inputs

Align the usage of UnaryTests with decision table inputs

UnaryTests and FEEL have become so powerful that the projection of allowedValues onto collection elements is not required any more.

XSD and Meta Model change on Figure 7-7: ItemDefintion class diagram, add a composition between ItemDefinition and UnaryTests with the cardinality 0..1 on both sides named typeConstraint. (same as allowedValues): https://github.com/omg-dmn-taskforce/omg-dmn-spec/pull/27/files