Isn’t this two different points:
- Does TypeObject require the usage of MappedItem?
- Does MappedItem require the usage of TypeObject?
For the second questions, we have to keep in mind that not all elements have associated typeobjects (but perhaps it’s not crazy to suggest they shouldn’t use mapped representations).
But also, MappedItems do not necessary have to point to another product. One could also use mapped items to instantiate multiple items within the same representation.
MappedItems can also result in geometric transformations that would (in my view) require a different type object to be supplied (such as mirroring and scaling)
Since IFC4 possible to assign a IfcProductDefinitionShape to multiple Products. This is my view is a much simpler way of establishing how Type-Product geometries are related.
For IFC5 it’s seriously being discussed to move the geometry to the type object.
Therefore, my view on all of this is: We can’t really restrict these kind of things too much without introducing backwards incompatibility. MappedItems are, in my opinion, the wrong abstraction to describe Type-Product geometries, anyway.
I’d propose to clarify wording and recommendation in the docs where needed, but not making any schema changes, and come up with proper, easily understood mechanisms for IFC5.