Allowed values investigation

[opatrascoiu]

The DMN 1.4 spec contains the following:

7.3.3 ItemDefinition metamodel

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.

DMN 1.5 - after the addition of the new constraints
An ItemDefinition element may restrict the values that are allowed from typeRef, using the allowedValues attribute. allowedValues is an instance of UnaryTests that constrains the domain of the typeRef. If an ItemDefinition element does not contain allowedValues, its range of allowed values is the full range of the referenced typeRef. When an ItemDefinition has sibling itemComponents, their values are available in the evaluation context of the UnaryTests of the allowedValues. In cases where the isCollection attribute of an ItemDefinition is true, each element of the collection must satisfy the UnaryTests of the allowedValues, i.e. the allowedValues are projected onto the collection elements. The default value of isCollection is false. The allowedValues attribute has been deprecated as of DMN 1.5 and replaced with the typeConstraint attribute. The typeConstraint attribute differs from allowedValues by not projecting onto collection elements but directly constraining the collection. An alternative way to define an instance of ItemDefinition is as a composition of ItemDefinition elements. An instance of ItemDefinition may contain zero or more itemComponent, which are themselves ItemDefinitions. Each itemComponent in turn may be defined by either a typeRef and allowedValues or a nested itemComponent. In this way, complex types may be defined within DMN. The name of an itemComponent (nested ItemDefinition) must be unique within its containing ItemDefinition or itemComponent.

DRAFT DMN 1.6 - separates the paragraph with no changes

Conclusion:
The change in DMN 1.5 removes by accident a crucial part of the semantics for the allowed values.

[opatrascoiu]

Proposal;:

1. Keep the original paragraph from DMN 1.4 - backwards compatible
2. Add paragraph for constraintType

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.

The allowedValues attribute has been deprecated as of DMN 1.5 and replaced with the typeConstraint attribute. The typeConstraint attribute differs from allowedValues by not projecting onto collection elements but directly constraining the collection. If an ItemDefinition element contains one constraintType, the constraintType specifies the logical constraint that are applied for the ItemDefinition. If an ItemDefinition element does not contraintType, its constraint is the constraint for the  referenced typeRef.

[baldimir]

Thank you Octavian for opening this discussion.

To highlight the missing part, this is it:
If an ItemDefinition element contains one or more allowedValues, the allowedValues specifies the complete range of values that this ItemDefinition represents.

The discussion was mainly about inheritance of the type restrictions from typeref. If it is inherited or not.

[falko]

Did you check the changebar version of the revision to find the issue that removed it? If there is no issue and it could be an editor mistake.

[opatrascoiu]

@falko I checked the diffs. It was removed in https://issues.omg.org/browse/DMN15-135. Without this paragraph, we have backward compatibility issues - the process of attaching the constraints to types becomes ambiguous.

If I remember correctly we did not discuss in the RTF any change in the process of collecting the constraints. I think the removal of the paragraph that explains the process of resolving the constraints for a type is not intentional.

@SimonRinguette could you have a look at this, and maybe speak with Dennis as he submitted the proposal?

We need to solve this one ASAP, preferably before the release of DMN 1.6.

[gitgabrio]

Thanks @opatrascoiu to raise the discussion.

Reading the motivation for the new typeConstraint, I personally have the impression that there was the intention to extend the behavior, that previously allowed only enums/ranges to be defined as constraints, even if the UnaryTests itself would allow more complex use cases. So, the typeConstraint has been defined, and the only possible way to create a constraint over a collection as whole is to use the ? kind of expression.
WIth that in place, extending the scope of the ?identifier to parent types comes pratically out of the box, and would also be consistent with the following definition (IINW):

typeConstraint: UnaryTests [0..1]: This attribute is a UnaryTests that restricts the values in the base type that are allowed in this ItemDefinition.

Beside that, the constraint inheritance was already implied also in both the definitions quoted at the begin of this discussion, as @baldimir underlined.

Wrapping up, I think that the previous implementation limited a lot the usefullness of the extension mechanism, while the ability to inherit not only fields but also constraint would make the DMN specs much more powerful, allowing use cases that would be currently cumbersome to implement.

So, unless there is not a Business requirement to avoid that, I think it would be a good idea to allow the constraint inheritance, that seems to be the most straightful consequence of last modifications.

[opatrascoiu]

Changing the rules of attaching the constraints to types is not backward compatible. We cannot break the backward compatibility in a minor release. I don't mind changing the rules in DMN 2.0.

[gitgabrio]

Sorry @opatrascoiu - what are the rules you refer to ?
Even if there was some for allowedValues, typeConstraint is something new, that did not exists before, does not have any previous rule, and must implicitily have a different semantic.
I'm fine if we choose to keep the previous approach to allowedValues, to maintain backward compatibility, and move to newer approach for typeConstraint.
This would also make the new typeConstraint more clearly defined/differentiated compared to allowedValues

[opatrascoiu]

My assumption is the collection / attachment of constraints for types is the same for both kinds: old and new constraints.

AFAIK the DMN 1.5 change intends to add only a new kind of constraint.

[gitgabrio]

Yup, that is also mine assumption. But a new constraint with (almost) the same semantic of the previous one does not have much sense, IMO.
What I see is:

1. a request that clearly ask for more consistence usage of UnaryTests ("[...] Our proposal would be to align the usage of UnaryTests with decision table inputs.[...]")
2. a technical definition that actually allows the inheritance of constraints
3. a specifications that, IMO, clearly refer to inheritance This attribute is a UnaryTests that restricts the values in the base type that are allowed in this ItemDefinition -> if a type extends another type, its base type is the extended one (please correct me if I'm wrong)
4. the "inherited constraint" approach for typeConstraint would improve the usability of the standard, maintaining backward compatibility; and that should be the ultimate goal, IMO
5. at the end of the day, it seems just a matter to better rephrase the specification, something that anyway has to be done.

So, again if there is not a Business restriction that I'm not aware of, I fail to see a reason to not do an improvement that would be backward compatible and would improve the usability of the standard itself.

[baldimir]

Hi, I would like to ask also clarification about this please: When an ItemDefinition has sibling itemComponents, their values are available in the evaluation context of the UnaryTests of the allowedValues. - What are the sibling itemComponents in this case? Are those meant from a complex type perspective, so that when there is a complex type with multiple itemComponents, the allowedValues of those itemComponents can use the values from all those itemComponents between each other?

[baldimir]

Discussed on the meeting - based on the discussion, the sibling itemComponents that are part of an ItemDefinition should be able to share the values for the allowedValues UnaryTests. Example: ItemDefinition with itemComponents category, productType. There could be a constraint on the category saying for a category, only specific productTypes are allowed.

[baldimir]

This may need an RTF ticket to change that it is possible that such type constraints are defined on the ItemDefinition level. Currently it is not possible to have allowedValues defined on ItemDefinition, when there are itemComponents in it.