Determine which classes are abstract and concrete

[palemieux]

For each class, determine whether the class can be serialized, i.e. whether an instance of the class can ever be found in an OTIO file.

For example, can the following ever be found in an OTIO file?

{
  "OTIO_SCHEMA": "SerializableObject.1",
  "metadata": {"bar": 2},
  "name": "foo",
  "foreignproperty" : "hello"
}

[reinecke]

I think the candidate "abstract" classes would be:

• Composition
• Composable
• Item
• MediaReference
• SerializableObject

From an implementations standpoint and in-memory usage standpoint, none of the classes are abstract.
From a practical usage standpoint, I don't think any of these should be showing up in files.

@ssteinbach @jminor Do you think for the purposes of the data model spec we should say these should not appear in files?
From an implementation standpoint, we find it useful to be able to instantiate and serialize these for test purposes, but I think it's pretty safe to say we'd consider it bad form is we saw people interchanging files using these schema, right?

[jminor]

Yes, this list looks correct to me.

The only one I'm not 100% sure on is SerializableObject. Way back we discussed serializing custom in-house objects as SerializableObject, but with custom metadata. I think any use case along those lines these days would use SchemaDef plugins instead, so it should be safe to say that there are no raw SerializableObject instances, only subclasses, in a serialized OTIO file.

[palemieux]

A key question is whether Composition should not show up in files or shall not show up in file. In other words, is it an error for a file to contain any of the classes listed at #11 (comment) ?

[reinecke]

My personal opinion is Should Not. I think it's okay for implementations to allow you to try these things out, but we should signal that any consumer other than a low-level library for interacting with the format should feel free to ignore these objects as they have little semantic meaning on their own.
In other words, you could put these things in a file, but something like Premiere isn't expected to pay attention to or traverse them.

[jminor]

@palemieux can you clarify the distinction between Should Not and Shall Not? I'm guessing Should Not means that an implementation has undefined behavior, where Shall Not means it must produce an error?

[palemieux]

can you clarify the distinction between Should Not and Shall Not?

Using Composition as an example of an abstract class:

1. shall not would mean that a file would be invalid, and thus rejected, if it contained an instance of Composition.

2. should not would mean that a file would not be rejected if it contained an instance of Composition. Processors would be discouraged emit instances of Composition in files. Processor behavior when encountering a Composition instance in a file would either be (a) unspecified or (b) to prune the instance of Composition prior to processing the file.

(1) might invalidate existing files. (2) increases the complexity of the schema and will undoubtedly result in someone using abstract classes to mean something -- despite best effort.

I recommend prohibiting the serialization of classes for which no semantics are defined.

[reinecke]

What would make sense to me is to go with should not and define the semantics for these to be ignored. While low-level implementations (like the reference implementation) may give you the ability to access and interact with these objects, I'd expect DCCs to discard these objects for their use cases.

[palemieux]

@reinecke Per our discussion, another approach would be for the specification to forbid abstract classes from files -- so that the error is caught by validators. The reference implementation can of course choose to expose the classes for debugging/educational/legacy purposes.

[reinecke]

Upon review I agree this feels like the best choice.