Repository navigation
Test cases needed for IFCProject properties (and other non-IfcObjects) in IFC4+ #435
Description
An interesting edge case we hit in xbim's IDS validation logic made me realise IDS may need a couple of extra test cases for the properties facet - particularly for any "early bound" IDS implementations. In xbim's implementation when checking properties we distinguish between _IfcObject_s and _IfcTypeObject_s due to the different Properties relationships, and the need to inherit /override Objects with Types. But it became apparent that properties on IFCProjects under IFC4 were not being identified (but fine under 2x3). Why:
In IFC2x3, IfcProject is a subclass of IfcObject which is where it gets its properties from (via IsDefined relationship).
In IFC4, IfcProject moved to a new abstract superclass of IfcContext, derived from IfcObjectDefinition. We'd missed IfcContext as place where properties could be defined.
This probably is less of an issue for those implementations doing latebound / 'duck' typing. But raises the fact we may need some additional test cases. I created one https://github.com/xBimTeam/Xbim.IDS.Validator/blob/master/Xbim.IDS.Validator.Core.Tests/TestCases/xbim/pass-ifc4-projects-support_properties.ids
At the same time we may want to look at IfcMaterialDefinition properties and test cases for those as well. Relates to #198
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
aothms commentedon Oct 18, 2025
Good point.
Also there are some discrepancies with 2X3 for example that several material properties are actually defined in the schema as optionally typed measures, see suptypes of: https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/ifcmaterialpropertyresource/lexical/ifcmaterialproperties.htm I.e predefined property sets for materials.
BIMvoice commentedon Aug 5, 2026
@andyward I noticed this is assigned to @CBenghi so I'm not proposing to take it over, just sharing what I measured in IfcOpenShell's own IDS implementation (IfcTester), since it's directly relevant data for this issue.
I verified the schema claim first:
IfcProject's supertype chain isIfcContext > IfcObjectDefinition > IfcRootin IFC4 andIfcObject > IfcObjectDefinition > IfcRootin IFC2X3, andIfcContextindependently redeclares its ownIsDefinedByinverse attribute pointing atIfcRelDefinesByProperties, matching your diagnosis exactly.Then I built minimal IFC4 and IFC2X3 files with a property set on
IfcProjectand ran them through IfcTester's Property facet. IfcTester does not have this defect in either schema. It finds the property viaIfcContext.IsDefinedByin IFC4 just as it does viaIfcObject.IsDefinedByin IFC2X3, because the underlying property lookup resolves inverse attributes through the schema declaration rather than special-casingIfcObject.Following your suggestion to also check
IfcMaterialDefinition: IFC4 is fine there too. But that check did find a real, different defect on the IFC2X3 material side.IfcExtendedMaterialPropertiescrashed IfcTester's property checker outright rather than giving a wrong verdict, because it is a subtype ofIfcMaterialPropertiesthat lacks thePropertiesattribute the parent branch reads. Fixed in our own repository, separate from this issue.I've also put together proposed test cases covering the IfcProject/IfcContext boundary and the material side, as a starting point for @CBenghi to use, change, or discard: #452.
Propose IfcProject and IfcMaterial property test cases
Merge pull request #452 from BIMvoice/propose/ids-435-context-materia…