SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsifc-core-version-evolution

ifc-core-version-evolution

General & other

View repository

Updated 10-15 22:18

About this skill

IFC Core : Version Evolution

IFC has evolved across four published schema generations (IFC2x3, IFC4, the withdrawn IFC4.1 / IFC4.2 stepping-stones, and IFC4.3) plus the in-development IFC5 / IFCx. Each step added entities and, critically, introduced renames and deprecations that break files across versions. This skill is the reference for what changed and when. It is the read-side counterpart to ifc-impl-version-migration, which covers the how-to of migrating a model.

Quick Reference

Version ledger

Version Schema identifier ISO publication Released Status
IFC2x3 TC1 IFC2X3 ISO/PAS 16739:2005 2007-07 Official (legacy)
IFC4 IFC4 ISO 16739:2013 2013-02 Retired
IFC4 ADD2 TC1 IFC4 ISO 16739-1:2018 2017-10 Official
IFC4.1 IFC4X1 none 2018-06 Withdrawn
IFC4.2 IFC4X2 none 2019-04 Withdrawn
IFC4.3 ADD2 IFC4X3 / IFC4X3_ADD2 ISO 16739-1:2024 2024-04 Official (current)
IFC5 / IFCx none none unreleased In development

ALWAYS target one of the three Official versions : IFC2x3 TC1, IFC4 ADD2 TC1, IFC4.3 ADD2. NEVER target IFC4.1 or IFC4.2 : both are Withdrawn stepping-stones, fully superseded by IFC4.3. NEVER target IFC5 or IFCx for production : both are in development and subject to change.

Full per-release ledger with release purposes : references/methods.md.

The hard renames (the breaking-change shortlist)

These changes mean a file written for one version is NOT automatically valid in another. ALWAYS use the name that matches the file's FILE_SCHEMA.

Item IFC2x3 IFC4 IFC4.3
Built-element supertype IfcBuildingElement (abstract) IfcBuildingElement (abstract) IfcBuiltElement (non-abstract)
System supertype IfcSystem IfcSystem / IfcBuildingSystem IfcBuiltSystem (IfcBuildingSystem deprecated)
IfcRoot.OwnerHistory mandatory optional optional
IfcSpace interior/exterior InteriorOrExteriorSpace attribute PredefinedType (IfcSpaceTypeEnum) PredefinedType
IfcMonetaryUnit.Currency IfcCurrencyEnum IfcLabel IfcLabel
IfcSIUnit.Dimensions DERIVED explicit attribute explicit attribute
Civil elements n.a. IfcCivilElement IfcCivilElement deprecated

IfcClassification.Location was renamed Specification in a later IFC4 edition. See references/methods.md for the complete rename and attribute-change table.

IFC2x3 to IFC4 : key additions

  • Tessellated geometry : IfcTessellatedFaceSet, IfcTriangulatedFaceSet, and the RepresentationType value 'Tessellation'. Absent in IFC2x3.
  • Advanced geometry : NURBS, advanced B-rep, B-spline surfaces, new elementary surfaces and intersection curves (IFC4 ADD2).
  • 4D / 5D workflows : enhanced scheduling and cost support.
  • mvdXML and concept templates : the technology for defining Model View Definitions, plus integrated ifcXML4.
  • Material refinements : IfcMaterialConstituentSet, IfcMaterialProfileSet; the material-property subtypes (IfcMechanicalMaterialProperties and siblings) were deleted and consolidated into IfcMaterialProperties.

IFC4 to IFC4.3 : key additions

  • Infrastructure domains : Railways, Roads, Ports, Waterways, plus geotechnics and earthworks.
  • 62 new occurrence entities with corresponding type entities, and 294 new predefined types, largely for infrastructure.
  • Alignment and Linear Placement (per ISO 19148) and IfcFacility / IfcFacilityPart, introduced through IFC4.1 / IFC4.2 and consolidated in 4.3.
  • Facility restructuring : IfcBuilding became a subtype of IfcFacility and IfcBuildingStorey a subtype of IfcFacilityPart. The inheritance chain itself moved, not just new entities added.

Decision Trees

Is a feature or entity available in my target version?

Which feature?
|
+-- Tessellation (IfcTriangulatedFaceSet, IfcPolygonalFaceSet)
|   --> IFC4 and IFC4.3 only. NEVER in IFC2x3 (use IfcFacetedBrep there).
|
+-- NURBS / advanced B-rep (IfcAdvancedBrep, IfcBSplineSurface)
|   --> IFC4 and IFC4.3 only. NEVER in IFC2x3.
|
+-- Infrastructure (IfcRoad, IfcRailway, IfcBridge, IfcAlignment,
|   IfcLinearPlacement, IfcCourse, IfcKerb, IfcRail)
|   --> IFC4.3 only. NEVER in IFC2x3 or IFC4.
|
+-- IfcFacility / IfcFacilityPart
|   --> IFC4.3 (introduced via IFC4.2). NEVER in IFC2x3 or IFC4.
|
+-- Buildings, walls, slabs, properties, materials, classifications
    --> All versions (with the renames in the table above).

How to handle a version-specific entity name

Read the file's FILE_SCHEMA in the STEP header.
|
+-- FILE_SCHEMA = 'IFC2X3'
|   --> Use IfcBuildingElement, IfcBuildingSystem.
|       OwnerHistory is mandatory on every IfcRoot subtype.
|
+-- FILE_SCHEMA = 'IFC4'
|   --> Use IfcBuildingElement (still abstract), IfcBuildingSystem.
|       OwnerHistory is optional.
|
+-- FILE_SCHEMA = 'IFC4X3' or 'IFC4X3_ADD2'
    --> Use IfcBuiltElement (non-abstract), IfcBuiltSystem.
        IfcCivilElement and IfcBuildingSystem are deprecated.

Additive change or breaking change?

Did the version add a NEW entity / type / property?
|
+-- YES, and nothing existing was renamed or removed
|   --> ADDITIVE. An older file stays valid; the new feature is
|       simply unavailable to older readers.
|
+-- An entity was RENAMED, made abstract/non-abstract, or REMOVED
|   --> BREAKING. The file is NOT valid across the boundary without
|       migration. Route to ifc-impl-version-migration.
|
+-- An attribute changed (DERIVED <-> explicit, type changed,
    cardinality changed, reordered)
    --> BREAKING at the attribute level. A blind attribute copy fails.
        Route to ifc-impl-version-migration.

Patterns

Pattern : Detect a file's schema version before anything else

ALWAYS read FILE_SCHEMA from the STEP header before interpreting any entity. The header's third clause names the exact schema the file claims to follow :

FILE_SCHEMA(('IFC4'));

ALWAYS branch entity-name choices on that value. NEVER assume a .ifc file is IFC4 : a file with a .ifc extension can be any of IFC2x3, IFC4, or IFC4.3. NEVER trust the file extension or a viewer's label over FILE_SCHEMA.

For ifcXML the schema is named in the document's schema reference instead of FILE_SCHEMA; for ifcJSON it is a metadata key. See ifc-syntax-step-physical-file.

Pattern : Honour the hard renames

IfcBuildingElement was renamed to IfcBuiltElement and made non-abstract in IFC4.3. The official IFC4.3 CHANGE note states verbatim : "The entity has been renamed from IfcBuildingElement and made non abstract." The old name IfcBuildingElement returns HTTP 404 in the IFC4.3 lexical documentation.

  • ALWAYS use IfcBuildingElement for IFC2x3 and IFC4 content.
  • ALWAYS use IfcBuiltElement for IFC4.3 content.
  • NEVER write IfcBuildingElement into an IFC4X3 file : it is a file-breaking error, not a harmless alias.
  • In IFC4.3, IfcBuiltElement is non-abstract and MAY be instantiated directly when no concrete subtype fits. In IFC4 and IFC2x3, IfcBuildingElement is abstract and NEVER instantiated directly.

The same discipline applies to IfcBuildingSystem to IfcBuiltSystem (IFC4.3), and to IfcSpace.InteriorOrExteriorSpace becoming PredefinedType in IFC4. The full table is in references/methods.md.

Pattern : Treat deprecated entities as import-only

An entity marked Deprecated still exists in the schema and a reader MUST still parse it, but a writer MUST NOT emit it.

  • IfcWallStandardCase is Deprecated since IFC4 ADD2 TC1 (schema version 4.0.2.1). Its IFC4 changelog entry reads "Status changed to Deprecated" and the documentation states "This definition may be imported, but shall not be exported by applications." It is still present in IFC4.3, still marked deprecated, with the note "This definition will be removed in a future major release of this standard."
  • ALWAYS author plain IfcWall (with IfcMaterialLayerSetUsage for layered walls) instead of IfcWallStandardCase.
  • The *StandardCase pattern is deprecated across element types : IfcBeamStandardCase, IfcColumnStandardCase, IfcMemberStandardCase, IfcPlateStandardCase, IfcSlabStandardCase, IfcDoorStandardCase, IfcWindowStandardCase, IfcOpeningStandardCase. ALWAYS annotate per-version : some existed in IFC4 and were removed later in the IFC4.x line. NEVER blanket-state "all StandardCase entities are removed in IFC4.3" : IfcWallStandardCase is still in the IFC4.3 schema as a deprecated entity.
  • NEVER use IfcBuildingElementProxy as a spatial or void placeholder in IFC4.3 : the IFC4.3 CHANGE note directs use of IfcVirtualElement instead.

IFC4.3 deprecated 24 entities, explicitly including IfcBuildingElement, IfcCivilElement, and IfcBridgePart. The deprecated-entity inventory and the per-version status of each *StandardCase entity are in references/methods.md.

Pattern : Cover IFC4.1 and IFC4.2 as stepping-stones, not skips

IFC4.1 and IFC4.2 are Withdrawn, but they are where infrastructure support entered the schema : IFC4.1 introduced alignment description (horizontal and vertical) and Linear Placement per ISO 19148; IFC4.2 introduced IfcFacility, IfcFacilityPart, IfcBridge, IfcBridgePart, IfcBearing, and IfcDeepFoundation. These were consolidated into IFC4.3.

  • NEVER describe IFC4.3 as jumping straight from IFC4 : the alignment and facility model matured through 4.1 and 4.2 first.
  • NEVER produce or request files with FILE_SCHEMA(('IFC4X1')) or (('IFC4X2')) : target IFC4.3 instead.

Pattern : Position IFC5 and IFCx as the next generation

IFC5 and IFCx are in development and not released : every claim about them is a moving target and MUST be labelled as such.

  • IFC5 is the next-generation standard : a composition / layering model with prim-style inheritance, multi-author non-destructive layers, and TypeSpec as the schema language replacing EXPRESS.
  • IFCx is the JSON data encoding of the IFC5 generation (the .ifcx extension). It uses a node-and-attribute graph and is not a STEP format.
  • IFC5 / IFCx break from STEP entirely : no ISO-10303-21 syntax, no FILE_SCHEMA header.
  • ALWAYS state "IFC5 / IFCx are in development, subject to change" when referencing them. NEVER present an IFC5 entity name or an IFCx structure as stable. NEVER recommend IFC5 / IFCx for a production exchange.

For the architecture of these, see ifc-core-ifc5-architecture and ifc-core-ifcx-architecture.

Pattern : Decide whether a change is the migration skill's job

This skill is reference : what changed and when. The moment the task is transforming a model from one version to another, route to ifc-impl-version-migration, which covers the two-stage entity-then-attribute remap, the lossy nature of migration, and why upgrade is more stable than downgrade. NEVER attempt an attribute-level remap from this skill alone.

Reference Links

  • references/methods.md : full release ledger, complete rename and attribute-change table, deprecated-entity inventory, *StandardCase per-version status, FILE_SCHEMA identifier table.
  • references/examples.md : worked scenarios : reading FILE_SCHEMA, resolving an entity name per version, classifying a change as additive or breaking, spotting a wrong-version entity.
  • references/anti-patterns.md : the version mistakes this skill prevents, each with the reason it fails.

Official sources

Related skills

  • ifc-core-standards-overview : what IFC is and which version to target.
  • ifc-impl-version-migration : how to migrate a model between versions.
  • ifc-errors-version-mismatch : diagnosing wrong-version-entity errors.
  • ifc-core-ifc5-architecture : the IFC5 composition model.
  • ifc-core-ifcx-architecture : the IFCx JSON encoding.