Empty string and cardinality of requirements

[manuel-furia]

Hi,

a customer was confused about components with an empty string IFCLABEL property passing the following ids check:

<ids:specifications>
    <ids:specification name="Specification 1" ifcVersion="IFC4">
      <ids:applicability minOccurs="1" maxOccurs="unbounded">
        <ids:entity>
          <ids:name>
            <ids:simpleValue>IFCWALL</ids:simpleValue>
          </ids:name>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:property cardinality="required" dataType="IFCLABEL">
          <ids:propertySet>
            <ids:simpleValue>Pset_Name</ids:simpleValue>
          </ids:propertySet>
          <ids:baseName>
            <ids:simpleValue>Foo</ids:simpleValue>
          </ids:baseName>
        </ids:property>
      </ids:requirements>
    </ids:specification>
  </ids:specifications>

From the customer's point of view, there is no difference between the property having null value or empty string, since in both cases the required data is not there so the check should fail.
The example in the "Cardinality of Requirements" section of the ids documentation states, for the "required" cardinality, that "Matching entities have a ePset_SpaceOMA/TravelDirection property of type IFCLABEL and non null value".

In the current spec, should IFCLABEL('') be considered non-null? If it is, does it make sense from the user's point of view? Most non-developers would not know/care about the distinction between null and empty string, and authoring tools could be producing either when the value of a property is deleted.

[aothms]

Good question, I clearly remember we discussed this during the conception of the spec.

And we also have testcases related to this:

https://github.com/buildingSMART/IDS/blob/development/Documentation/ImplementersDocumentation/TestCases/attribute/fail-attributes_with_empty_strings_always_fail.ids

In the IfcOpenShell implementation we also seem to specifically check for this case: https://github.com/IfcOpenShell/IfcOpenShell/blob/4593e5aea641f0afee40f5e141f6f0a4475f1afc/src/ifctester/ifctester/facet.py#L314-L315

If the documentation is unclear, feel free to provide an improvement, but I think the spec is intended to work as you propose. Curious what the others think.

[manuel-furia]

@aothms Thanks. The IfcOpenShell implementation link you provided refers to attributes, not properties, buy there seems to be a similar check for properties here anyway: https://github.com/IfcOpenShell/IfcOpenShell/blob/4593e5aea641f0afee40f5e141f6f0a4475f1afc/src/ifctester/ifctester/facet.py#L685

[andyward]

There's a test case for this I believe here

The intent seems clear: "An empty string is considered false and will not pass"

The full IDS and IFC are here and here

The xbim implementation treats empty Ifclabels etc as failed https://github.com/xBimTeam/Xbim.IDS.Validator/blob/88d3d4181bb317471dc35c3d42ff3477a16d540d/Xbim.IDS.Validator.Core/Binders/FacetBinderBase.cs#L412

However I just spotted there's an issue with the above test in this repo in that the datatype specified should be IFCLABEL not IFCLOGICAL, so it's possible it could fail even if empty strings were being treated as 'passed' in your IDS verification implementation. I'll log a separate bug for this.

[manuel-furia]

@andyward
"An empty string is considered false and will not pass"

I was looking at that test case before opening the issue and it was very confusing to me because of the conflating of false and empty. Let's say I want to check the existence of a boolean value, regardless of it being false or true. If any "false" is supposed to not pass, then a boolean property existing and being false will always fail, so how do I check its existence?
I think the exception that empty should be treated as missing should be specific to strings (and maybe lists?), not to types that have a "falsely" value but do not have an "empty" value.
Regarding IFCLOGICAL, should UNKNOWN be considered empty or simply a value of the type?
Regarding strings, I think a better test would be something of the kind:
"An empty string is considered absent and will not pass"

[andyward]

I've logged the test case issue in IfcOpenShell : IfcOpenShell/IfcOpenShell#6472

It appears a few of the test cases are wrong in IfcOpenShell around 'fail' testing of Properties - and these test cases have made it into the main IDS reference tests. Hopefully @Moult can take a look.

I was looking at that test case before opening the issue and it was very confusing to me because of the conflating of false and empty

I believe the IfcOpenShell tests are using 'true' and 'false' as synonymous with 'pass' and 'fail' - it's a bit of the internal implementation leaking out into the public tests. In general omitting the value on an IDS Property facet is saying 'is the property present (regardless of value)'. There's some guidance in facet-configurations.

Let's say I want to check the existence of a boolean value, regardless of it being false or true. If any "false" is supposed to not pass, then a boolean property existing and being false will always fail, so how do I check its existence?

A boolean can only be IFCBOOLEAN(.T.) or IFCBOOLEAN(.F.) - anything else is invalid syntactically (syntax checking is not in IDS's remit). Omitting the value on the facet will check the existence of the property (and that it's typed correctly as IFCBOOLEAN if the datatype is specified). So in the case where the value is omitted, both True and False will pass. If you want to check for Bool value false, just specify the value 'false' as per this test case

Regarding IFCLOGICAL, should UNKNOWN be considered empty or simply a value of the type?

IFCLOGICAL Unknown should fail. In fact there's a test here but it's actually got the same bug from IfcOpenShell so you may get a false failure.

Regarding strings, I think a better test would be something of the kind:
"An empty string is considered absent and will not pass"

I agree the test names are a bit opaque and maybe lack consistency.

[andyward]

It appears a few of the test cases are wrong in IfcOpenShell around 'fail' testing of Properties - and these test cases have made it into the main IDS reference tests

IFCLOGICAL Unknown should fail. In fact there's a test here but it's actually got the same bug from IfcOpenShell so you may get a false failure.

The test cases have been updated now so you could use these tests in your app to see if it's implemented correctly.