Consider allowing a "parent" class for metadata classes

[javagl]

This was originally proposed in CesiumGS/glTF#70 . Given that EXT_structural_metadata is only an "instance" of the 3D Metadata Specification that is defined together with 3D Tiles, it may make more sense to have this conversation here. An attempt of a summary from the linked PR:

It could make sense to allow metadata classes to define a parent class, to form a hierarchy of classes.

This would allow users to model certain metadata structures more cleanly. There could be some parent metadata class that defines some common/basic properties. The child classes could just refer to this parent, inherit all its properties, and additionally define their own, custom, specific properties. This could decrease the redundancy that is otherwise caused by repeating all the common/basic properties in each and every class. And it would make it easier to add a new common/basic property to many classes, by just adding it to the common parent class, and not having to add it to each class individually.

There will have to be some constraints, like not allowing any form of "overrides" of properties, and disallowing cycles. And although it is not a breaking change in terms of existing data, there are some details that have to be sorted out, regarding the specification, and how exactly clients should handle this concept of a "parent" class. Some of these details (extracted/summarized from this comment):

The parsing:

Looking at things like the existing MetadataClass in CesiumJS, a quick shot at supporting this would be to just add a parent: MetadataClass to that. But this means that such a class can no longer be parsed in a "standalone" fashion from a single JSON node. For example from a schema JSON like

 "classes" : {
      "classA" : { ... },
      "classB" : { ... }
}

it was trivial to just throw that "classA" object into a function like MetadataClass.fromJson. Now, that "classA" might declare "parent": "classB", meaning that it will be necessary to first generate the MetadataClass objects from all classes that do not define a parent, and store them in some repository, so that they can be looked up when generating the objects for classes that do have parents.

Offering the information on the client side:

This concept may also require further differentiation for the properties: The properties should probably be all properties. But maybe there should be some sort of distinction between properties/ownProperties/inheritedProperties...?

Minor updates for the specification:

When looking at things like propertiesBySemantic, the specification may have to update the description of semantic to say...

The semantic cannot be used by other properties in the class or any of its parent classes