search

buildingSMART / IFC4.3.x-development

Repository to collect updates to the IFC4.3 Specification
Other
169 stars 86 forks source link

Add Predefined Type attribute to IfcObject #870

Closed Sherstennikov-Igor closed 4 months ago

Sherstennikov-Igor commented 4 months ago

If the "Object Type" attribute was born at the IfcObject level (https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcObject.htm) , which is filled in only when Predefined Type =USER DEFINED, then it is strange not to see it right there attribute "Predefined Type".

This will simplify the schema and its processing.

alexshilo commented 4 months ago

I agree. PredefinedType needs to be placed on the same level as ObjectType. The same applies to ElementType, since it is dependent on PredefinedType.

It might be worth moving the PredefinedType location and moving it to the IfcObject and IfcTypeObject class levels. The ElementType attribute also needs to be moved to the IfcTypeObject class to be consistent with the IfcObject class.

TLiebich commented 4 months ago

while the arguments are understandable, at least with the current technology stack it is not possible to add the predefined type / element type (the different name was due to some IFC2x3 compatibility concerns) at the object / type object level. The individual predefined types are ENUMERATIONs that are specific at each sub type level.

(N.B. even with the current technology it is possible to have EXTENSIBLE ENUMERATION, but reorganizing it would lead to severe compatibility issues).

So to me it is rather an IFC5 consideration.

aothms commented 4 months ago

it is possible to have EXTENSIBLE ENUMERATION

That is one option. The alternative is attribute redeclaration. So having an attribute types as GENERIC and redeclaring the attribute type at the leaf level. But that is also not an option as it's completely obscure technology that doesn't translate to compiled languages.

What could have been done in the past is to not use enumerations at all, but rather string values that are constrained with where rules. That is not a backwards compatible change so will not be made.

Sherstennikov-Igor commented 4 months ago

So to me it is rather an IFC5 consideration.

Yes, it would be great to plan in the framework of IFC 5.0.0.0. It is also necessary to revise the "Predefined Type". In some class, Type are divided according to various criteria, which does not allow using both criteria at once. For example: https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcPileTypeEnum.htm

BORED, DRIVE, JET GROUTING - division pile by type of sinking

COHESION, FRICTION, SUPPORT - division pile by type of load perception

It must be 2 parameters.