MultipleApply APISchemas, Inheritance vs BuildIn Schemas

Community USD
1

Heya,

I am trying to find out how to navigate the following challenge.
We do have to support multiple USD versions (usd 21.08 - usd 23), and we want to use multipleApply API Schemas inheriting from existing applied Schemas (<=usd-21.08) respective Built-In applied Schemas.

Our plan was to have a Multi-ApplyAPI that adds some extra attributes to a CollectionAPI.
with a propertyNamespacePrefix = "foo"

And while the schema-definition differs between <=21.08 and the rest.
inherits =</CollectionAPI>
vs
inherits = </APISchemaBase>
prepend apiSchemas=['CollectionAPI']

We do see a difference in the scenes created.

A scene created in usd-21.08 (Our schema using inheritance), the collection attributes are called
foo:myInstance:includes

A scene create in usd-22.05 using built-in schemas the collection-attributes will be called
collection:myInstance:includes

So scenes generated in usd-21.08 and in usd-22.05 dont seem to be incompatible.
Do you have a suggestion as to what we can/should change in our Schema-definiton perhaps? to make sure we generate data that is compatible ?

Thank you for your help!
Seb

2

Hi @infernalspawn, sorry for the delay and I’m afraid I don’t have good news. The ability you are leveraging from the old, inheritable-API-schemas OM is one that we hadn’t really considered as API schemas were evolving (they just “inherited” inheritance from typed schemas, initially), and when we realized this was something you could do (completely replacing a schema’s identifying namespace prefix) we realized it would be problematic moving forward.

So, as we were formulating the new OM where API’s can only be composed into other API’s, we do provide the ability to add a multi-apply that will take its instance-name from the containing API, but we curtailed the ability to fully replace the namespace prefix with the containing (base) API’s namespace prefix.

I can’t really think of a reasonable schema-side solution to this transition problem. Seems like it’s either copy a bunch of code to fully define your Foo schema, or write a conformance script that processes USD layers and changes “foo:XXX:includes” (etc) property names to “collection:XXX:includes”…