4x3alpha - IfcTransportElement and IfcTransportElementType

Serialization will be broken in comparision to previous schemas by changing the predefined type to a select. Refer https://forums.buildingsmart.org/t/existing-enumeration-constants-modifications/2243/9

Is it preferable to introduce new occurence and type concepts for mobile elements?

the change in a p21 file is either using a TYPED_PARAMETER, or using an UNTYPED_PARAMETER according to the WSN form.

PARAMETER_LIST = PARAMETER { “,” PARAMETER } .
PARAMETER = TYPED_PARAMETER | UNTYPED_PARAMETER | OMITTED_PARAMETER .
TYPED_PARAMETER = KEYWORD “(” PARAMETER “)” .
UNTYPED_PARAMETER = “$” | INTEGER | REAL | STRING | ENTITY_INSTANCE_NAME | ENUMERATION | BINARY | LIST .
OMITTED_PARAMETER = “*” .

or …, IFCVIBRATIONISOLATORTYPEENUM(.SPRING.), … vs. …, .SPRING., …

it should be a recoverable error in an P21 parser. I would see the effort of handling the compatibility issue minor to the overload, when introducing two new classes and deprecating two others.

attached is a 2011 MSG document discussing backward compatibility at the level of P21 files. According to it, we should accept the change to a select type.20110702_IFC4_SchemaCompatibilityAssessment.pdf (149.2 KB)

Just for clarification. IfcTransportElement.PredefinedType would then be of Type IfcTransportElementSelect instead of IfcTransportElementTypeEnum?

I would also point you @TLiebich to this topic https://forums.buildingsmart.org/t/4x3alpha-ifcbuildingstorey/2267/7, see my last response for IfcBuildingStorey and IfcFacilityPart second paragraph. IfcBuildingStorey would have to be moved back to IfcSpatialStructureElement as its parent again.