typeConstraint behavior for collections

[gitgabrio]

Greetings all.
I'm currently implementing the typeConstraint feature for ItemDefinition:

typeConstraint: UnaryTests [0..1]	This attribute is a UnaryTests that restricts the values in the base type that are allowed in this ItemDefinition. In case of a collection, it directly constrains the collection and is not projected on the collection elements.

In our code base, we have a test for the following one:

<semantic:itemDefinition isCollection="true" label="tInterests" name="tInterests">
      <semantic:typeRef>tInterest</semantic:typeRef>
     <semantic:allowedValues xmlns:triso="http://www.trisotech.com/2015/triso/modeling"
                             triso:constraintsType="enumeration">
       <semantic:text>"Golf","Computer","Hockey","Jogging"</semantic:text>
     </semantic:allowedValues>
   </semantic:itemDefinition>

and I wonder what should be the behaviour if I replace allowedValues with typeConstraint

<semantic:itemDefinition isCollection="true" label="tInterests" name="tInterests">
      <semantic:typeRef>tInterest</semantic:typeRef>
     <semantic:typeConstraint xmlns:triso="http://www.trisotech.com/2015/triso/modeling"
                             triso:constraintsType="enumeration">
       <semantic:text>"Golf","Computer","Hockey","Jogging"</semantic:text>
     </semantic:typeConstraint>
   </semantic:itemDefinition>

My impression is that, given the semantic of typeConstraint, the only allowed definitions (in case of collection) should be functions that works on list, but it is not specified anywhere.

Does anybody have a suggestion/clarification to share ?
Thanks!

[StrayAlien]

hey @gitgabrio ... I am just embarking on that same DMN 1.5 journey and also have some questions on typeContraints. Hopefully they (and this) get answered in April's DMN meeting.

EDIT: I see the the DMN meeting notes this was discussed. What was the outcome? The notes only say it was discussed.

[baldimir]

Hello @StrayAlien, you are right, I should have noted some things from the discussion in the meeting notes. Sorry for that.

We discussed that the case @gitgabrio described would basically restrict the collection from containing anything, because everything would fail the check. To get the same behaviour as allowedConstraints, the typeConstraint needs to be modelled in a different way in some cases, as the behaviour is different on collections. In the case from Gabriele, the restriction would need to be defined on the base type, not on the collection. If it would need to be on the collection, some list function needs to be used, contains or similar. Hope it does make sense what I wrote :)

[StrayAlien]

Hi @baldimir . Apols, I wasn't meaning to be offensive if that is how it came accross. Lots of stuff gets discussed at those meetings, so, pretty hard to detail everything. I understand.

Re the above. Yep. Understood perfectly. Thank you!

.... I still have more questions though ... :-)

[gitgabrio]

Hi @StrayAlien
one further detail is that, when applied to collections, allowedConstraints and typeConstraint could be combined to to provide a check like: verify that the list contains x elements (typeConstraint) and that any of these elements falls inside a given "collection" (allowedValues). So, it seems that the twos, when applied to collections, are actually complementary.