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.

[CBenghi]

Let the software handle casting, not users. What are the arguments against it?

I think the argument against it is two-fold:

1. Specifications would not be fully expressive and open to misinterpretations.
2. To let applications cast appropriately we have to formalise clear casting rules for all types.

The group also assumed that specifying datatype would be easy to do when the value is constrained. It seems reasonable that constraints on values come after the choice of the data to expect.

[andyward]

It seems reasonable that constraints on values come after the choice of the data to expect.

Just as a counter argument, take a scenario that requires a length property to be, say, > 1m.

That would require a datatype be specified as part of the requirement - presumably IFCLENGTHMEASURE. But if an IFC file is provided with a datatype of IFCPOSITIVELENGTHMEASURE instead it would always fail? That feels unintuitive given both are essentially synonyms for REAL.

In this case it feels like the data type constraints would benefit from some kind of casting or equivalence

[aothms]

That feels unintuitive given both are essentially synonyms for REAL.

IfcPositiveLengthMeasure is even a subtype of IfcLengthMeasure, but we've said not to include inheritance in the entity evaluation, so it makes sense to be consistent here.

TYPE IfcPositiveLengthMeasure = IfcLengthMeasure;
 WHERE
	 WR1 : SELF > 0.;
END_TYPE;

So that leaves us with two cases:

• siblings: Requested IfcLabel, got IfcText
• children: Request IfcLengthMeasure, got IfcPositiveLengthMeasure

In both cases these distinctions matter at a schema level: you inform about the intent about how a data type is used: e.g labelling, identifying, describing: which is good because it informs about the scope you can use information in. But in a data deliverable it doesn't add information when you're asked to deliver a IfcLengthMeasure and you deliver a IfcPositiveLengthMeasure, because that information is already embedded in that value.

And then there is also the other case:

• parent: Requested IfcPositiveLengthMeasure, got IfcLengthMeasure with a positive value

In this case it feels like the data type constraints would benefit from some kind of casting or equivalence

So in summary, I wouldn't be opposed to it, but that kind of intelligence is not really consistent with how we choose not to support substituting entities in case of inheritance.

[andyward]

Agreed it gets complex when the datatype is specified we want to honour the IFC semantic in the tests. Clearly IFCLENGTHMEASURE(1.0) != IFCAREAMEASURE(1.0) despite both being backed by the same underlying type.

With a pragmatists viewpoint I tend to recommend omitting the data type when the user wants to check a value but doesn't care about the exact sematic type, but technically that's invalid IDS and some implementations may treat it differently. Perhaps we just need to revisit this 'implementors agreement' where

PSET / NAME / [VALUE]
(without dataType) is not allowed:

Fields Entered	Required	Optional	Prohibited	Applicability
PSET / NAME	✅	❌	✅	✅
PSET / NAME / [DATATYPE]	✅	✅	❌	✅
PSET / NAME / [DATATYPE] / [VALUE]	✅	✅	❌	✅
PSET / NAME / [VALUE]	❌	❌	❌	❌

Worth noting that according to these rules @atomczak 's original workaround is actually invalid as you can't prohibit a dataType:

A temporary workaround for IDS1.0 is to add a specification for each other's data type and forbid it.

An alternate solution to all this (in IDS2+) might be to make dataValue an ids:idsValue in the schema rather than a string. That way the user could specify enumerations, patterns etc. for the datatype.

[CBenghi]

@andyward,

because of value conversion to SI units, I was wondering if we can easily introduce a convention that allows to accept any measure that shares the same dimensional exponents of the specified datatype.

This would resolve both fcLengthMeasure == IfcPositiveLengthMeasure and the FCLENGTHMEASURE(1.0) != IFCAREAMEASURE(1.0).