Symmetry is broken between applicability and requirements due to nullness #430

Activity

1. NickNisbet commented on Sep 29, 2025

   

   NickNisbet

   on Sep 29, 2025 via email

   More actions

   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.
2. Moult commented on Sep 29, 2025

   

   Moult

   on Sep 29, 2025 via email

   ContributorAuthor

   More actions

   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: ***@***.***>
3. MatthiasWeise commented on Oct 1, 2025

   

   MatthiasWeise

   on Oct 1, 2025

   Contributor

   More actions

   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.

   👍React with 👍1Reacted by Jonatan Jacobsson
4. MatthiasWeise commented on Oct 1, 2025

   

   MatthiasWeise

   on Oct 1, 2025

   Contributor

   More actions

   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.
5. atomczak

   added this to IDS development trackeron Nov 18, 2025
6. github-project-automation

   moved this to Todo in IDS development trackeron Nov 18, 2025
7. atomczak

   added this to the 1.1 milestone on Dec 3, 2025
8. atomczak

   added

   discuss & decide

   on Dec 3, 2025