Often a discussion topic seems to divert to the topic of IFC being STEP/Express and it’s evident that many involved would like to see more modern exchange formats.
Here’s a discussion thread particularly on this topic.
Let’s start here: https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/link/chapter-1.htm
The Industry Foundation Classes specify a data schema and an exchange file format structure
This data schema is then officially published into Express data model definitions, and the vast majority of implementations use STEP formatting of project data to exchange this. An XSD is also published, permitting xml to be used for the exchange in a reliable manner.
You can also note this statement within the scope
Alternative exchange file formats may be used if they conform to the data schemas.
There is no obligation to use EXPRESS for Industry Foundation Classes (which is an object oriented data schema independent of the programming language they are represented in and independent of the exchange format used to pass the data model from one process to another).
You can of course utilize a service to convert from one format to another if your implementation needs to receive or transmit models in formats not directly supported.
Already there have been efforts within buildingSMART to extend the documentation to offer other data exchange formats including Turtle and json. Others can be proposed and tested, and if they are popular then and effective then it might be that STEP is retired from common use at some point in the future (but for legacy I expect will still be recognized and supported).
As discussed in the summit at Dusseldorf, there have been changes implemented for IfcDoc ( the editor of the definition of IFC) and the IFC data schema should soon be published and available in a user friendly way that can have version control applied. I believe this will make it much clearer that whilst IFC is founded in express, it actually is isolated.
I would note that Express is a very efficient means to define the data model, and part of the challenge with other schema formats is how to nominate aspects such as Rules, Functions etc (for that reason many would like to see them removed).
I would also note that there is a lot of improvements to make to the data schema (including simplification). I do believe that this ability to apply version control to the data schema will make a huge difference in allowing a larger group to work on improvements and test proposals etc in a faster and more efficient manner.
