Schema wishlist

These are just to get a discussion started:

## Couple restrictions to datatype

Maybe sth like this is possible:

```
model BaseValueDescription {
dataType: DataType;
optional?: boolean;
inherits?: string[];
}

model EnumValueDescription extends BaseValueDescription {
dataType: "Enum";
enumRestrictions: EnumRestrictions;
}

model ArrayValueDescription extends BaseValueDescription {
dataType: "Array";
arrayRestrictions: ArrayRestrictions;
}

model ObjectValueDescription extends BaseValueDescription {
dataType: "Object";
objectRestrictions: ObjectRestrictions;
}

model RealValueDescription extends BaseValueDescription {
dataType: "Real";
objectRestrictions: ObjectRestrictions;
quantityKind?: QuantityKind;
}

model PrimitiveValueDescription extends BaseValueDescription {
dataType: "Boolean" | "Integer" | "String" | "DateTime" | "Reference" | "Blob";
}
```

## Schema refs

(or is this the inherits we currently have?)

Concise metaphorical example

- bsi::ifc::v5a::point -> array[real]
- bsi::ifc::v5a::polyline -> array[bsi::ifc::v5a::point]

## Unions

It's one way to enable "two-star" procedural geometry schemas such as extrusions.

- bsi::ifc::v5a::circular_arc-> object(start:point, mid:point, end:point)
- bsi::ifc::v5a::composite_curve -> array[bsi::ifc::v5a::polyline | bsi::ifc::v5a::circular_arc | ...]

The alternative is that we don't constrain anything on the schema level and we break it up into children, but then we have much less control schema-wise

```
{ path: comp-curve-guid, children: [segment1-guid, segment2-guid]}
{
path: segment1-guid
attributes: { bsi::polyline { ... } }
}
{
path: segment2-guid
attributes: { bsi::circular_arc { ... } }
}
```

Other alternative is inheritance, but in my view doesn't work that well. It's a mess now in ifc4 with IfcCurve, IfcBoundedCurve, IfcTrimmedCurve and concrete things like IfcPolygonalBoundedHalfSpace