(reminder to) change from IFC4X3 to IFC4X3_ADD2 about ids

[MatthiasWeise]

This is different from IFC4 where addendums have not been reflected in the schema name (it was IFC4 for all updates).
I also wonder about IFC4X3, which seems to be removed from the bSI list of IFC releases (https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/). Does it still exists and can it be used?
Anyhow, I don't think it is a good idea to change schema name as it most likely will result in confusion/incompatibility in daily practice.

For updating the IDS schema: We don't know how many addendums will be released in the future, so I would prefer a more general agreement for supported schema names, e.g. check the prefix "IFC4X3" and accept all suffixes.

[aothms]

Anyhow, I don't think it is a good idea to change schema name as it most likely will result in confusion/incompatibility in daily practice.

There's no perfect answers to this I think, but at least in the current case we're explicit about the incompatibility.

For updating the IDS schema: We don't know how many addendums will be released in the future, so I would prefer a more general agreement for supported schema names, e.g. check the prefix "IFC4X3" and accept all suffixes.

Within the IfcOpenShell set of tools we're differentiating now between "schema" and "schema identifier". Schema identifier means that exact schema string, whereas just schema does more or less as you propose looking at just the prefix.

Somewhat ironically, earlier on we used the numeric schema identifiers such as 4.3.0.1, which was of course very confusing, but would conceptually somewhat neatly allow to specify either 4.3 (meaning 4.3.x.y for any x or y) or 4.3.0.0 (meaning exactly IFC4X3 without any TC or ADD).

[MatthiasWeise]

There's no perfect answers to this I think, but at least in the current case we're explicit about the incompatibility.

I am not sure if versioning is helpful in that case. My understanding is that an addendum is a bug fix that is backward compatible and should replace the old version (any old IFC4X3 file should still work with IFC4X3_ADD2).

[aothms]

My understanding is that an addendum is a bug fix that is backward compatible

In an ideal world perhaps, but people make mistakes and where we stand now is that while IFC4X3_TC1 is (nearly) compatible with IFC4, it is not fully compatible with IFC4X3 sec. Because IFC4 is an ISO release, compatibility with that was prioritized over compatibility with IFC4X3.

And apart from the it's still good to know the schema used by the exporter without having to reverse engineer that from the instances in the model, because where does that line of thinking stop? Then we also wouldn't have had to have a IFC4X3 schema identifier to begin with.

But sure, I realize there's two sides to this coin. This is probably not the time nor place to discuss this now. This is a given and how are we going to deal with this in IDS? Preferably without having to update the IDS schema ifcVersion enum everytime there is a TC on the IFC schema side.

For me the prefix thing is a reasonable idea, but do keep in mind then that IFC4 != IFC4X3, whereas IFC4X3 == IFC4X3_TC1. We can also (solely internally in implementation or externally in spec) rely on tuples of numbers, IFC4X3_TC1 -> (4.3.0.1).

Options:

1. require exact schema identifiers
2. fuzzy identifier match based on special case string prefix [eg. regex match with negative lookahead for X]
3. fuzzy identifier match based on version tuples [IFC4X3_TC1 -> (4.3.0.1) == (4.3.x.y)]
4. specify version tuples in IDS

(where 2 and 3 give an identical outcome just the wording in the spec is different).

My vote is for 2 or 3

[MatthiasWeise]

This is probably not the time nor place to discuss this now. This is a given and how are we going to deal with this in IDS?

I was not aware about that change coming with IFC4X3. In fact, it is not only about updating the IDS schema (you mentioned some options already). It is also about how we are going to define our checking rules, which would mean that an IDS author must list all IFC4X3 subversions to which it should apply. Thinking about that scenario I would actually argue that defining a requirement for IFC4X3 should be sufficient and should include all addendums.

[evandroAlfieri]

Sorry, I should have added a brief description to the issue, to avoid confusion. I'll try to do it now.

The current IDS schema has an enumeration that says "hey, you can write an IDS only for the (3) official bSI's IFC schema versions"

To do so, I see the schema identifiers (2X3, 4 and 4X3) have been used. Now, as @MatthiasWeise pointed out, for the first two, in the past, different schemas referred to the same identifiers. This was not ideal, but with time most implementers learned that when they see 2X3 it means 2x3 TC1 and 4 means 4 add2 tc1, aka the official versions. Fast forward to recent years, to avoid any misunderstanding, in the development towards 4.3, every new schema, being it a draft, a candidate, an experiment, a temporary one or anything similar, had been given a dedicated identifier. So, the one and only official 4.3 schema (as it will be probably called in the daily practice, just 4.3) is the one that corresponds to 4.3.2.0 with identifier 4X3_ADD2. All intermediate schemas that led to this (I.e., 4X3, RC1,2,3,4...TC1,ADD1 and whatnot) are in fact no longer published, they should really be seen as iterations towards the final one. Best, they shouldn't be seen. Also, backwards compatibility among them was not a criterion for not fix mistakes. Indeed, backwards compatibility was regarded only towards the previous official version (meaning 4.2 if you ask bSI, and 4 if you ask ISO).

Well, reading it I really skipped quite some context. Anyway, having said that, the intent of my issue was: now that we have the ability to be explicit and avoid misunderstanding, let's refer to the one and only official IFC 4.3 schema. Then, if this is done by explicitly encoding the correct identifier in the IDS enumeration; or by using "4.3" or "fourdotthree" or "thatoneschema" plus an agreement among IDS implementers that know which schema is the intended one, I cannot say (well, I have a preference 😉). Hope this brings more context to the original issue. I'm sure the group will quickly find a resolution.

[TLiebich]

well, the discussion, why IFC4.3 releases have different schema identifiers, whereas this was not the case in IFC2x3 and IFC4, is an interesting debate, but the IDS forum is probably the wrong place for it (well, I would have prefered to stick with one schema name, but this is not relevant for the discussion here).

In scope of IDS the main question is: must the IDS file author differentiate between IFC4x3, Add1, Add2, ...? In my view, the clear answer is no. (Note bene, out of my head, the IFC4x3, Add1, Add2 do not differ in regard to the "IDS relevant subset" of IFC, meaning the class identifiers for product and product type subtypes, predefined type enums (here not 100% sure) and the facets.)

so the IFC schema designator in IDS should be for now IFC2x3, IFC4 and IFC4x3. I don not have a preference on how to encode it - see options 2 and 3 by @aothms