-
Notifications
You must be signed in to change notification settings - Fork 0
Description
See also https://linkml.io/linkml/schemas/inheritance.html#mixin-classes-and-slots and https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem.
The diamond problem does not apply to JSON-SCHEMA since every schema included by allOf needs to be valid on the target document, meaning the following schema is invalid in any case:
allOf:
- title: B
properties:
x:
title: xB
type: integer
- title: C
properties:
x:
title: xC
type: stringThis make sense also in case of beeing transferred to e.g. python dateclasses because otherwise casting from a more specific to a more general base class would not be possible.
The need to allow incompatible definitions applies actually only to annotations (like title, descriptions, etc) and class methods (out-of-scope for JSON-SCHEMA). In this case, the order of superclasses becomes important, e.g.
allOf:
- title: B
properties:
x:
title: xB
type: integer
minimum: 1
- title: C
properties:
x:
title: xC
type: integer
maximum: 10will generate a web form with xB as label for x and a code generator will create
class Model(BaseModel):
x: Optional[conint(ge=1, le=10)] = Field(None, title="xB")Consistently,
class B:
def echo(self):
print("xB")
class C:
def echo(self):
print("xC")
class D(B,C):
pass
D().echo()will result in xB.
Other then the order with allOf there's no intrument in JSON-SCHEMA to indicate primary and secundary superschemas / classes. $ref could be regarded to have a different semantics as allOf: $ref but only a single value is allowed for $ref.