Ifc Impl Library Selection

ifc-impl-library-selection

IN DEVELOPMENT : subject to change. IFC5 and IFCx are not released standards. The IFCx Rust tooling named in this skill is emerging and unverified ; treat that row as a moving target. The IFC2x3, IFC4, and IFC4.3 library guidance below is stable.

This is a POINTER skill. It routes a reader to the right IFC implementation library and to the OpenAEC skill package that owns that library's detail. It does NOT teach any library API. The IFC skill package teaches the IFC standard itself : schema, entities, formats, geometry, version evolution. Library APIs, installation, and code belong to the dedicated per-library packages.

For the IFCx data format see ifc-core-ifcx-architecture. For changing a file's schema version see ifc-impl-version-migration.

Quick Reference

The package-boundary rule

• ALWAYS treat a library as a pointer here : name it, state what it does, route to the owning package. NEVER write library API calls, install commands, or code snippets in this package.
• ALWAYS pick the library by language, platform, and target IFC version, in that order. The language is the hardest constraint : a .NET project cannot consume a Python library.

The library landscape

NEVER assert an IFC version a library supports beyond the "verified" column. When a project needs a version not listed as verified, route the reader to the owning package or project to confirm.

Routing to the owning OpenAEC package

Hard rules

• ALWAYS match the library language to the project language first. This filters the list before any other criterion.
• ALWAYS route library API questions to the owning package. This skill answers "which library", never "how to call it".
• NEVER recommend IfcConvert for changing an IFC schema version : it is a geometry / file-format converter. Schema-version migration is the ifcpatch Migrate concept. See ifc-impl-version-migration.
• NEVER assert a concrete repository for IFCx Rust tooling. No ifcx-rs repository is verified to exist. Refer to it only as "emerging Rust tooling for IFCx".
• NEVER present a community Rust project as an OpenAEC package.

Decision Trees

Which library for which language and platform?

What language and platform is the project?
|
+-- Python (data pipeline, automation, server, CLI)
|   --> IfcOpenShell        owning package : Blender-Bonsai-ifcOpenShell-Sverchok
|
+-- TypeScript / JavaScript, runs in a browser or Node.js
|   --> web-ifc             owning package : ThatOpen
|
+-- C# / .NET (desktop or server)
|   --> xBIM Toolkit        no OpenAEC package : xBIM project docs
|
+-- C++ (native, high-performance desktop)
|   --> IfcOpenShell (C++ core) or IFC++
|   --> IfcOpenShell owning package : Blender-Bonsai-ifcOpenShell-Sverchok
|
+-- Rust
|   --> emerging only : see the IFC5 / IFCx branch below
|
+-- Blender add-on / 3D authoring inside Blender
    --> Bonsai (built on IfcOpenShell)
        owning package : Blender-Bonsai-ifcOpenShell-Sverchok

Which library for which target IFC version?

What IFC version must the project read or write?
|
+-- IFC2x3 or IFC4
|   --> any of IfcOpenShell, web-ifc, xBIM (all cover this range)
|
+-- IFC4.3 (infrastructure : roads, rail, ports)
|   --> IfcOpenShell has verified IFC4.3 coverage.
|       For web-ifc, confirm IFC4.3 coverage with the ThatOpen package.
|       xBIM verified coverage is IFC2x3 and IFC4 only : confirm IFC4.3
|       support with the xBIM project before relying on it.
|
+-- IFC5 / IFCx (.ifcx JSON)
    --> see the next tree : tooling is emerging, not production-ready

IFC5 / IFCx tooling : emerging

Does the project target IFC5 / IFCx (.ifcx JSON) ?
|
+-- Yes
|   --> Tooling is in development. IFC5 and IFCx are not released standards.
|       NEVER treat IFC5 / IFCx library support as production-ready.
|       Rust tooling for IFCx exists only as emerging work : NEVER assert a
|       concrete repository. Community Rust projects exist (clearly labelled
|       community, NOT OpenAEC). See ifc-core-ifcx-architecture.
|
+-- No  --> use the language / version trees above.

Library question, or API question?

What is being asked?
|
+-- "Which library should this project use?"
|   --> this skill : the decision matrix above
|
+-- "How do I call this library / install it / write this code?"
    --> NOT this skill. Route to the owning package :
        IfcOpenShell  -> Blender-Bonsai-ifcOpenShell-Sverchok package
        web-ifc       -> ThatOpen package
        xBIM, IFC++   -> the project's own documentation

Patterns

Pattern : select by primary language first

ALWAYS filter the library list by the project's implementation language before weighing any other factor. A library is only usable from its own language ecosystem : IfcOpenShell from Python or C++, web-ifc from TypeScript or JavaScript, xBIM from .NET. The language constraint is absolute and removes most of the table immediately.

Pattern : select by deployment target

After the language filter, confirm the deployment target fits :

• Browser or Node.js front end : web-ifc compiles to WebAssembly and runs client-side at near-native speed.
• Desktop or server batch processing : IfcOpenShell (Python or C++) and xBIM (.NET) run natively without a browser runtime.
• Inside Blender : Bonsai, which is built on IfcOpenShell.

Pattern : route to the owning package

Once a library is chosen, ALWAYS hand off API detail to the owning OpenAEC package : IfcOpenShell to the Blender-Bonsai-ifcOpenShell-Sverchok package, web-ifc to the ThatOpen package. For xBIM and IFC++ there is no OpenAEC package : route the reader to the project's own documentation. This skill stops at the recommendation ; it never crosses into API teaching.

Pattern : handle an IFC5 / IFCx request honestly

When a project asks for IFC5 / IFCx (.ifcx) support, state plainly that IFC5 and IFCx are in development and that tooling is emerging, not production-ready. Name Rust tooling only as "emerging" : NEVER assert a repository such as ifcx-rs, which is unverified. If a Rust pointer is needed, community projects exist and MUST be labelled community projects, never OpenAEC packages. Route the reader to ifc-core-ifcx-architecture for the format itself.

Pattern : do not confuse the two "convert" tools

A reader asking to "convert an IFC file" wants one of two unrelated things. Changing the IFC schema version is the ifcpatch Migrate concept, covered by ifc-impl-version-migration. Converting IFC geometry into a mesh or non-IFC format (OBJ, glTF, DAE) is IfcConvert. NEVER recommend IfcConvert for a schema-version change. Both tools' API detail belongs to the Blender-Bonsai-ifcOpenShell-Sverchok package.

Reference Links

• references/methods.md : the full library landscape detail, capabilities, owning packages, verification status, source URLs.
• references/examples.md : worked library-selection scenarios by language, platform, and target version.
• references/anti-patterns.md : the library-selection mistakes and why each one fails.

Related skills : ifc-core-ifcx-architecture, ifc-impl-version-migration, ifc-impl-format-transcoding, ifc-core-validation.

Authoritative sources (see SOURCES.md) :

• IfcOpenShell : https://ifcopenshell.org/ and https://docs.ifcopenshell.org/
• web-ifc : https://github.com/ThatOpen/engine_web-ifc
• xBIM : https://docs.xbim.net/
• IFC++ : https://ifcquery.com/
• IFC5 development : https://github.com/buildingSMART/IFC5-development