Several of us have been involved in conversations over the last couple of years about the “modernization” of IFC. I looked carefully to see if there was already a thread here addressing this issue specifically, and couldn’t find one, so early apologies if this is already addressed elsewhere.
First, I’ll start with a couple of existing discussions in the public realm on this topic. I wrote a Github issue for IFC-gen a little while back which, while not tackling IFC modernization directly, focuses on one aspect of that modernization which is a singular representation of the schema and its storage in Github. @jonm has already noted that a move to Github is under way.
@TimDavies wrote a blog post recently that captures a number of issues quite well. I wrote a somewhat ranty twitter thread in response, recapitulating stuff that I’ve talked about with @dennisshelden and others.
@yorik mentioned in a FreeCAD BIM development news post that he’s working to “decouple” geometry creation and BIM semantics. His commentary there aligns with some things in the post by Tim that I earlier referenced around the size of IFC. Why do we have hundreds of entity types in the IFC spec when entities are just a representation, some properties, and some relationships?
And finally, I’ll provide the issues that I’ve talked about with members of this group before, but have not recorded in the open. These issues come from working very closely writing IFC parsing and code generation infrastructure over the last two years and starting to build a cloud-services business where we’re generating IFC data. Please keep in mind that these are not criticisms, just observations. I know that there were, at the time that many of these things were decided, good reasons for doing them.
- IFC is designed to store stuff in files. I’ve actually had someone who was been involved in the IFC conversation for some time tell me that this is for archival purposes. Anyone who has IFC workflows for real projects currently will tell you that this is a bad setup. BIM data has outgrown file-based workflows. I also don’t buy the idea that we’ll be able to open a 2gb IFC file that we “archived” at any point in the future.
- IFC is designed so that you have to have a “project” with at least one “building”. I’ve worked on lots of projects for which artificially injecting a “building” is just weird. During my time at Buro Happold, we worked on lots of canopies covering existing spaces for example.
- IFC relationships are built for querying in relational databases. For many workflows, especially those in the cloud using nosql dbs, this is just bloat. Most developers, myself included, make the initial mistake of mapping IFC relationships to types in their class hierarchies when they can be better expressed as interfaces.
- EXPRESS or XSD. Choose one. For things like functions and rules that are currently encoded in the EXPRESS schema but almost universally not implemented in software libraries derived therefrom, just author a nice specification document. Specs are written like this all the time. Better to have something that we all can read, then to have something that we all ignore.
- To echo @TimDavies comment about naming: get rid of the “Ifc” prefix. This seems like a vestige of a time when programming languages didn’t have namespaces so you had to prefix everything. I’m reminded of my days as an iOS developer where all the APIs were called stuff like “NSObject”, which stood for NeXTSTEP.
- Break up the specification into modules corresponding to the “domains”. It’s currently impossible using automated code generation from the spec to put stuff into modules, namespaces, etc. based on the domain because you just have one enormous spec.
- The IfcDoc tool hampers adoption. This is probably the most controversial thing I’ll say in this entire conversation. If our first response to someone who wants to get started using the specification of IFC to build software libraries or other tooling for IFC is to download a windows-only application that contains the ability to generate documentation, mvds, etc. it’s too much.
- Automate IFC validation. We should seriously consider adopting serialization formats for which there is abundant validation tooling available today, for free. As an example I can go to this JSON schema validator, enter my schema and my JSON and immediately be told what’s broken. JSON schema validation is built into development environments like Visual Studio Code and Visual Studio as well. If you don’t think this is important, I invite you to try and write a valid IFC file by hand. I know there is tooling for XSD validation as well, but I have yet to see a workflow where someone is using this in an automated way with IFC xmls or mvdxmls. Could be that I’m not looking hard enough.
- Find a better solution for SELECT types in EXPRESS. SELECTs are very powerful, but don’t have a good representation in many C-like programming languages. Language like Typescript with support for discriminated unions handle SELECTs better. This makes support for SELECTs across languages problematic. Also, many SELECT types are SELECT of SELECT which is mind-boggling. I’d be interested to see how these are handled in XML.
- Consider publishing and supporting a set of schemas for web-based workflows. I realize that IFC is often serialized to XML. But is this representation the most compact representation that can be made? As workflows move to the cloud, LOTS of data is going to be passed around. Someone is going to pay for all of that and the difference between storing points as
x: 5, y:5, z:5and
[5,5,5]is going to add up.
This is my short list of issues that I’ve had discussion around over the past months. I invite you all to comment on these or add the issues that you would like to see as part of the modernization discussion as well.