Symmetry is broken between applicability and requirements due to nullness

[Moult]

It used to be that a facet was symmetrical. For example, a facet applied to an entity would result in either True or False. If you used that facet as an applicability True = applicable, False = not applicable. As a requirement, True = pass, False = fail.

I've noticed that the documentation has now changed such that this symmetry is broken. A facet used as an applicability seems to be always be treated as the "required" situation, whereas a facet used as a requirement has different meanings.

For example:

• Applicability (required): Property(pset=Pset_Foo, basename=Foobar) - Matches if Pset_Foo.Foobar is filled in
• Requirement (required): Property(pset=Pset_Foo, basename=Foobar) - Matches if Pset_Foo.Foobar exists, even if null

Another example:

• Applicability (prohibited): Property(pset=Pset_Foo, basename=Foobar) - Matches if Pset_Foo.Foobar is filled in
• Requirement (prohibited): Property(pset=Pset_Foo, basename=Foobar) - Matches if Pset_Foo.Foobar exists, even if null

Is this intentional? It acts as an edge case for users which can lead to surprise, and also means code is less straightforward to implement.

[NickNisbet]

I think that this inconsistency is compounded by allowing requirements to be expressed in the applicability section. Namely ‘existence’. I find it troubling that we can demand the existence of say an IfcTransportElement=elevator without saying what it must be a part of. We are not dealing with universals here (no white or black swan issues). We are dealing with a specific project/sites/buildings. The ‘existence’ tests should be deprecated in favour of saying a building or storey (or whatever) must have an elevator (or whatever). But definitely NOT the site!. If there are two buildings, then one elevator is not sufficient. It is one PER BUILDING (given certain circumstances). Regards, Nick.

[Moult]

Also broken is the symmetry between required and prohibited. It used to be that the same facet had exactly opposite results for required vs prohibited. Now there are subtle differences. I never realised these changes earlier because I would monitor the XSD which didnt change. Dion Moult Sent from Proton Mail Android

…

-------- Original Message --------

On 29/9/25 7:12 pm, NickNisbet wrote: NickNisbet left a comment [(buildingSMART/IDS#430)](#430 (comment)) I think that this inconsistency is compounded by allowing requirements to be expressed in the applicability section. Namely ‘existence’. I find it troubling that we can demand the existence of say an IfcTransportElement=elevator without saying what it must be a part of. We are not dealing with universals here (no white or black swan issues). We are dealing with a specific project/sites/buildings. The ‘existence’ tests should be deprecated in favour of saying a building or storey (or whatever) must have an elevator (or whatever). But definitely NOT the site!. If there are two buildings, then one elevator is not sufficient. It is one PER BUILDING (given certain circumstances). Regards, Nick. — Reply to this email directly, [view it on GitHub](#430 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAVR3TRZLYDQTGDUW7CHID3VDZW3AVCNFSM6AAAAACHYPC4I6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNBVHA2TMNBRHA). You are receiving this because you authored the thread.Message ID: ***@***.***>

[MatthiasWeise]

I think that this inconsistency is compounded by allowing requirements to be expressed in the applicability section. Namely ‘existence’.
I find it troubling that we can demand the existence of say an IfcTransportElement=elevator without saying what it must be a part of. We are not dealing with universals here (no white or black swan issues). We are dealing with a specific project/sites/buildings. The ‘existence’ tests should be deprecated in favour of saying a building or storey (or whatever) must have an elevator (or whatever). But definitely NOT the site!. If there are two buildings, then one elevator is not sufficient. It is one PER BUILDING (given certain circumstances).

Regards, Nick.

There was a discussion about global existance, e.g. to ask for instances of IfcSpace.
In the current approach, this was limited to at least one and not a specific number, which is theoretically possible with min/maxOccurs.

I fundamentally agree that this should be better expressed through relationships (in the worst case starting with IfcProject/IfcContext), but there are limitations due to the available facets in IDS. One can say that IfcSpace must be part of an IfcBuildingStorey, but one cannot say that an IfcBuildingStorey must have/contain IfcSpaces. We would need a new HasParts-Facet to express this.

[MatthiasWeise]

It used to be that a facet was symmetrical. For example, a facet applied to an entity would result in either True or False. If you used that facet as an applicability True = applicable, False = not applicable. As a requirement, True = pass, False = fail.

I've noticed that the documentation has now changed such that this symmetry is broken. A facet used as an applicability seems to be always be treated as the "required" situation, whereas a facet used as a requirement has different meanings.

For example:

* Applicability (required): Property(pset=Pset_Foo, basename=Foobar) - Matches if Pset_Foo.Foobar is filled in

* Requirement (required): Property(pset=Pset_Foo, basename=Foobar) - Matches if Pset_Foo.Foobar exists, even if null

Another example:

* Applicability (prohibited): Property(pset=Pset_Foo, basename=Foobar) - Matches if Pset_Foo.Foobar is filled in

* Requirement (prohibited): Property(pset=Pset_Foo, basename=Foobar) - Matches if Pset_Foo.Foobar exists, even if null

Is this intentional? It acts as an edge case for users which can lead to surprise, and also means code is less straightforward to implement.

I guess you want define something like "select all instances of IfcWall where the property IsExternal is not defined"? I think this cannot be done with current IDS.