Test cases needed for IFCProject properties (and other non-IfcObjects) in IFC4+

[andyward]

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

[aothms]

Good point.

At the same time we may want to look at IfcMaterialDefinition properties and test cases for those as well. Relates to #198

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]

@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 is IfcContext > IfcObjectDefinition > IfcRoot in IFC4 and IfcObject > IfcObjectDefinition > IfcRoot in IFC2X3, and IfcContext independently redeclares its own IsDefinedBy inverse attribute pointing at IfcRelDefinesByProperties, matching your diagnosis exactly.

Then I built minimal IFC4 and IFC2X3 files with a property set on IfcProject and ran them through IfcTester's Property facet. IfcTester does not have this defect in either schema. It finds the property via IfcContext.IsDefinedBy in IFC4 just as it does via IfcObject.IsDefinedBy in IFC2X3, because the underlying property lookup resolves inverse attributes through the schema declaration rather than special-casing IfcObject.

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. IfcExtendedMaterialProperties crashed IfcTester's property checker outright rather than giving a wrong verdict, because it is a subtype of IfcMaterialProperties that lacks the Properties attribute 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.