Conditional PartOf specifications

[atomczak]

Discussed in #341

^{Originally posted by andyward September 12, 2024}
I'd like to write a specification that implements the requirement that All spaces belonging to a BuildingStorey '01' should have their space names matching '01-.*' (or the converse requirement: Spaces named like '01-.*' must be part of a BuildingStorey with Name '01' )

I'm struggling to see how I could do this in IDS1.0. I was hoping to be able to do this with the partOf facet and using RelAggregates but there's no obvious way to apply a requirement to the 'child' side of the relationship.

e.g.

<specification name="Spaces on level '01' must be named based on the level" ifcVersion="IFC2X3">
  <applicability maxOccurs="unbounded">
    <entity>
      <name>
        <simpleValue>IFCBUILDINGSTOREY</simpleValue>
      </name>
    </entity>
    <ids:attribute>
      <ids:name>
        <simpleValue>Name</simpleValue>
      </ids:name>
      <ids:value>
        <simpleValue>01</simpleValue>
      </ids:value>
    </ids:attribute>
  </applicability>
  <requirements>
    <partOf relation="IFCRELAGGREGATES">
      <entity>
        <name>
          <simpleValue>IFCSPACE</simpleValue>
        </name>
      </entity>
      <!-- and these spaces should have Name attribute matching pattern '01-.*' -->
    </partOf>
  </requirements>
</specification>

Any ideas? or is this a usecase to consider for a future IDS? I'd imagine similar use cases for things like ensuring components are in the correct IfcSystem (by classification, name etc).

[atomczak]

How about this #380? Simply allow any facet in PartOf, except PartOf itself, with a minimum of one entity. The implementers' agreement would be that those subfacets apply to the PartOf entity itself. @andyward

[NickNisbet]

Before going down this route, lets do a review of the overall syntax and back/forward-referencing. Otherwise we could be revisiiting this to add more and more syntaxes for ever.

[andyward]

How about this #380? Simply allow any facet in PartOf, except PartOf itself, with a minimum of one entity. The implementers' agreement would be that those subfacets apply to the PartOf entity itself. @andyward

Nice- Looks like it would satisfy the requirement, and seems simple and non-breaking for a 1.1 release. Not sure about the wider syntax review - but that feels like an IDS2 thing if we're making major changes (e.g. Exclusions etc)? Because we're re-using the existing facetTypes this would pick up any future changes anyway?

[atomczak]

I agree with @andyward; this is an acceptable minor change for 1.1, unlike any bigger syntax changes. @NickNisbet, can you document the exact changes you want to propose in Discussions? (unless it's already there)

[BIMvoice]

Checked the current state of this, since it has been quiet.

partOfType in Schema/ids.xsd is unchanged on both development and ver/1.1.x (byte identical, still just a single entity child), and PR #380, the proposed fix, is still open, draft, unreviewed, and now well behind its base. So this is genuinely unresolved, not quietly fixed somewhere.

For what it is worth, I measured the practical cost of the gap using IfcTester. With the current schema there is no way to write a specification that catches a space named as though it belongs to storey "01" but which is actually aggregated under a differently named storey. The partOf requirement can only check that the parent is an IFCBUILDINGSTOREY, not that its Name is "01", so a space named 01-777 sitting under storey 02 passes validation.

IfcTester itself has no bug here: the schema conformant attempt to put an <attribute> inside <partOf> is rejected outright at load time with a validation error, not silently ignored. I looked specifically for a silent accept path and there is none.

Two things that may be worth surfacing:

@fissim-at proposed essentially the same mechanism as PR #380 independently, via a published paper, in this comment on the originating discussion from July 2025. It has had no reply, and nothing links it back to this issue or to PR #380. That is a second, external data point for the general direction.

@NickNisbet's syntax and back referencing concern from the original thread also still looks unanswered, and from the outside that appears to be what is actually blocking PR #380 rather than any lack of a concrete proposal.

For reference, the existing suite has 34 partOf conformance cases, none of which exercise anything beyond entity class and predefined type on the partOf target.