Data type mismatch in applicability bypasses checking

[atomczak]

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. 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.

[andyward]

This sounds a bit similar to #331 - but we didn't get an authorative decision.

I proposed a third possible solution: to permit some kind of alias. So IFCLABEL is equivalent to IFCTEXT etc

[atomczak]

You're right, indeed it's the same issue, but let's keep this one given the IFCxIDS samples provided and try to resolve here. I see you also addressed it in #206.

I prefer the first option - not requiring data type even when value is provided. Let the software handle casting, not users. What are the arguments against it? @CBenghi

[andyward]

Yes it's unclear if dataType is optional or not. I believe the schema now leaves it optional (As per last comment in 206) but the audit-tool still treats its omission as an error.