buildingSMART Forums

IFC Backwards compatibility

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

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 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: …)

1 Like

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

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

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 :slight_smile:

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:

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.

1 Like

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.

20110702_IFC4_SchemaCompatibilityAssessment_full.pdf (450.2 KB)

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

1 Like

As I know in 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