SDMN — Are special Folder semantics really needed for CompositionConnector and ContainmentConnector? Or at all in SDMN.

In the detailed description of both these types is the following (bullets 3 & 4):

• If element within a folder-type DataItem container is updated (e.g., through a change in the value of a

property), the container will not be updated. I.e., the container is not aware of changes to existing contained
DataItems.

• If DataItem within a non-folder-type DataItem container is updated (e.g., through a change in the value of

a property), the container will also be updated. I.e., the container is aware of changes to contained
DataItems.

This seems just to be saying that Folder 'containment' of other items is not really containment, such that the containing object is not considered to be changed when a sub-part is. This is contrary to the very idea of containment, and likely indicates that Folder 'containment' should really just be referencing. If a 'Folder' is deleted for example, are all the items within it deleted? If so, this indicates that a Folder is not a reference object but a true container, and the above special logic is not needed.

My suspicion is that the semantics of Folders is not that clear in SDMN, and knowing what SDMN's primary purpose is, it it not clear that Folder is even needed there - it seems just to be some kind of document-organising concept in CMMN. It might simplify SDMN significantly to get rid of it.

Proposed change:
At least the documentation of Folder needs to be improved to make the semantics clear OR perform analysis to determine if it can be removed from SDMN altogether.

This issue is being resolved by Issue 10/68

Issue 10/68 resolves the confusion between containers and composition.
We also determined that the Folder should remain in SDMN.