# MultipleApply APISchemas, Inheritance vs BuildIn Schemas

**URL:** <https://forum.aousd.org/t/multipleapply-apischemas-inheritance-vs-buildin-schemas/1077>\
**Category:** USD\
**Created:** [December 22, 2023, 3:04am UTC](https://forum.aousd.org/t/multipleapply-apischemas-inheritance-vs-buildin-schemas/1077 "2023-12-22T03:04:45Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![infernalspawn](https://avatars.discourse-cdn.com/v4/letter/i/f08c70/32.png) [@infernalspawn](https://forum.aousd.org/u/infernalspawn)\
**Post date:** [December 22, 2023, 3:04am UTC](https://forum.aousd.org/t/multipleapply-apischemas-inheritance-vs-buildin-schemas/1077/1 "2023-12-22T03:04:45Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![spiff](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/spiff/32/22_2.png) [@spiff](https://forum.aousd.org/u/spiff)\
**Post date:** [January 19, 2024, 11:41pm UTC](https://forum.aousd.org/t/multipleapply-apischemas-inheritance-vs-buildin-schemas/1077/2 "2024-01-19T23:41:13Z")

</div>

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”…