I think I agree with nn1 and Moult.
I don’t see how the schema can practically be modularized. I think most programs would need to know about the full schema (all modules) anyway, because they will get files with lots of different modules.
And I’m particularly sceptical to introduce versioning per module. What will then happen with files that uses multiple modules? For example an electro circuit that controls an HVAC valve or a road traffic light? There will have to be some kind of “global” versioning system to ensure that the different modules are compatible with each other.
From the application perspective, I just don’t see how this could work well in practice. But I think I would need more concrete examples to be able to know what we really are talking about here, so this is mostly based on fear of the unknown.
Btw: The ISO 10303-21 standard (step text format) also describes conformance 2 type, where objects are written like this:
instead of this:
This allows programs to deal with objects even if it doesn’t know about the concrete subtype. Any IFC viewer could thus visualize the product (since it knows about IfcProduct), but doesn’t necessarily have to know about IfcOutlet, because that could be part of an unknown module. I think this could be useful (but also very verbose and give much bigger files).
What I’m basically saying, is that the ISO 10303 does already touch these topics, and already supports modularization. So if we are still going to use the STEP/EXPRESS architecture, we should look at the standard and see what more it has to offer in this direction.
I think there is another kind of modularization that would much more benefit applications, and that is if the IFC models itself were more modular and could be split across multiple files. One step in that direction would be to use GUID references in relation objects instead of entity ids.
The convention today is to have separate files for each domain: one architect file, one electro file, one ventilation file etc. All of them repeates (duplicates) for example the spatial structure. And there is no way to enrich another model (for example specify material layers in building elements, needed for various simulations, without reexporting the whole architecture model).