Should OTIO_SCHEMA key inside metadata result in a SerializableObject?

[rogernelson]

I noticed this somewhat by accident, but if OTIO_SCHEMA exists inside a metadata object the OTIO API will attempt to deserialize it into a schema. I was wondering if wondering if this was an unintentional side effect of the recursive deserialization or if the metadata is not intended to not be a completely opaque blob? One thing to note is that if there is no schema available in the manifest matching the OTIO_SCHEMA value, the metadata will include an UnknownSchema when read through the API.

Here's an example snippet of serialized data (with only relevant fields included):

"children": [
  {
    "OTIO_SCHEMA": "Clip.1",
    "metadata": {
      "my_metadata": {
        "OTIO_SCHEMA": "MY_METADATA.1",
        "my_key": "my_value"
      }
    }
  }
]

If I access this in the API:

(Pdb) clip.metadata
{'my_metadata': <opentimelineio._otio.UnknownSchema object at 0x19332d050>}

This prevents the metadata from being accessed like a regular dictionary object, for example clip.metadata['my_metadata']['my_key'].

I am not sure if this is desirable or not, so I thought it would be good to have a discussion about it.

[rickcoles-fn]

My initial thought is that this is not desirable. I reckon anything inside a metadata object should be be treated as opaque by OTIO, otherwise there's scope for all sorts of unexpected and inconsistent behaviour.

Perhaps, if they really want to, client could still choose to extract such embedded schema and feed it into OTIO deserialization?

[rogernelson]

Thanks for the response! Let's poke some of the experts to see if they also have an opinion @jminor @reinecke @ssteinbach

[jminor]

Hi, sorry for the brief answer while I'm out on leave, but yes, this is intentional. The idea is/was that custom schema objects may exist within metadata, and the schema system gives those objects the benefit of the schema upgrade system, serialization to/from class instances with helpful methods, etc.

We have been using this in our pipeline for a while with some pros & cons. The main con being that there isn't an established SchemaDef mechanism in pure C++. However, it is pretty easy to register custom classes in C++ even if there isn't a plugin mechanism for that. You can just subclass SerializableObjectWithMetadata and then call TypeRegistry::register_type(...) before deserializing and then you'll get your custom class instead of UnknownSchema.

The other downside, which you mentioned is that UnknownSchema objects are opaque, which makes them awkward to work with if you haven't provided a custom class. It might be desirable to allow accessing them like dictionaries, or maybe just an accessor on the internal dictionary that they use to store their contents.

[rickcoles-fn]

Interesting, and I can certainly see the benefits. Treating metadata as partially opaque makes me nervous, though, as I see metadata usage very significant and wide ranging and thus scope for unpredictability.

But then if everyone understands that an "OTIO_SCHEMA" appearing in metadata means something special and client code needs to handle unknown embedded schema then perhaps we can get the best of both approaches?

And you should probably not be looking at this while you're on leave, Josh :)

[rogernelson]

I think that makes sense. We just have to think of OTIO_SCHEMA as a reserved keyword in a programming language. You can't give that name to your variables since it has special meaning to the language.

[ssteinbach]

+1 to what @jminor said. Also on leave, apologies.

• Even beyond the metadata dictionary, the idea was that OTIO_SCHEMA could appear anywhere in the JSON and be deserialized into a type.
• Documenting OTIO_SCHEMA as a reserved key would be a good, since it is a constraint on the serialization (at present).
• the additional benefit that Josh didn't list was that standard OTIO types could also be used in metadata - RationalTime, etc. would be automatically deserialized
• The intent was that UnknownSchema could be accessed via a dictionary blindly, but it looks like that fell off the table. That should be filed as an issue (if it isn't already). I see that there isn't a unit test for that behavior.
• It probably is a good idea to discuss whether the "everything everywhere gets deserialized via OTIO deserializer" is a good policy or not.

[reinecke]

I've created issue #1234 for dictionary-like access to UnknownSchema.

[rogernelson]

Thanks for answering even while on leave Josh! I agree it could be a nice enhancement to allow someway of accessing an UnknownSchema like a dictionary. But at least until then it still has an accessor where the raw json can be extracted.