Separation of Concerns for Identifiers in USD#105
Open
asluk wants to merge 37 commits intoPixarAnimationStudios:mainfrom
Open
Separation of Concerns for Identifiers in USD#105asluk wants to merge 37 commits intoPixarAnimationStudios:mainfrom
asluk wants to merge 37 commits intoPixarAnimationStudios:mainfrom
Conversation
…iers vs. source identifiers.
Captured reviewer's additional notes on UsdModel and UsdMedia as relevant illustrations-- to be addressed in a subsequent working session. Just checkpointing for now.
5b556f2 to
54e5555
Compare
spiffmon
reviewed
Mar 19, 2026
Add design requirement that vendor extensions are data-model-level concepts, not OpenUSD plugins, per AOUSD Core Spec 1.0 precedent. Expand step 5 with specifics of the vendor extensibility model. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
aea4c30 to
87fe3e3
Compare
steveghee
reviewed
Mar 25, 2026
steveghee
reviewed
Mar 25, 2026
steveghee
reviewed
Mar 25, 2026
steveghee
reviewed
Mar 25, 2026
steveghee
reviewed
Mar 25, 2026
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
steveghee
reviewed
Mar 25, 2026
Replace manufacturing-specific framing with three industry-neutral examples of collapsing internal asset structure (manufacturing, service documentation, M&E layout). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…feedback Adds Mercedes-Benz base-number + ES1/ES2 extension codes as a concrete example of identifier schemes with internal structural rules. Clarifies the distinction between USD built-in schema validation and domain-specific validation, which applies equally to dictionaries or schemas. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
d35b64e to
c33200a
Compare
Source format provenance (URDF/SDF/MJCF round-trip), ROS package identity, multi-robot fleet composition, sensor/actuator catalog identifiers, and operational telemetry binding. References the RobotecAI interoperability REP as a concrete community effort that would benefit from a standardized identifier mechanism. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
9150faf to
fea7d15
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of Proposal
Summary
Standardize a mechanism for carrying external source identifiers on USD prims alongside namespace paths. Identifiers from systems like IFC, PLM, asset management databases, and telemetry platforms should round-trip through USD without loss or reliance on ad-hoc conventions.
Problem statement
There is no standardized place in USD to store external identifiers. Pipelines work around this by encoding them into prim names,
customData, ordisplayName-- all with significant trade-offs. ThedisplayNamemigration intouiHintsmakes this time-sensitive.Glossary
Reference Links
displayNamemigration creating urgencyDetails
Two distinct problems are often conflated: (1) an unencumbered source identifier field, and (2) improved prim name ergonomics. This proposal focuses on (1) without foreclosing (2). Two candidate approaches -- extending
assetInfowith stratified sub-dictionaries vs. applied schemas with typed properties -- are compared with trade-offs and eight open questions.Risks
Uncurated proliferation, premature standardization, adoption fragmentation, and scope creep. See proposal for details.
Alternate solutions
Existing mechanisms (
customData,displayName, encoding into prim names) are evaluated in the proposal and found insufficient. The two candidate approaches are the alternatives under consideration.Out of Scope
Prim name grammar extensions, transcoding algorithms, feature-level identity continuity, and authorship traceability. Each is identified as complementary or downstream work in the proposal.
Link to Rendered Proposal
Supporting Materials
None at this time.
Contributing