IFC5 as a Web-friendly format #95
Description
Proposal: IFC5 as a Web-friendly format
Motivation
Current IFC (STEP/EXPRESS) is too heavy for web and modern programming stacks. IFC5 should be lightweight, streamable, and easy to integrate into existing ecosystems.
Key points
• Primary format: JSON (+NDJSON for streaming), strict JSON Schema.
• Geometry: glTF-first (meshes, PBR), IFC metadata stays in JSON.
• Packaging: Optional ZIP (IFC5-Pack) with manifest.json + JSON + GLB.
• IDs: Deterministic (ULID/UUIDv7), references by ref or uri only.
• Units/coords: Explicit SI units, EPSG codes for CRS.
• Stream-friendly: Partial downloads, chunked HTTP.
• Core + extensions: Minimal kernel, domain modules as add-ons.
• Cross-language libraries: Design should allow easy library implementation in C, C++, Java, Python, .NET and others without heavy dependencies.
Goal
Make IFC5 simple to generate in Node/Go/Python backends and trivial to view in browsers (WebGPU, Three.js, etc.), while enabling lightweight SDKs in all major languages (C/C++/Java/Python/.NET).
Open Questions
• Should IFC5-JSON be strictly lossless to IFC4x3, or a pragmatic subset?
• Should streaming geometry (progressive meshes) be part of the core or an extension?
• Should we standardize a REST/GraphQL interface for web APIs?
Note on ISO compatibility
This proposal could be fully ISO-compliant if handled as an official serialization alongside the core EXPRESS (or its successor) definition.
• The formal model would remain in EXPRESS/EXPRESS-like language for long-term stability.
• IFC5-JSON (with JSON Schema) and IFC5-Pack (ZIP + glTF + manifest) could be defined as alternative serializations, similar to how IFC-XML is standardized today.
• This keeps IFC5 both formally rigorous for ISO requirements and practical for web, cloud, and cross-language SDKs.
Such an approach ensures IFC5 is future-proof, while still being lightweight enough for modern programming environments (C, C++, Java, Python, .NET, etc.) and web platforms (WebGPU, Three.js, etc.).