Which language should you use to check your IFC models?

Cover Image Credit: Link

IDS, mvdXML, Gherkin with Python: three approaches for checking IFC models against exchange requirements. All three come from buildingSMART and solve the same class of problem, but they work quite differently. No systematic study had compared them, so we wrote one.

We tested all three against requirements from two sources: the IDS documentation published by bSI, and the aIfc4Rail project — a bSI initiative dedicated to extending IFC for the railway domain. The central challenge in aIfc4Rail was practical: verify that a railway signal is correctly georeferenced inside an IFC model, at a specific station along a named alignment.

Figure 2 from Jaud, Marie & Pinzenöhler (EC3 2025). IFC entities required to place a signal along an alignment. Solid lines are data connections; dotted lines link entities to their visual representations. Colours correspond to the requirement categories in Table 3 of the paper. — Source: Jaud et al. (2025), EC3 2025 / CIB W78 proceedings.

IDS: the fastest way to get started

IDS is the youngest of the three and the most accessible. Its vocabulary is deliberately narrow — a fixed set of element types and property checks covering existence, values, and predefined types. That constraint is part of the design; the standard was built around the most common requirements from real projects, not around theoretical completeness. Commercial tool support is wide, which matters a lot when team members do not have deep IFC schema knowledge.

For many projects, IDS is simply enough. One pattern that came out of the study: IDS reads like a lightweight version of mvdXML, with a small number of hard-coded functional building blocks taken from the bSI specification. That framing helps explain where it excels and where it runs out of road — the limits become visible quickly when requirements get more specific than existence and property value checks.

mvdXML: more of the IFC structure, at the cost of more effort

mvdXML handles what IDS cannot. It supports cardinality, uniqueness, and logical combinations of rules using AND, OR, XOR, NAND, NOR, and NXOR. Its structure maps closely to the IFC schema itself, which makes it more demanding to author but also gives you genuine control over what gets checked and how. Geometry is still out of scope — that boundary applies to both IDS and mvdXML.

The standard is older and has been successfully used for model checking and software certification. Unlike IDS, where the interpretation of the IFC schema is encoded in documentation that can change independently of the serialization version, mvdXML carries the necessary graph to parse and check directly inside the dataset itself.

Gherkin: plain language, but programming required

Gherkin works differently from the other two. Requirements are written in plain natural language — Given / When / Then steps that anyone on the project can read, regardless of their IFC background. That readability is real and it matters for communication between domain experts and IT implementers.

The catch is that feature files contain only the logic. Executing them requires Python code that implements the step definitions, and that code has to account for the full complexity of the IFC schema. Even a short statement like Given an IfcGroup can result in 25 lines of manually written Python on the bSI reference implementation. Gherkin always involves programming.

It is also the only tool of the three that can handle geometric requirements, and the only one with no hard ceiling on what it can express. That flexibility is real — but only if a validated implementation is already in place. A feature file without a working Python backend is just text.

Figure 3 from Jaud, Marie & Pinzenöhler (EC3 2025). The same railway signal modelled at two levels of geometric detail: a basic atomic shape (left) and a full assembly of individual parts (right). In railway infrastructure, these representations can coexist within one IFC exchange — a scenario that IDS cannot handle without assumptions. — Source: Jaud et al. (2025), EC3 2025 / CIB W78 proceedings; signal geometry from DB Infra GO (2025).

The aIfc4Rail test case: where it gets interesting

The railway example from the aIfc4Rail project is a good stress test for all three tools. Unlike typical vertical BIM models, rail infrastructure does not have clean spatial boundaries. Greenfield projects still connect to an existing network; most work in mature networks involves replacement of existing assets. A specific asset category might be modelled at high granularity while neighbouring objects use simplified representations. The geometry of the same signal can range from a rough silhouette to a full component-level assembly.

Figure 4 from Jaud, Marie & Pinzenöhler (EC3 2025). The spatial-structure-centred test scenario: a railway station with surrounding buildings. White and orange are owned by the asset owner; red belongs to others. The colour distinction is encoded via a custom property, not IFC ownership metadata — and checking it requires different tools depending on how far into the IFC structure the rule reaches. — Source: Jaud et al. (2025), EC3 2025 / CIB W78 proceedings.

This heterogeneity is the reason the comparison matters. A simple key-value check — does this signal have a property set with a station name? — works fine in IDS. But once you need to verify that the signal is correctly linked to an alignment via an IfcLinearPlacement, or that the linear measurement at the station reference is exactly 69.395 m, IDS runs out of functional blocks. mvdXML can cover the structural relationships. Geometry needs Gherkin.

What to use when

Use IDS for simple key-value checks. Use mvdXML when the requirement touches more of the IFC structure. Use Gherkin for geometry — if a validated implementation is already in place.

That recommendation comes directly from the comparison in Tables 2, 3, 4, and 5 of the paper. It is not a ranking. All three tools are governed by bSI and developed on GitHub. They address different points on the complexity curve, and for many real projects the right answer is more than one of them.

One question the paper does not resolve: who checks the checker? A sound process for verifying that different implementations of the same IDS, mvdXML, or Gherkin ruleset produce consistent results does not yet exist. That is a gap worth addressing.

Read the full paper →

Jaud, Š., Marie, S., & Pinzenöhler, A. (2025). The quest for the openBIM exchange requirements checking language: Comparing mvdXML, IDS and Gherkin. In Proceedings of the 2025 European Conference on Computing in Construction & CIB W78 Conference on IT in Construction, Porto, Portugal, July 14–17, 2025.