buildingSMART / buildingSMART/IDS
Data type mismatch in applicability bypasses checking
- Dominant language
- C#
- Stars
- 318
- Forks
- 90
- PR merge metrics
- No merged PRs in 30d
Description
Consider an example where you want to check all elements with a property XYZ of value ABC (the requirement is not relevant here).
Because we ask for a precise value, we need to specify the data type, which, in my case, is IFCLABEL. If a model has property XYZ with value ABC but captured as IFCTEXT instead, it is simply omitted. Not good.
I'm attaching an IDS file with IFCLABEL and IFC model with a beam with IFCTEXT: [Data_type_experiment.zip](https://github.com/user-attachments/files/16690146/Data_type_experiment.zip). I tried checking one against the other in usBIM and IfcTester, and both didn't report any errors, but also no passed element. It means they didn't consider that beam as an applicable object, giving a false positive result.
The solutions I see:
1. allow to leave data type empty in applicability, so no matter what data type, it will find it.
2. allow to specify multiple data types (more complex and still leaves the door open to omissions)
In the long run, I hope the IFC is purged of overlapping data types like these...
A temporary workaround for IDS1.0 is to add a specification for each other's data type and forbid it. In the case above, saying that IFCTEXT is forbidden for XYZ property. I attach that one as well.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.