.IFC File Format – File forms and versions

Parts of the standard

The documentation’s introduction lists four parts:

Names of types, entities, rules and functions start with Ifc followed by English words in CamelCase, with no underscores; attribute names are CamelCase with no prefix. The standard is also published by ISO as ISO 16739-1, prepared by ISO/TC 59, SC 13. The ISO foreword of the 4.3 documentation says this edition cancels and replaces the 2018 edition and that ISO 16739-1 is the only part of the ISO 16739 series published. Annex A gives the ISO location of the schema files as https://standards.iso.org/iso/16739/-1/ed-2/en, that is, edition 2.

The main changes from the 2018 edition, as the foreword lists them: spatial and project structures for infrastructure and civil works; construction elements for infrastructure; revised building constructs; geometric transition curves for alignments; a new placement along alignment curves; new and revised geometric models for sweeping along those curves; removal of constructs deprecated in 2018; and new deprecations. The scope adds that the infrastructure facilities now covered are bridges, roads, railways, waterways and port facilities.

Schema forms

The schema, the property and quantity sets and the usage constraints are authored as a UML class diagram, kept as an XMI file (schemas/IFC.xml in the development repository), and published from it in these forms:

Annex A states that the EXPRESS and XML Schema listings combine all the definitions of clauses 5 to 8 (core, shared element, domain and resource schemas) without comments, and that implementations shall adhere to the schema definition languages. The schemas page lists those schemas and their entities.

Exchange file forms

The scope names these exchange file formats for data that follows the schemas. Alternative formats may be used if they conform to the data schemas.

The documentation does not name file extensions other than .ifc, used for the clear-text examples; see Not confirmed.

The clear-text file

The introduction describes the clear-text file as an encoding of the entity instances that make up the exchange, in which each instance’s attribute values are given as an ordered sequence of unnamed values. The documentation numbers each entity’s stored (direct) attributes in that order: it walks up the supertype chain and lists the attributes of the topmost supertype first, so every rooted entity starts with the four attributes of IfcRoot. Inverse attributes, which describe the relationships pointing at an instance, get no number. Because values are positional, the introduction notes that renaming an entity or inserting an attribute at the start of the sequence makes a file written for an older release nearly impossible to read, while adding an item to an enumeration is fully backward compatible.

#30=IFCWALL('1kTvXnbbzCWw8lcMd1dR4o',$,'Wall 1',$,$,#31,#40,$,.SOLIDWALL.);

The chain is IfcRoot → IfcObjectDefinition → IfcObject → IfcProduct → IfcElement → IfcBuiltElement → IfcWall; IfcObjectDefinition and IfcBuiltElement add no stored attributes. The values of IfcWallTypeEnum are ELEMENTEDWALL, MOVABLE, NOTDEFINED, PARAPET, PARTITIONING, PLUMBINGWALL, POLYGONAL, RETAININGWALL, SHEAR, SOLIDWALL, STANDARD, USERDEFINED and WAVEWALL. The kernel page gives the attributes of the core entities in the same way. How instance names, strings, enumerations and unset values are spelt is ISO 10303-21 syntax; see the STEP page.

Versions and schema identifiers

buildingSMART’s validation service lists the active versions, those neither withdrawn nor retired, with the schema identifier each one uses. Its rule IFC101 accepts only these three identifiers.

The IFC 4.3 documentation generator uses IFC4X3_ADD2 as the schema name for the packaged and ISO builds. Builds made from the development repository between releases use IFC4X3_DEV followed by an underscore and the short Git commit hash, so a file carrying such an identifier was written against an unreleased development state.

What the header carries

The header section of the clear-text file is defined by ISO 10303-21 (see the STEP page). From the IFC side, the sources read establish two uses of it:

• The schema identifier above is the value of FILE_SCHEMA, as in FILE_SCHEMA(('IFC4X3_ADD2'));. The documentation generator rewrites this value in its example files to the current schema name.
• The model view definition a file declares is read by buildingSMART’s validation rules from the first description string of FILE_DESCRIPTION: the text between square brackets in that string is taken as the view’s name, for example ReferenceView or Alignment-basedView. A file whose first description has no bracketed text declares no view.

Model view definitions

A model view definition (MVD) is a subset of the schema meeting particular data requirements, and may add constraints on how that subset is populated. Software is certified against a view. The official MVD policy for IFC 4.3 has three levels, each adding more advanced features:

buildingSMART’s validation rules IFC430 and IFC431 list the entities a file declaring ReferenceView or Alignment-basedView must not contain.

String and time limits

The documentation notes that the characters allowed in strings are those of ISO 10646, and that their encoding in files is set by ISO 10303-21 and ISO 10303-28, so a 255-character label may take considerably more than 255 octets in a file.

Compatibility, deletions and deprecations

Backward compatibility, a file written for an earlier release being readable by software for a later one, is a hard requirement except in rare cases. Changes to property and quantity sets do not change the structure of the ISO 10303-21 file and are not held to the same standard. Forward compatibility is not explicitly considered. A deprecated construct is marked for deletion in a future major release: readers shall still import it, and writers should export the proposed alternative instead.

Deleted in IFC 4.3

These entities, types and functions of ISO 16739-1:2018 (IFC4) no longer exist: IfcBeamStandardCase, IfcBuildingElement, IfcBuildingElementType, IfcColumnStandardCase, IfcCorrectObjectAssignment, IfcDoorStandardCase, IfcDoorStyle, IfcDoorStyleConstructionEnum, IfcDoorStyleOperationEnum, IfcMemberStandardCase, IfcNullStyle, IfcObjectTypeEnum, IfcOpeningStandardCase, IfcPlateStandardCase, IfcPresentationStyleAssignment, IfcPresentationStyleSelect, IfcProxy, IfcSlabElementedCase, IfcSlabStandardCase, IfcStyleAssignmentSelect, IfcWallElementedCase, IfcWindowStandardCase, IfcWindowStyle, IfcWindowStyleConstructionEnum and IfcWindowStyleOperationEnum.

Deprecated in IFC 4.3

The UML model also flags as deprecated, from earlier releases or the 4.3.2.0 addendum: IfcDoorLiningProperties, IfcDoorPanelProperties, IfcPermeableCoveringProperties, IfcWindowLiningProperties, IfcWindowPanelProperties (replaced by property sets such as Pset_DoorLiningProperties), IfcMaterialClassificationRelationship, IfcMaterialList (use IfcMaterialConstituentSet), IfcRelCoversBldgElements, IfcRelCoversSpaces and IfcWallStandardCase. buildingSMART’s rule IFC102 reports all of these in 4.3 files, and also IfcTextLiteral.

Backward incompatibilities

Not confirmed

• The file extensions .ifcXML and .ifcZIP, and how a zipped IFC file is packaged: the documentation read names no extension other than .ifc and does not describe a zipped form. buildingSMART’s validation service says it accepts only non-zipped STEP physical files with the .ifc extension. The buildingSMART technical page on IFC formats, which the scope refers to, could not be read.
• Any IFC-specific rules for the other header entities, FILE_NAME and the remaining fields of FILE_DESCRIPTION, and whether a fixed keyword precedes the bracketed view name: none are given in the sources read.
• The scope and content of the Design Transfer View.
• The structure of IFC JSON and RDF/OWL files, which the documentation lists as under development.

Sources

• IFC4.3.x-development – buildingSMART’s source repository for the IFC 4.3 documentation, master branch: content/introduction.md, content/scope.md, content/iso_foreword.md, content/normative_references.md, content/terms_and_definitions.md, code/templates/annex-a.html, code/server.py and code/xmi_document.py (schema name and file names), schemas/IFC.xml (the UML model: attributes and deprecation flags), and the type pages IfcLabel.md, IfcIdentifier.md, IfcText.md, IfcTimeStamp.md, IfcGloballyUniqueId.md, IfcDoorLiningProperties.md, IfcMaterialList.md, IfcPostalAddress.md
• Validation Service developer guide – buildingSMART’s table of valid schema versions
• Validation Service user guide – upload rules and the schema version check
• ifc-gherkin-rules – buildingSMART’s validation rules: IFC101, IFC102, IFC430, IFC431 and features/steps/utils/ifc.py (how the view name is read)