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?
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.
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.
@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.
