# Rust implementation - Questions about ambiguities **URL:** \ **Category:** Core Specification, Samples and Compliance\ **Created:** [December 29, 2025, 9:54pm UTC](https://forum.aousd.org/t/rust-implementation-questions-about-ambiguities/2813 "2025-12-29T21:54:07Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![laurooyen](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/laurooyen/32/1084_2.png) [@laurooyen](https://forum.aousd.org/u/laurooyen)\ **Post date:** [December 29, 2025, 9:54pm UTC](https://forum.aousd.org/t/rust-implementation-questions-about-ambiguities/2813/1 "2025-12-29T21:54:07Z")
Hello everyone Thanks for the amazing work on the specification. I can only imagine how much effort it took. I’d like to share my Rust implementation of OpenUSD here if that’s alright. I’ve been working on this for well over a year by reverse engineering the C++ codebase but can now finally make it spec compliant 🙂 In doing so I ran into the following issue: The specification defines a ‘propertyChildren’ field on prim specs but existing usdc crate files use a ‘properties’ field. I couldn’t find guidance in the specification on how to handle this. The example Python implementation maps the field which works but is non-normative. This would be an even bigger issue when third-party implementations need to write usdc files. What is the intended handling here? Should the specification mention this? > **[GitHub - FloatyMonkey/openusd-rs: Implementation of OpenUSD in pure Rust](https://github.com/FloatyMonkey/openusd-rs)** > > Implementation of OpenUSD in pure Rust ---
**Author:** ![dhruvgovil](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/dhruvgovil/32/3_2.png) [@dhruvgovil](https://forum.aousd.org/u/dhruvgovil)\ **Post date:** [December 30, 2025, 6:08am UTC](https://forum.aousd.org/t/rust-implementation-questions-about-ambiguities/2813/2 "2025-12-30T06:08:06Z")
I’ll defer to @nvmkuruc for clarity on this one. (Matt might be unavailable till after the holidays though) very excited to see a rust implementation in the works though. I considered writing the sample implementation in Rust but Python felt like it would be maximally accessible. ---
**Author:** ![laurooyen](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/laurooyen/32/1084_2.png) [@laurooyen](https://forum.aousd.org/u/laurooyen)\ **Post date:** [December 30, 2025, 9:37am UTC](https://forum.aousd.org/t/rust-implementation-questions-about-ambiguities/2813/3 "2025-12-30T09:37:28Z")
Thanks. I totally get why Python. Rust is weird, for one mapping the OOP heavy design of USD schemas into it has been … interesting, not fully satisfied with my solution yet. Anyways I ran into a second problem, should a forward slash be present between variant selections and prim children thereof? The paths below are presented as valid in section 8.1 of the specification. Note the (absence of a) slash before the last prim name. 1. /Root/Child/Grandchild{size=1}/GreatGrandchild 2. /World/Foo/Baz{VariantSet1=VarFoobaz}Foobaz If I interpret the PrimElements parsing rule of a Path correctly, I believe 1 to be invalid and 2 to be valid. Parsing these paths with the C++ implementation confirms this assumption. That is 1 throws an error, 2 parses successfully. I feel like this should be mentioned explicitly under the valid/invalid paths section in the specification and example 1 should be fixed. Additionally, the ‘file\_formats/tests/assets/text/baseline/variants.json’ from the core spec supplemental release contains what I believe to be the wrong representation with erroneous slash. Meaning my spec compliant path parser fails those tests. ---
**Author:** ![nvmkuruc](https://avatars.discourse-cdn.com/v4/letter/n/76d3ee/32.png) [@nvmkuruc](https://forum.aousd.org/u/nvmkuruc)\ **Post date:** [December 30, 2025, 2:10pm UTC](https://forum.aousd.org/t/rust-implementation-questions-about-ambiguities/2813/4 "2025-12-30T14:10:19Z")
@laurooyen The important bit regarding `properties` vs. `propertyChildren` is that `properties` will be the field name in `usdc`. That should not change. The reference implementation of `usdc` explicitly remaps `properties` to `propertyChildren` to align with the document data model. We’re going to discuss whether or not the document data model using `propertyChildren` as the field name instead of `properties` is an error or not and if a future revision should either revise that or explicitly specify the mapping in the `usdc` format specification. Regarding paths, you’re correct that 1 is an invalid path and we update this in a future revision to the specification. ---
**Author:** ![nvmkuruc](https://avatars.discourse-cdn.com/v4/letter/n/76d3ee/32.png) [@nvmkuruc](https://forum.aousd.org/u/nvmkuruc)\ **Post date:** [April 14, 2026, 3:40pm UTC](https://forum.aousd.org/t/rust-implementation-questions-about-ambiguities/2813/5 "2026-04-14T15:40:04Z")
Hi @laurooyen, the core spec working group decided to align the document data model field name with the `usdc` field name. Both will be `properties`. This should be addressed for the 1.1 spec and a future update to the reference implementation.