Spatial Composition restraint

[jwouellette]

Please refer to:
https://forums.buildingsmart.org/t/spatial-composition-restraints/1129

Description of the proposal:
Remove legacy composition type

Describe how it contributes to the objectives set in https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC:

What do we win:

What do we loose

Schema impact:

Instance model impact:

Backwards compatible:

Automatic migration possible:

Additional implications:

Note that not all points need to be satisfied!
Backwards compatibility and file size are not concerns.

[Moult]

My understanding of this issue is that after the composition type is removed, it implies that you can nest more than three levels deep of a single spatial element, e.g: IfcSite > IfcBuilding > IfcBuilding > IfcBuilding > IfcBuilding > IfcBuilding > IfcBuildingStorey becomes legal.

+1. I had a shot at filling out the fields:

Wins: more flexibility in spatial tree. No need for vendors to apply non-automated rule checking (as there are no WHERE rules) on three level deep composition type. Also less confusion about whether a building complex is an IfcSite or a IfcBuilding.COMPLEX.

Losses: Possibly some BIM authors might go crazy and create silly unnecessarily nested trees. Deep trees are baaaaaad. It also creates confusion about the currently non-abstract IfcFacility and IfcFacilityPart proposals. Also, if I wanted to know how many building complexes I have, the query becomes slightly harder to write.

Backwards compatible: No

Automatic migration: Yes