IFC Backwards compatibility

[jonm]

There is an interesting thread on twitter (that perhaps would be better suited to being discussed here).
I’d like to at least focus on this response by @fmohus
https://twitter.com/fmohus/status/1133662203553419264

I’ll quote it below for longevity.

I’m sure I should understand the aspect of “backwards compatibility” better. This topic did briefly arise in the last summit, with a notion that perhaps as long as “obsolete” concepts could be structured into a new concept, that concepts might be deprecated and made obsolete.

Certainly IFC Schema Specifications - buildingSMART Technical suggests that major releases can break compatibility.

I’m certainly an advocate of removing say the IfcRoot inheritance of relationships The non-permanent GUIDs

Is there any resources or explanations that explain exactly what the requirements are around backwards compatibility?

Many interesting thoughts, well worth considering for # IFC5 , but keep in mind that # IFC is also an archival format that needs backwards compatibility - In Norway it is even formally National Archives accepted (see §5-17 litra j in this regulation: https://lovdata.no/dokument/SF/forskrift/2017-12-19-2286 …)

[ReD_CoDE]

I don’t know about current topics inside the MSG & ISG, and wasn’t in last summit, but I think IFC at the moment has two vital issues:

1. One is related to its structure which one of the main issues is “backwards compatibility”
2. The second is about the data/information exchange, which fortunately @Moult shared the part of the issue in his insights

The non-permanent GUIDs

+1 on @jonm’s suggestion, assuming there isn’t a usefulness of having UUIDs for things like PSets? For instance, let’s say in an ideal future we can reference one IFC file from another. The architect models a room. He references a IFC files from a sustainability consultant. The sustainability consultant is only responsible for adding relationships and psets, and so therefore ideally his IFC file only contains those relationship and pset definitions. Or maybe the QS has an IFC file that only con…

But this is just a small part of the whole picture

I think the MSG & ISG teams should focus on two areas, one is related to IFC and one to IfcDoc
I will share my insights in the near future, after submitting articles in Automation in Construction journal

[Moult]

Currently there isn’t a single vendor who has stellar IFC support for all features - therefore even current compatibility is lacking, let alone backwards compatibility.

Therefore, I propose a compromise: during the vendor maturity phase while IFC is teething, the spec is allowed to break backwards compatibility. Luckily, the grammatical syntax remains the same, after all, it is just STEP (yes yes I know IFC is a schema, not a format but let’s not get distracted), so vendors won’t crash and burn when given a file which has different information. Vendors can work around with temporarily by offering to support multiple IFC versions. For example, nobody outputs IFC1, and I think I saw somewhere perhaps ArchiCAD is even stopping 2x3, so backwards compat is already broken

When buildingSMART and the community surrounding it naturally recognises IFC vendors reaching maturity, then IFC can adopt a different licensing strategy. I would like to direct your attention to LaTeX. LaTeX is an open-source document typesetting language invented 36 years ago. Yet, I can compile documents written decades ago with modern compilers. This is due to the LPPL license adopted by the LaTeX project. Here’s a snippet from the Wikipedia page, emphasis mine:

The LPPL grew from Donald Knuth’s original license for TeX, which states that the source code for TeX may be used for any purpose but a system built with it can only be called ‘TeX’ if it strictly conforms to his canonical program. The incentive for this proviso was to ensure that documents written for TeX will be readable for the foreseeable future – and indeed, TeX and its extensions will still compile documents written from the early 1980s to produce output exactly as intended. Quoting Frank Mittelbach, the main author of the license:[1] “LPPL attempts to preserve the fact that something like LaTeX is a language which is used for communication, that is if you write a LaTeX document you expect to be able to send it to me and to work at my end like it does at yours”.

So I don’t think it’s necessarily hard, just draw a line in the sand when the community consensus on vendor maturity occurs, and enforce strong spec extension discipline by buildingSMART.

[TLiebich]

Hi, this is an important discussion - how to handle backward compatibility for future releases. A similar and sometimes “heated” discussion happened also during the development process of IFC4. I would like to differentiate between:

• compatibility at file level (ability of an existing IFC importer to accept IFC files serialized against a future schema version)
• compatibility at “service” level - availability of a service to convert IFC files from a higher schema version down to an earlier schema version

in the past the requirements where strict and demanded compatibility of file structure level which restricts the ways the schema can be improved or cleaned up.

[TLiebich]

20110702_IFC4_SchemaCompatibilityAssessment_full.pdf (450.2 KB)

Attached document shows a previous work to deal with compatibility issues between IFC2x3 and IFC4.

[ReD_CoDE]

As I know in ifcwebserver.org you have a project to compare IFC schema but don’t know how does it work?

(It seems that you compare schema structure with IfcOWL or IfcRDF)

I think it would be better have sample STEPs like this, which not only helps programmers write code better, but also cause machine defines code structure better

IFC2x3 physical exchange structure:
#1000= IFCBEAM ('0juf4qyggSI8rxA20Qwnsj',IfcOwnerHistory,'Name','Description','ObjectType',IfcObjectPlacement,IfcProductRepresentation,'Tag');

IFC4 physical exchange structure
#1000= IFCBEAM ('0juf4qyggSI8rxA20Qwnsj',IfcOwnerHistory,'Name','Description','ObjectType',IfcObjectPlacement,IfcProductRepresentation,'Tag',.IfcBeamTypeEnum.);

Now, not only human but also machine can recognize the code structure has one “IfcBeamTypeEnum” and/or “an entity name has changed from X to Y”

So importer and exporter then will recognize those parts that are same, so will convert just those the same parts and inform which parts are not the same and should be upgraded manually or automatically