Schema wishlist

[aothms]

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

[tomvandig]

Coupling the restrictions makes sense, then in addition I would also like to remove the intermediate xxxRestrictions object and just directly place the restrictions next to the datatype. I feel a lot of readability is now lost because of this intermediate node.

Schema refs are indeed similar to what is now inherits, but a bit more general. Inherits both support the (multiple) inherit use case of redeclaring a child-type but also allow for referencing by embedding an object that inherits. We could create syntactic sugar for this to (again) improve readability.

The Union part is a good point, I think its an oversight and we should support it. It is not particularly hard to validate, but it might be annoying to build queries on...

For sure though, I don't think we should do the children approach for these use cases, as the data is clearly intended to be a single object, but we would break it apart just to gain type flexibility.

The further we go with the schemas, though, the more we ask of the implementers. I don't think these particular requests are going too far, but we should be careful not to try to support everything. Or, if we do want much more, we should find/build tooling (or standards) to simplify the work for implementers.

[aothms]

Coupling the restrictions makes sense, then in addition I would also like to remove the intermediate xxxRestrictions object and just directly place the restrictions next to the datatype. I feel a lot of readability is now lost because of this intermediate node.

Makes sense

For sure though, I don't think we should do the children approach for these use cases, as the data is clearly intended to be a single object, but we would break it apart just to gain type flexibility.

I think so too, but in this particular case, it's kind of what we did with IfcAlignmentSegment. If you want to say additional (outside of the schema) things about the parts you need to break them up anyway.

The Union part is a good point, I think its an oversight and we should support it. It is not particularly hard to validate, but it might be annoying to build queries on...

I agree, for validation it's just an or reduction over the options, but implementation can be tricky especially when multiple unions in different places kind of create combinatorial complexity, so it's something to use sparingly.

It's also the main means to create backwards compatibility which is why we have quite a few of them in ifc4.

The further we go with the schemas, though, the more we ask of the implementers. I don't think these particular requests are going too far, but we should be careful not to try to support everything. Or, if we do want much more, we should find/build tooling (or standards) to simplify the work for implementers.

100% agreed. I'm also a bit uncomfortable that we're defining our own stuff for this, but with the things above added, it's also a pretty nice sweet spot that's still in line with e.g jsonschema so conceptually we're not doing anything crazy.