Reconsidering the ability to allow class inheritance

[Moult]

I know this has been decided before, but the more I use IDS, but more I find it quite silly when people ask me "how do I write a requirement for all physical elements", the answer is: "copy paste from this big list of elements which only I have generated, and I've generated three variants of that list for IFC2X3, IFC4, and IFC4X3".

(and yes, people still copy paste wrongly)

And then when somebody reads the IDS, they see a massive list of objects and their eyes tend to glaze over.

In contrast, with inheritance and exclusion facets, I can express this in IfcOpenShell as simply as:

• IfcElement, ! IfcFeatureElement meaning all physical elements, minus openings and protrusions
• IfcDistributionControlElement meaning all the control elements in distribution system (no boring things like pipes and ducts and trays)
• IfcSpatialStructureElement, ! IfcSpace meaning stuff like sites, buildings, storeys (big things) except for individual spaces

It's simple, readable (to me at least), and works across schema versions.

[andyward]

Agreed - it's a strange limitation, especially given how complex some of the other features are elsewhere in IDS (e.g. the recursive aspects of PartOf and Classification facets are probably much trickier to implement and understand). It can't be down to implementor complexity? Worth noting In the xbim implementation we had to add additional logic to prevent ifcType inheritance by default...

As a result though, I've seen examples that then abuse the attribute facet (e.g. AttributeName = "GlobalId" to identify all IfcRoot subclasses) - which seem like an opaque workaround for the absence of something quite simple.

And I'd second that the removal prohibited applicability facets was a big step backwards in 0.96.

[rubendel]

For what it's worth I had the exact same issue as Andy here, putting in extra work not to apply the IFC inheritance, which I think clearly indicates that the original reason (if I remember correctly) of implementation simplicity is moot.

[NiklasPor]

Tbh my base assumption was that IDS would work like this, because most of the other parts of IFC are all based on the inheritance hierarchy 👀

[atomczak]

I was there too, when working on the early version of IfcTester...

Some of the assumptions of IDS were to be as much as possible explicit, schema-agnostic, computationally simple, and easy to implement (with entities, attributes, and measures one could argue if that's actually the case). We also need to consider the broader technical roadmap with IFC5 fusing IFC with GIS etc. Another aspect is the legal interpretation of IDS, which would be much harder with implicit inheritance that differs per IFC version.

If not for the explicit list, how would you express such specification: "the model can contain IfcDuctSegment or IfcPipeSegment but not IfcFlowSegment"?

Tools can be more user-friendly and give users the option to include inheritance or exclusion as suggested by @Moult, as long as they save an explicit list to the resultant IDS file.