# Ifc Syntax Building Elements > Use when you need to create, place, or debug a physical construction element in an IFC model : a wall, slab, beam, column, member, plate, door, window, roof, covering, stair, railing, footing, or proxy, including the type object, the PredefinedType enumeration, the spatial containment link, and the opening / void / fill triad for a door or window in a wall. Prevents using the removed name IfcBuildingElement in an IFC4.3 file (it was renamed IfcBuiltElement), leaving an element orphaned with no spatial container, reversing the IfcRelVoidsElement and IfcRelFillsElement anchors, setting PredefinedType to USERDEFINED without an ObjectType, and using a deleted *StandardCase entity. Covers IfcWall, IfcSlab, IfcBeam, IfcColumn, IfcMember, IfcPlate, IfcDoor, IfcWindow, IfcRoof, IfcCovering, IfcStair, IfcRailing, IfcFooting, IfcBuildingElementProxy, the matching type objects and PredefinedType enums, IfcOpeningElement, IfcRelContainedInSpatialStructure, IfcRelVoidsElement, IfcRelFillsElement, the IFC4.3 infrastructure - Skill: `impertio-studio/ifc-syntax-building-elements` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add impertio-studio/ifc-syntax-building-elements` - Raw SKILL.md: https://api.skillmd.com/api/skills/impertio-studio/ifc-syntax-building-elements/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - License: MIT - Author: Impertio-Studio (https://skillmd.com/u/impertio-studio) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/impertio-studio/ifc-syntax-building-elements --- # IFC Syntax : Building Elements A building element is a physical part of the construction : a wall, a slab, a door. This skill covers the concrete element entities, their type objects and `PredefinedType` enumerations, how an element is placed into the spatial structure, and the opening / void / fill triad used for a door or window in a wall. Applies to IFC2x3, IFC4, and IFC4.3. The abstract supertype was renamed across versions : see Version Differences. ## Quick Reference ### The element supertype and the hard rename Every concrete building element is, through inheritance, an `IfcElement` and an `IfcProduct` (so it carries `ObjectPlacement` and `Representation`). The direct abstract supertype changed name : - IFC2x3 and IFC4 : `IfcBuildingElement` (abstract). - IFC4.3 : the entity was RENAMED to `IfcBuiltElement` and made non-abstract. ALWAYS write `IfcBuildingElement` for an IFC2x3 or IFC4 file and `IfcBuiltElement` for an IFC4.3 file. NEVER use `IfcBuildingElement` in an IFC4.3 file : that name returns HTTP 404 in the IFC4.3 schema and the file is invalid. This is a hard, file-breaking rename. See `ifc-core-entity-hierarchy`. ### The concrete element catalogue Every entity below is a subtype of `IfcBuiltElement` (IFC4.3) / `IfcBuildingElement` (IFC2x3, IFC4). Each occurrence entity (from IFC4 onward) has a matching type entity and an OPTIONAL `PredefinedType`. | Occurrence | Type object | PredefinedType enum | What it is | |------------|-------------|---------------------|------------| | `IfcWall` | `IfcWallType` | `IfcWallTypeEnum` | A vertical space-separating element | | `IfcSlab` | `IfcSlabType` | `IfcSlabTypeEnum` | A horizontal element (floor, roof, landing) | | `IfcBeam` | `IfcBeamType` | `IfcBeamTypeEnum` | A horizontal structural member | | `IfcColumn` | `IfcColumnType` | `IfcColumnTypeEnum` | A vertical structural member | | `IfcMember` | `IfcMemberType` | `IfcMemberTypeEnum` | A generic structural member (brace, mullion) | | `IfcPlate` | `IfcPlateType` | `IfcPlateTypeEnum` | A planar element (sheet, gusset, panel) | | `IfcDoor` | `IfcDoorType` | `IfcDoorTypeEnum` | A door (fills an opening) | | `IfcWindow` | `IfcWindowType` | `IfcWindowTypeEnum` | A window (fills an opening) | | `IfcRoof` | `IfcRoofType` | `IfcRoofTypeEnum` | A roof assembly | | `IfcCovering` | `IfcCoveringType` | `IfcCoveringTypeEnum` | A finish (ceiling, flooring, cladding) | | `IfcStair` | `IfcStairType` | `IfcStairTypeEnum` | A stair assembly | | `IfcRailing` | `IfcRailingType` | `IfcRailingTypeEnum` | A railing (handrail, balustrade) | | `IfcFooting` | `IfcFootingType` | `IfcFootingTypeEnum` | A foundation footing | | `IfcBuildingElementProxy` | `IfcBuildingElementProxyType` | `IfcBuildingElementProxyTypeEnum` | An element with no specific entity | Full enum value lists are in `references/methods.md`. ### A concrete element entity : IfcWall Verified verbatim (IFC4.3) : ``` ENTITY IfcWall SUPERTYPE OF (ONEOF (IfcWallStandardCase)) SUBTYPE OF (IfcBuiltElement); PredefinedType : OPTIONAL IfcWallTypeEnum; WHERE CorrectPredefinedType : NOT(EXISTS(PredefinedType)) OR (PredefinedType <> IfcWallTypeEnum.USERDEFINED) OR ((PredefinedType = IfcWallTypeEnum.USERDEFINED) AND EXISTS (SELF\IfcObject.ObjectType)); CorrectTypeAssigned : (SIZEOF(IsTypedBy) = 0) OR ('IFC4X3_DEV.IFCWALLTYPE' IN TYPEOF(SELF\IfcObject.IsTypedBy[1].RelatingType)); END_ENTITY; ``` The shape is the SAME for `IfcSlab`, `IfcBeam`, `IfcColumn`, `IfcMember`, `IfcPlate`, `IfcRoof`, `IfcCovering`, `IfcStair`, `IfcRailing`, `IfcFooting` : a single OPTIONAL `PredefinedType`, a `CorrectPredefinedType` rule, a `CorrectTypeAssigned` rule. The schema name in `CorrectTypeAssigned` is version-specific. - `CorrectPredefinedType` : if `PredefinedType` is `USERDEFINED`, the inherited `IfcObject.ObjectType` MUST be set. - `CorrectTypeAssigned` : if the occurrence is typed, the type MUST be the matching `*Type` entity (an `IfcWall` is typed only by an `IfcWallType`). ### IfcDoor and IfcWindow : the extra attributes `IfcDoor` and `IfcWindow` carry size and operation attributes the others do not. Verified verbatim (IFC4.3) : ``` ENTITY IfcDoor SUBTYPE OF (IfcBuiltElement); OverallHeight : OPTIONAL IfcPositiveLengthMeasure; OverallWidth : OPTIONAL IfcPositiveLengthMeasure; PredefinedType : OPTIONAL IfcDoorTypeEnum; OperationType : OPTIONAL IfcDoorTypeOperationEnum; UserDefinedOperationType : OPTIONAL IfcLabel; WHERE CorrectPredefinedType : ... CorrectTypeAssigned : ... END_ENTITY; ``` `IfcWindow` is the same shape with `PartitioningType` (`IfcWindowTypePartitioningEnum`) and `UserDefinedPartitioningType` in place of the door's operation attributes. The `OverallHeight` / `OverallWidth` attributes were present in IFC2x3 ; the `PredefinedType` and operation attributes were added in IFC4. See Version Differences and `references/methods.md`. ### Placing an element : IfcRelContainedInSpatialStructure An element is NOT geometrically inside its storey ; it is linked to a spatial level by an objectified relationship. Verified verbatim (IFC4.3) : ``` ENTITY IfcRelContainedInSpatialStructure SUBTYPE OF (IfcRelConnects); RelatedElements : SET [1:?] OF IfcProduct; RelatingStructure : IfcSpatialElement; WHERE WR31 : SIZEOF(QUERY(temp <* RelatedElements | 'IFC4X3_DEV.IFCSPATIALSTRUCTUREELEMENT' IN TYPEOF(temp))) = 0; END_ENTITY; ``` - `RelatingStructure` : the single spatial container (an `IfcBuildingStorey`, `IfcSpace`, `IfcSite`, ...). - `RelatedElements` : the elements placed in it. ALWAYS place every physical element in exactly ONE spatial container through an `IfcRelContainedInSpatialStructure`. NEVER leave an element with no containment link : an uncontained element is an orphan and most viewers will not show it. See `ifc-core-spatial-structure`. ### The opening triad : void then fill A door or window in a wall is THREE relationships, not one. A void is cut into the wall, then the void is filled by the door. ``` IfcWall --[IfcRelVoidsElement]--> IfcOpeningElement --[IfcRelFillsElement]--> IfcDoor ``` Verified verbatim (IFC4.3) : ``` ENTITY IfcRelVoidsElement SUBTYPE OF (IfcRelDecomposes); RelatingBuildingElement : IfcElement; RelatedOpeningElement : IfcFeatureElementSubtraction; END_ENTITY; ENTITY IfcRelFillsElement SUBTYPE OF (IfcRelConnects); RelatingOpeningElement : IfcOpeningElement; RelatedBuildingElement : IfcElement; END_ENTITY; ``` The "Relating" anchor REVERSES between the two : in `IfcRelVoidsElement` the wall is `RelatingBuildingElement` ; in `IfcRelFillsElement` the opening is `RelatingOpeningElement`. `IfcOpeningElement` (a subtype of `IfcFeatureElementSubtraction`) is the void itself ; it carries an OPTIONAL `PredefinedType` of `IfcOpeningElementTypeEnum` (`OPENING`, `RECESS`, `USERDEFINED`, `NOTDEFINED`) and the inverse `HasFillings`. ### Infrastructure elements (IFC4.3 only) IFC4.3 added subtypes of `IfcBuiltElement` for infrastructure. They do NOT exist in IFC2x3 or IFC4 : - `IfcCourse` : a layer of a built-up element (for example a course of bricks). - `IfcKerb` : a kerb / curb edging. - `IfcPavement` : a pavement surface layer. - `IfcRail` : a running rail of a railway. - `IfcBearing` : a structural bearing transferring load between elements. ALWAYS restrict these entities to IFC4.3 files. NEVER write `IfcKerb` or `IfcRail` into an IFC2x3 or IFC4 file. ### Version Differences | Item | IFC2x3 | IFC4 | IFC4.3 | |------|--------|------|--------| | Abstract supertype | `IfcBuildingElement` | `IfcBuildingElement` | `IfcBuiltElement` (renamed, non-abstract) | | Occurrence `PredefinedType` | absent | present | present | | `IfcDoor.OperationType` / `PredefinedType` | absent (operation on `IfcDoorStyle`) | present | present | | `IfcWallStandardCase` | present | present | present but DEPRECATED | | `IfcWallElementedCase` | absent | present | DELETED | | `IfcSlabStandardCase`, `IfcSlabElementedCase`, `IfcBeamStandardCase`, `IfcColumnStandardCase`, `IfcMemberStandardCase`, `IfcPlateStandardCase` | absent | present | DELETED | | Infrastructure elements (`IfcKerb`, `IfcRail`, ...) | absent | absent | present | ALWAYS model a wall as a plain `IfcWall` with an `IfcMaterialLayerSetUsage` instead of `IfcWallStandardCase` : the StandardCase entity is deprecated in IFC4.3 and its siblings were deleted. ## Decision Trees ### Which element entity? ``` What is the physical element? | +-- A vertical space-separating element --> IfcWall +-- A horizontal floor / roof slab / landing --> IfcSlab +-- A horizontal structural member --> IfcBeam +-- A vertical structural member --> IfcColumn +-- A brace, mullion, post, generic linear member --> IfcMember +-- A planar element : sheet, gusset, curtain panel --> IfcPlate +-- A door --> IfcDoor (fills an IfcOpeningElement) +-- A window --> IfcWindow (fills an IfcOpeningElement) +-- A roof assembly --> IfcRoof +-- A finish : ceiling, flooring, cladding --> IfcCovering +-- A stair assembly --> IfcStair +-- A railing : handrail, balustrade, fence --> IfcRailing +-- A foundation footing --> IfcFooting +-- Genuinely none of the above, semantics unknown --> IfcBuildingElementProxy ``` ### A concrete entity or IfcBuildingElementProxy? ``` Does a concrete IFC entity match the element's semantics? | +-- YES --> ALWAYS use the concrete entity (IfcWall, IfcBeam, ...). | +-- NO, it is a real construction element with no matching entity --> IfcBuildingElementProxy, PredefinedType = ELEMENT or USERDEFINED. NEVER use it as a spatial or void placeholder : use IfcVirtualElement. ``` ### Type object : create one or not? ``` Will many occurrences share the same definition (a "300mm cavity wall")? | +-- YES --> create one IfcWallType, attach occurrences via IfcRelDefinesByType. | Shared property sets live on the type's HasPropertySets. | +-- NO, a one-off element --> a bare IfcWall occurrence is valid on its own. If typed, the type MUST be the matching IfcWallType (CorrectTypeAssigned). ``` ### Door or window in a wall : how many relationships? ``` Placing a door into a wall? | +-- Step 1 : create the IfcOpeningElement (the void). +-- Step 2 : IfcRelVoidsElement : RelatingBuildingElement = wall, | RelatedOpeningElement = opening. +-- Step 3 : IfcRelFillsElement : RelatingOpeningElement = opening, RelatedBuildingElement = door. The wall, the opening, and the door are each contained in the spatial structure separately. NEVER skip the opening : a door is never voided into a wall directly. ``` ## Patterns ### Pattern : Place every element in the spatial structure ALWAYS link every physical element occurrence to exactly one spatial container with an `IfcRelContainedInSpatialStructure` : `RelatingStructure` is the storey or space, `RelatedElements` lists the elements. ALWAYS reuse one relationship for many elements in the same storey : `RelatedElements` is a `SET [1:?]`. NEVER leave an element uncontained : an orphan element fails validation and is invisible in most viewers. See `ifc-core-spatial-structure`. ### Pattern : Create an element with a shared type ALWAYS model a definition shared by many occurrences as a `*Type` object (an `IfcWallType` for walls), and link the occurrences with `IfcRelDefinesByType` (`RelatingType` = the type, `RelatedObjects` = the occurrences). ALWAYS type an occurrence only with its matching type entity : the `CorrectTypeAssigned` rule rejects an `IfcWall` typed by an `IfcSlabType`. See `ifc-core-entity-hierarchy` and `ifc-impl-authoring-file`. ### Pattern : Set PredefinedType correctly ALWAYS pick the `PredefinedType` value from the element's own enumeration : an `IfcWall` uses `IfcWallTypeEnum`, an `IfcBeam` uses `IfcBeamTypeEnum`. ALWAYS set the inherited `ObjectType` (`IfcLabel`) when `PredefinedType` is `USERDEFINED` : the `CorrectPredefinedType` rule requires it. ALWAYS use `NOTDEFINED` when the type is genuinely unknown ; NEVER leave `PredefinedType` mismatched to the entity. NEVER write a `PredefinedType` on an element occurrence in an IFC2x3 file : the attribute did not exist on occurrences in IFC2x3. ### Pattern : The door-in-wall void and fill triad ALWAYS create the `IfcOpeningElement` first, then subtract it from the wall with `IfcRelVoidsElement` (`RelatingBuildingElement` = wall, `RelatedOpeningElement` = opening). ALWAYS fill the opening with `IfcRelFillsElement` (`RelatingOpeningElement` = opening, `RelatedBuildingElement` = door or window). NEVER reverse the anchors : the wall is the `Relating` side of the void, the opening is the `Relating` side of the fill. A reversed model is structurally parseable but semantically wrong. A worked STEP triad is in `references/examples.md`. ### Pattern : Honour the version renames ALWAYS write the abstract supertype as `IfcBuildingElement` for IFC2x3 and IFC4, and `IfcBuiltElement` for IFC4.3. ALWAYS model a layered wall as a plain `IfcWall` plus `IfcMaterialLayerSetUsage` : `IfcWallStandardCase` is deprecated in IFC4.3 and `IfcSlabStandardCase`, `IfcBeamStandardCase`, and the other `*StandardCase` / `*ElementedCase` entities were DELETED in IFC4.3. NEVER write an infrastructure entity (`IfcKerb`, `IfcRail`, `IfcBearing`, ...) into an IFC2x3 or IFC4 file : they exist only from IFC4.3. See `ifc-core-entity-hierarchy` for the full type / occurrence model. ## Reference Links - `references/methods.md` : the verified EXPRESS definitions of every element entity, the complete `PredefinedType` enum value lists, `IfcOpeningElement`, the three relationship entities, and the per-version difference detail. - `references/examples.md` : worked STEP scenarios : a wall with a type, spatial containment, the full door-in-wall void/fill triad, a window, a beam with a PredefinedType, and a proxy element. - `references/anti-patterns.md` : the failure modes this skill prevents, each with the rule it breaks and the reason it fails. ### Official sources - IfcWall : https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcWall.htm - IfcDoor : https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcDoor.htm - IfcWindow : https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcWindow.htm - IfcOpeningElement : https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcOpeningElement.htm - IfcRelContainedInSpatialStructure : https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcRelContainedInSpatialStructure.htm - IfcRelVoidsElement : https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcRelVoidsElement.htm - IfcRelFillsElement : https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcRelFillsElement.htm - IfcBuiltElement : https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcBuiltElement.htm ### Related skills - `ifc-core-entity-hierarchy` : the `IfcProduct` to `IfcElement` to `IfcBuiltElement` chain, the type / occurrence model, the `IfcBuildingElement` rename. - `ifc-core-relationships` : the objectified-relationship pattern and the full `IfcRel*` reference table. - `ifc-core-spatial-structure` : `IfcRelContainedInSpatialStructure` versus `IfcRelReferencedInSpatialStructure` and the orphan-element rule. - `ifc-syntax-property-sets` : attaching `Pset_WallCommon` and other property sets. - `ifc-impl-authoring-file` : assembling a complete element into a valid file.