Should IfcSegmentedReferenceCurve be a subtype of IfcGradientCurve?

[aothms]

This is a bit of a minor thing, but should IfcSegmentedReferenceCurve be a subtype of IfcGradientCurve? It's a backwards compatible change to make.

It would make things more consistent, and glancing at the code we have on our end now, it would have minimally simplified things.

IfcCompositeCurve
        ^
        |
IfcGradientCurve
        ^
        |
IfcSegmentedReferenceCurve

(In general I'm not too fond of geometric items inheriting from each other. For example we had IfcAsymmetricIShapeProfileDef previously inheriting from IfcIShapeProfileDef, which in my point of view violates liskov substitutability, and can result into unnoticed omissions in implementations where an IfcAsymmetricIShapeProfileDef is silently handled as a IfcIShapeProfileDef.

IfcBoxedHalfSpace is an example, where it is valid, where every IfcBoxedHalfSpace functionally performs the same as an IfcHalfSpaceSolid.)

[RickBrice]

I don't see IfcSegmentedReferenceCurve being a type of IfcGradientCurve. As I understand the schema, an IfcSegmentedReferenceCurve modifies the elevation of an IfcGradientCurve and adds a cross slope variation.

Constraining IfcSegmentedReferenceCurve.BaseCurve to an IfcGradientCurve is consistent with CT 4.1.7.1.1.3 https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/concepts/Product_Shape/Product_Geometric_Representation/Alignment_Geometry/Alignment_Geometry_-_Horizontal,_Vertical_and_Cant/content.html

Additionally, constraining IfcGradientCurve.BaseCurve to IfcCompositeCurve is consistent with CT 4.7.1.1.2 https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/concepts/Product_Shape/Product_Geometric_Representation/Alignment_Geometry/Alignment_Geometry_-_Horizontal_and_Vertical/content.html