Ensure that SELECT entities only contain somewhat equivalent data types

[pipauwel]

I suggest ensuring that the EXPRESS data types included in SELECTs are equivalent in kind. EXPRESS allows mixing ENTITY, SET, STRING, and anything else into one SELECT, but this creates awkward structures in any other language.

There are a few examples / few cases. #19 is one of them.

[SergejMuhic]

I would be in favor of that but the current projects (infra extensions) are doing the opposite. :)

The selects are quite tricky to implement as I am not aware of structures that would mimic them.

[pipauwel]

I tend to translate SELECTs to a subtype and supertype hierarchy. This is of course extra difficult if subtypes of one type are 'LIST' and 'WALL' and 'INTEGER'.

A more drastic change might be to not use SELECTs and instead confine to subtype and supertype hierarchies.

[SergejMuhic]

@pipauwel Sure, in that case it is okay. But as I mentioned the infra extensions are using the selects substantially and it went into Enumerations also. So, now you have PredefinedType attributes referencing selects of Type Enumerations. :)

[hlg]

I fully support the original proposal. There are 7 "mixed" selects, 6 have both Entity types and Defined types in their selection and 1 has both Entity types and Enumeration in its selection:

• IfcAppliedValueSelect
• IfcColourOrFactor
• IfcHatchLineDistanceSelect
• IfcMetricValueSelect
• IfcPropertySetDefinitionSelect
• IfcTrimmingSelect
• IfcPresentationStyleSelect

All other selects have either pure Entity type or pure Defined type selections.

Converting type selection to inheritance would mean to embrace multiple inheritance, which is possible in EXPRESS, but I believe IFC has deliberately waived. If selects are used like marker interfaces, they allow for a "light-weight" multiple inheritance where all attributes have single inheritance. This is a good compromise to avoid ambiguities such as the "diamond problem". The same can be achieved if selections are replaced by subtyping, but then it is harder to keep track of and ensure the single inheritance tree for attributes.

I think it is easier to make sure that there are no "mixed" selects, as Pieter suggests. Then this should easily map to other meta models with different takes on multiple inheritance.

[pbourreau]

"...to embrace multiple inheritance, which is possible in EXPRESS, but I believe IFC has deliberately waived"

I am by far not the most experienced person on IFC, but: what is the reason for avoiding multiple inheritance? This is something that striked me when I first had a look at the IFC schema. Object-oriented representation (and therefore UML) is based on multiple inheritance, the most mainstream OO languages are now handling it. Inheritance is simple and powerful, so, unless there are some clear historical reasons for avoiding using multiple inheritance, could not we reconsider it? As already discussed in a previous issue (I can't find anymore), even the PSet mechanism can be transformed into class inheritance, and this would flatten the path from the class to its properties.

[berlotti]

Reconsider SELECTs that are currently in the schema, and try to avoid them in the schema. Use Interfaces in other languages (like UML), but only in a way that the interfaces can be represented as SELECT in EXPRESS.

Follow-up: case by case evaluation of SELECT