buildingSMART
Reconsidering the ability to allow class inheritance
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, ! IfcFeatureElementmeaning all physical elements, minus openings and protrusionsIfcDistributionControlElementmeaning all the control elements in distribution system (no boring things like pipes and ducts and trays)IfcSpatialStructureElement, ! IfcSpacemeaning stuff like sites, buildings, storeys (big things) except for individual spaces
It's simple, readable (to me at least), and works across schema versions.
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.
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.
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 👀
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.
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.
It would be great to have the option to include inheritance (it can default to False).
I also think is necessary to include inheritance. IDS will become unreadable if it not included...
Until the feature is implemented in the schema I invite editor implementers to get creative. The list of all non-abstract classes and their inheritance metadata is available in the IDS Audit Tool, and can be used to make the XP simulate inheritance for the user. Our testing editor manages that, and transforms the list back into a single value with the inheritance flag when reloading the IDS.
becomes
<xs:restriction base="xs:string">
<xs:enumeration value="IFCWALL" />
<xs:enumeration value="IFCWALLELEMENTEDCASE" />
<xs:enumeration value="IFCWALLSTANDARDCASE" />
</xs:restriction>
ad vice versa.
If any implementer needs help in getting the information from the tool, I'm available to support them.
Until the feature is implemented in the schema I invite editor implementers to get creative. The list of all non-abstract classes and their inheritance metadata is available in the IDS Audit Tool, and can be used to make the XP simulate inheritance for the user. Our testing editor manages that, and transforms the list back into a single value with the inheritance flag when reloading the IDS.
becomes
<xs:restriction base="xs:string"> <xs:enumeration value="IFCWALL" /> <xs:enumeration value="IFCWALLELEMENTEDCASE" /> <xs:enumeration value="IFCWALLSTANDARDCASE" /> </xs:restriction> ad vice versa.
If any implementer needs help in getting the information from the tool, I'm available to support them.
How do you get this interface? Can we have access to it (at least until the feature will be implemented)?
It's available at this url
Please be aware that it's not a commercial product; we are using it to test the IDS implementation. it's a SPA web page written in blazor, so it executes entirely on your machine, not on the server.
do not navigate away from the page or the information is lost. You can download the native format or the IDS files from the buttons at the bottom, and upoad a file before you create any specification.