review of a number of testcases

[MarcelStepien]

Hello all,

I have taken the time to test a majority of the testcases provided in the documentation folder against a running implementation of an IDS engine.

Specifically the following facets has been tested:

• Attribute
• Entity
• Property

While most tests worked fine, some of the listed cases require adjustments. Here, I want to showcase some findings and provide feedback to improve the provided cases.

---

1. (Entity) fail - a predefined type must always specify a meaningful type not userdefined itself

In this case, the check of predefinedValue -> USERDEFINED is expected to result in a failed test. However, this should result in a successful validation. A valid use case would be "generically find all IFC entities that have a custom defined type associated with them". Other test cases also consider some sort of priority to be checked for predefinedTypes:

• First, the predefinedType is always checked.
• Secondly, the objectType, processType or elementType is checked.
• And finally, if none of the previous apply, the relation of IfcRelDefinedByType is checked.

At this point, a case can be made for simply renaming "predefinedType" to "type" in the IDS specification.

---

2. (Entity) fail - entities must be specified as uppercase strings

This case validates the IFC entity class name by checking the equivalence between class name and defined requirement. In this case, I would recommend excluding entity class name validation from case sensitivity checks. The reason for this is that case sensitivity is a developer-specific dependency. Camel case or upper case notation can both be used in implementations and should not be enforced for the entity class name by the schema or test cases. So, this case should result in a successful validation.

But keep in mind, I would only recomend removing case sensitivity for class dependent requirements (such as IfcWall, IfcBoolean or IfcRelDefinedByType).

This relates also to:

• (Property) fail - booleans must be specified as uppercase strings 3 3

---

3. (Attribute) fail - attributes with empty strings always fail

The check evaluates an empty string as an failure. This should not be the case. There are several use cases in a BIM data exchange scenario where empty srings are a requirement for IfcValue entries. To be precise, if the check is to validate that something other than an empty string is provided, a pattern constraint should be used here.

This relates also to:

• (Property) fail - an empty string is considered falsey and will not pass

---

4. (Attribute) fail - booleans must be specified as uppercase strings 2 3

In this case, the validation considers a difference between False and .F.. However, considering that an IDS engine operates with an loaded and object-oriented IFC model, the boolean values are wrapped as IfcBoolean-types. There are several ways to represent a false boolean value, such as False, false, FALSE, F, f, or 0. These are logically different representations of the same value and therefore should result in successful validation.

Considering the possible definition of measure in IDS, the type IfcValue must also be checked. If no measure is specified, the simpleValue check is usually for a String. Here, this String should be forcibly converted to the same type as the IfcValue it is check against in the model, to ensure that no type discrepancy occurs.

This relates also to:

• (Property) pass - integer values checked using type casting

---

5. (Property) pass - floating point numbers are compared with a 1e6 tolerance

All checks of this type do not work logically. As defined, they should fail rather then pass, because 42 != 42.00042 and 41.999958 != 42.00042. I would raise the question, does it make sence to try and restrict the floating point accurency to 1e6 tolerance? The limit should be variable and rather dependent on the attached unit or the IfcValue type.

---

6. (Property) pass - non ascii characters are treated without encoding

There is a spelling issue in the IFC model file: ♫Don'tÄrgerhôtelЊет (IDS) != ♫Don''tÄrgerhôtelЊет (IFC)

There is a quotation mark to much included.

This relates also to:

• (Attribute) pass - non ascii characters are treated without encoding