EXT_structural_metadata - parent class

[lilleyse]

• Metadata assigned to glTF objects - like nodes and materials - is now encoded in JSON rather than in binary in a property table. This is similar to tileset and tile metadata in 3D Tiles. This is a breaking change that shouldn't have a wide impact.
• Added the concept of a parent class that allows for class hierarchies, with some restrictions like no duplicate property IDs and no cyclical inheritance

@javagl would you mind taking a look?

[javagl]

It's difficult to foresee all implications of this change. Some thoughts:

---

The first part is a breaking change for any existing data that uses the per-object metadata that originally pointed to the property table row. I think that this was not actively or widely used, so the impact might be minimal. In terms of alleviating the possible impact, one could consider different options. In theory, just on a "brainstorming" level, the new structure could "emulate" the old one: Given a data set that defines a node with the extension object...

"EXT_structural_metadata": {
  "propertyTable": 1,
  "index": 4
}

one could add a new class to the schema, say propertyTableRow, with the properties propertyTable and index, and then just define

"EXT_structural_metadata": {
  "class": "propertyTableRow",
  "properties": {
    "propertyTable": 1,
    "index": 4
  }
}

The client application would have to be adjusted to handle this. I.e. a possibly existing function like
const metadata = node.getStructuralMetadataValue();
would now be something like

const info = node.getStructuralMetadataValue();
const metadata = gltf.getPropertyTableRow(info.propertyTable, info.index);

But again: This is just brainstorming about how existing data could be "upgraded" to the new structure.

---

The additional support for a parent class is not breaking in terms of existing data. Everything that worked before will just continue to work. But of course, clients will have to be updated to handle that new concept. And here, it's particularly hard to imagine what this might mean.

For example, 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. (All this is possible, and maybe even "simple" - I'm just trying to think a few things through here...)

It 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...?

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

And, more broadly: The EXT_structural_metdata is supposed to be an 'implementation' ("incarnation") of the general 3D Metadata specification. This new parent concept is not covered by this specification. And it raises the question of whether this concept should also be in the 3D Tiles metadata ...

[lilleyse]

And it raises the question of whether this concept should also be in the 3D Tiles metadata ...

I think it should, though I'm not sure if it can be done without adding a new extension.

[lilleyse]

I moved the JSON encoding change to its own PR: #71