Avoid the new introduction of direct attributes instead of using psets consistently - here IfcKerb

[TLiebich]

In [IfcKerb ](http://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcKerb.htm)as new entity in IFC4.3.0 there is a direct attribute Mountable.

this could be best handled as a property at Pset_KerbCommon

Now since we deprecated almost all such direct attributes from IFC4.0 onwards it sounds very strange to reintroduce them. Hence my proposal:

• remove Mountable from IfcKerb
• add Mountable to Pset_KerbCommon

[SergejMuhic]

At first it had a predefined type MOUNTABLE but since it was only one, the attribute was changed to a boolean. Not sure how to handle such cases efficiently.

[TLiebich]

I would say, that there are three main questions to answer:

• is there additional information that should be specific to this - e.g. if there is a specific pset dedicated to IfcKerb/MOUNTABLE - make it a predefined type
• otherwise if it is an additional semantic information specific to this entity, add it to the 'Common" pset
• otherwise if it is a dimension, etc. that could be derived from geometry, add it to the Qset

[SergejMuhic]

ping @larswik that would mean Pset_KerbCommon.

[larswik]

I agree. Shall I do this (remove attribute from IfcKerb and add it as a property to Pset_KerbCommon) now?

[SergejMuhic]

would we at least introduce an IfcKerbTyepEnum USERDEFINED NOTDEFINED

or just leave an empty IfcKerb with no attributes?

[TLiebich]

sure, we should introduce IfcKerbTypeEnum as predefinedType. Actually, all leaf-node classes should have a predefined type. So +2 to add.

[larswik]

Tried to fix in https://github.com/bSI-InfraRoom/IFC-Specification/pull/370 Also added necessary where rules - please check!