Can schemaIdentifier and alias both be optional?

In 24.11 the schemaIdentifier field was added, and alias was made optional. Or at least that is how I interpret the commit comment.

It’s great because I can now have type names & identifiers set to the same value, rather than invent some prefix/midfix for all my types.

But when I try to use schemaIdentifier on a codeless schema, it still feels a bit redundant:

{
    "Plugins": [
      {
        "Info": {
            "FooAPI": {
              "schemaIdentifier": "FooAPI",
              "autoGenerated": false,
              "bases": [
                "UsdAPISchemaBase"
              ],
              "schemaKind": "singleApplyAPI"
            }
          }
        },
        "LibraryPath": "",
        "Name": "foo",
        "ResourcePath": "",
        "Root": ".",
        "Type": "library"
      }
    ]
  }

Would it be reasonable to change this coding error to set identifier = type.GetTypeName() instead?

So the fallback order would be:

  • schemaIdentifier metadata
  • first and only alias
  • type name

If you have a look at the (soon to disappear from the OpenUSD repo because now ships with prman) renderMan codeless schemas’ plugInfo.json, you’ll see the expectation is that the type that gets registered with TfType is still module-prefixed, and we don’t want those prefixes showing up in schema Identifiers. Now you can make the argument there’s nothing requiring that prefixing because there’s no C++ class-type to match against… I’ll queue this up for discussion on the team, though it may be a bit!

I realize that is the norm, but in some cases its nice to keep the namespace in both the TfType and the schema identifier. Particularly with 3rd Party schemas, it would be odd to drop the namespace and “claim” a schema identifier that might one day be needed in USD itself.

e.g. in my Foo plugin above I might provide a FooLightField which I want to use as both TfType and schema identifier.

In any case, its not a high priority at all, I can of course keep providing the schemaIdentifier. I only mentioned it because the option to fallback to typename (naively) appears to be a one-liner.