fail-a_logical_unknown_is_considered_false_and_will_not_pass

[I-Sokolov]

I think the test-case should be pass-*
Value is not specified, and any non-empty value must be allowed

[BIMvoice]

Agreeing with the original point, and disclosing something that follows from it.

We think this should be pass- too, and we have implemented it that way in IfcTester after hitting it as a real defect. But because IfcTester is what generates these test cases, our change would rename this one, so it seems right to raise that here rather than let it arrive silently.

Why we think UNKNOWN is a present value

IFCLOGICAL is three-valued: TRUE, FALSE, UNKNOWN. A value of UNKNOWN is explicitly set. It is not the same as the attribute being $. An existence check asks whether a value is there, and it is.

IfcTester did the opposite, in ifctester/facet.py:

attribute_type = inst.attribute_type(argument_index)
if attribute_type == "LOGICAL" and value == "UNKNOWN":
    is_empty = True

The consequence is not symmetric, which is what made it worth fixing. Using IfcPresentationLayerWithStyle.LayerOn = "UNKNOWN", a present value:

cardinality	before	correct
required	FAIL	PASS
prohibited	PASS	FAIL

The prohibited case is a false pass: a present value reported as absent means the prohibition is silently satisfied and a non-compliant model passes with nothing to prompt anyone to look. That is why we treated it as a defect rather than a preference.

The disclosure

ifctester/test/ids_doc_generator.py generates the test cases from IfcTester's own assertions:

This is not a test file. It lives in the test/ directory because it reuses test cases from test_facet.py and test_ids.py to generate example IFC files, IDS files, and Markdown documentation

and names them f"{result}-" + <test description>. So this case's name comes from an assertion reading "A logical unknown is considered false and will not pass" with expected=False.

Our fix replaces that with "A logical unknown is a real value and passes an existence check", expected=True. Regenerating would therefore turn this fail- case into a pass- case, which is what this issue asks for, but it is a semantics change to the conformance suite arriving through a downstream implementation. We would rather you decided it than have it appear as a side effect.

So: is pass- the intended behaviour? If yes, we will proceed and the regenerated case will match. If not, we will revert our change to match the suite instead, and would appreciate a line on the reasoning so we can document it.

A related gap

Nothing in the User Manual discusses IFCLOGICAL's three-valued nature or says whether UNKNOWN counts as populated. We searched attribute-facet.md, property-facet.md, specifications.md, Implementers/DataTypes.md and Implementers/developer-guide.md: the only mention is one row in DataTypes.md mapping IFCLOGICAL to xs:string, with no semantics.

The same bug had already been found and fixed once in IfcTester's Property facet before Attribute repeated it, which suggests it is easy to get wrong from the documentation alone. Whichever way this is decided, a sentence stating it would likely prevent the next implementer repeating it, and we are happy to open that as a docs PR.

[BIMvoice]

Correcting a claim in our comment above, which is wrong for the same reason @andyward corrected us on #283.

We said ifctester/test/ids_doc_generator.py generates this repository's test cases, and that fixing the bug in IfcTester would automatically flip fail-a_logical_unknown_is_considered_false_and_will_not_pass to a pass- case on regeneration. That is not how this repository works. The .ids files here are generated from fenced code blocks in Documentation/ImplementersDocumentation/TestCases/scripts.md via the CreateTestCases build target, with hand maintained .ifc companions. Nothing in IfcTester's generator touches this repository.

So the question we asked, whether pass- is the intended behaviour, still stands. But nothing here updates on its own if the answer is yes. It would need the fenced block and its .ifc companion edited directly, the same way we have since done for #371, #435, #181 and #155 in PRs #451, #452, #453 and #457.