Guidance for API schema instance names

Hello. For multi-apply API schemas, there don’t appear to be any restrictions in the instance name. For example–

from pxr import Usd
s = Usd.Stage.CreateInMemory()
p = s.DefinePrim("/root")
c = Usd.CollectionAPI.Apply(p, 'name with spaces')
c2 = Usd.CollectionAPI.Apply(p, 'name:with:colons')
print(s.GetRootLayer().ExportToString())

When you create the include or exclude relationship on c, you’ll get an error, as name with spaces isn’t a valid identifier for properties. However, name:with:colons works fine, as it will generate a valid property name.

Do people consider colons in the instance name to be bad practice? Do they complicate user interfaces and tooling that will treat them like namespaces? Do people consider whitespace in the instance name to be bad practice even when the instance name isn’t used to derive property names? Will OpenUSD ever apply restrictions to the instance name?

Thanks for the thoughts!

Although I can’t recall them at the moment, we have definitely discussed some future needs for namespaced multi-apply instance names. I think we should document and validate that instance names must be valid property names… even if there were cases where it made sense to have a multi-apply schema that did not provide any properties, it seems overly confusing to allow more permissive names for just those cases.

Thanks for catching this, @nvmkuruc - would you file an Issue?

Sure thing.

Do you anticipate namespaced instance names having any additional implied semantics?

Just spit-balling: the semantics schema could have namespaced or sub-semantics

  • Materials (wood, metal, cloth)
  • action-semantics (twist, push, pull, switch-on, switch-off, interact)
  • state semantics (open, closed)