Ambiguity on whether or not object aggregates can have a body

[Moult]

According to the element decomposition concept it says:

By default the following constraints apply to an element being decomposed by Element Decomposition:

Body Geometry — composite is constructed from the sum of the Body Geometry of the parts;
the composite shall not have an own Body Geometry, body geometry is provided at the parts;
the composite shall not have an own Material assignment, material is assigned to the parts.

However the page on IfcElementAssembly, very commonly used in steel assemblies, contradict this:

The geometry of an IfcElementAssembly is generally formed from its components, in which case it does not need to have an explicit geometric representation. In some cases it may be useful to also expose an own explicit representation of the aggregate.

Note the sentence I marked in bold.

Also the Element Decomposition concept has this note but what is it referring to? I've never heard of a "Element Decomposition Required" subtemplate:

Use the sub template Element Decomposition Required if any instance of the element is required to represent a composite with declared parts.

[aothms]

I would read this as another type of representation. E.g what you typically see in decomposed walls. Body on the parts. Axis on the wall. This is an approach I would prefer.

There is also this Impl Aggreement also checked by the validation service. https://standards.buildingsmart.org/documents/Implementation/IFC_Implementation_Agreements/CV-2x3-119.html

Neither are very unambiguously described though. I would say: Body only on the lowest level of decomposition. No requirements on other types. But Axis advised on linear elements and walls.

[Moult]

@aothms what would you say about the inconsistency between how spatial structure elements may have bodies on parents whereas in your proposal (and in the docs) object (ifcelement?) decomposition only has bodies on leaf aggregation.

This might be another distinguishing difference between the common debate on aggregate vs nesting, where aggregate parents cannot have bodies whereas nesting can (and probably should, since physical element nesting is about a physical connection point).

[aothms]

spatial structure elements may have bodies on parents whereas

I tbh don't come accross this on a regular basis, but I understand your point. That would be a good opportunity to clean up. Because how does that kind of usage relate to IfcSpatialZone? It seems to be that exact use case (except maybe zoning being non-hierarchical). Also we have the GFA enumeration on space type to distinguish from other spaces without using decomposition. And this PARTIAL/ELEMENT/COMPLEX idea. A lot of overlapping mechanisms...

another distinguishing difference between the common debate on aggregate vs nesting

I agree. Also in the case of alignments, the nested segments of a alignment have a representation in addition to the alignment itself.

I wonder whether that's a good thing or a bad thing:

• Representation defined on multiple levels (device - port) vs lowest (stair - parts)
• Different categories of elements (alignment - segment, device - port) vs (builtelement - builtelement)
• Ordered aggregate vs unordered aggregate

What is the reason that these three facets are controlled together? Is there some conceptual overlap between them?

If you decompose a stair, it would be cool if you can get the steps to show up in an ordered sequence... Right...?