With the evolution of IFC towards more continuous integration, one might wonder how ISO publication will have to evolve. When an ISO standard is ready for publication, there is a specific roadmap to follow, with a series of enquiries and possible comments. With the liaison between ISO/TC 59/SC 13 (where the ISO is published) and CEN/TC 442 (where the EN ISO version is adopted via Vienna Agreement) a published ISO version of IFC becomes a European standard as well and, automatically, a national standard throughout most EU countries.
This can be a good thing (trustworthiness) but also a dangerous thing (defining the content of a standard from outside the actual standardisation activity).
I understand this, as this is where the experts are to develop this work. However, when the time is right to go to publication, the typical interaction of national mirror committees and working groups providing feedback is mostly skipped. At the time the standard is ready for ISO, there is no room anymore for any serious comments, not on editorial level and certainly not on technical level. Rejecting the standard at that time would also be a huge waste of efforts. Accepting it automatically practically circumvents most of the standardisation workflow.
There is no clear solution but to try to make IFC as good as it can be. So I strongly urge all people involved to maximise the communication across these liaisons and ensure that all committees involved are addressed as early as possible, to avoid conflicts later on.
You have to remember that the time for standards publication is long⊠and the time to get to a review of such as standard is even longer (about 5 years). This is completely the opposite of an approach of continuous integration.
However, I also see an opportunity with a more lean and focused new generation of e.g. IFC5 (or later?) to have a more stable kernel and resources layer and having the actual content-related aspects, such as propertysets more independent (and maybe even outside of the standard?).
The main idea is that the core/interoperability layer of âIFC5â would be compact, yet robust and flexible, and the product submitted as an ISO standard, along with specifications for extending the schema via modules. That way, the core/interoperability layer is a long term support product, like the previous IFC2x series (including IFC2x2, 2x3, and 2x4 (IFC4), but the modules on top of that can be more rapidly developed and revised, as needed. This includes documentation as much as functionality. The pursuit of submitting modules to ISO would be possible, but not necessary. It could be that a module is so well developed that its user base decides an ISO âblessingâ is desired. Again, it could go through the process independent of the core IFC ISO standard.
@Hans_Lammerts When @stefkeB talks about âcontinuous integrationâ, he is referring to the current Technical Roadmap proposal that the IFC schema, modules, and documentation would be set up as a code repository (via GitHub) allowing for tools and workflows that enable editing at many different levels and then the automatic generation of products (schema documentation as EXPRESS, XSD, RDF, etc, HTML documents, I/O libraries as C#, C++, etc, etc.) when changes/pull requests have been reviewed and integrated. This would especially be helpful in keeping the HTML documentation current and enable the rapid development and deployment of modules, especially those at the classification/pset layer as described in the Technical Roadmap.
Thank you. It was the presentation by @berlotti that triggered my question. I think having a core package with Long term support is actually ideal to submit to ISO whereas the more thematic modules can evolve quicker, with full industry involvement, but donât necessarily have to go through full standardization.
Complete agree. I think that both parts should consider more collaboration in early stages.
Refereed to IFC5, wich I personally consider that will be the âessential brickâ fir BIM in the XXI century, maybe the best will be to have a BIG BRAINSTORMIG meeting involving all the parts, including other that usually dont appear until itâs too late (governments, big construction companies, small offices, manufacturers, material developers, etc).
Maybe this COVID RESET TIME is the best moment to do it.
Do the advantages of making buildingSMART standards ISO standard outweight the problems? Iâm thinking here mainly about the significant paywall. Many of us via our work donât have to worry about the price of access, but many SMCs do not have access to ISO standards. Would buildingSMART even be able to make free copies available of our own standards to members and supporters?
buildingSMART is already a recognised standards organization in its own right. Isnât that enough?
The ISO published version of IFC is behind a paywall, but the exact same standard (content-wise) is fully accessible via buildingSMART. I think they have a specific publishing agreement for that.
Having IFC as ISO standard helps with pushing industry adoption. It makes it more credible.
It makes it more credible? I think the proof of the pudding comes from actual use of projects and people using it. Not (again) some high professors in standarisation. People donât like being âpushedâ to use standards. Even if they are open. Sorry.
Hans, IFC was there first and because of wide industry adoption (= projects using it, software implementing it) it was deemed worthy to become an ISO standard. Not the other way around.
And now it has ISO status, it is something we can refer to in national and international projects and software vendors can implement in a global market and not simply for one local market.
You often mention DWG as a de-facto standard. Alas, it still is not an international standard and not openly documented. It is only because there are software companies who developed libraries (without help from the authors) that it is also supported in non-Autodesk software. The same thing is happening with the RVT format.
Yes it is nice that you can use such formats for exchange of information, but youâre still left at the discretion of a single company who has their own agenda.
I will Agree IFC should be pushed to software vendors to be Properly Adopt. For the long run we Need to be more transparent as industry (/bim uaers) But i am against making IFC mandatory to use by telling governments they should enforce IFC in contracts. With or without the help of BSI and ISO. It is wrong! IFC in itâs current shape is still weak in my opinion. Image below.
The focus here and from EU legislations should be on software Implementation. My opinion. There is really nothing wrong with using âclosedâ fileformats for projects. Have been doing that for years. Where did this ever go wrong? Examples please.
"There is really nothing wrong with using âclosedâ fileformats for projects. "
It went wrong every time an office had to model the project again for a renovation simply because they had switched software.
It also went wrong every time two software platforms didnât interoperate reasonable well.
It also went wrong every time a client was left with a project file they could not open because they didnât have the software
Iâm sure you get the point.
My impression is that without the insistence of some markets to make use of IFC mandatory there would have been even less pressure for software firms to work on interoperability.
AFAIK, there are already the formal agreements between CEN/TC 442, ISO/TC 59/SC 13 and buildingSMART International. And with what you and other presented on the future of IFC5, I understand better the need to talk about a stable IFC core (= ideal for formal standardisation) versus the more evolving domain-specific packages, which may be updated more frequently and for which the standardization process may be too restrictive.
If there is a more modular schema, certification can also be developed as a more focused process. No need to certify a bridge design software for architectural elements, but speaking the same IFC underneath and at least being able to read and visualise any IFC model is a compelling proposition.
