-
Notifications
You must be signed in to change notification settings - Fork 476
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove alphanumeric restriction on property IDs, support unicode #797
Comments
Note: a property's |
Right now, the suggestion is to remove the alphanumeric restriction. Will there be any other restriction afterwards? (One could make a case that "every possible JSON-key could be allowed", but that's a lot. Sure, nobody would use Will the restriction be kept for class- and enum IDs? I haven't thought through the implications. It might end up being trivial, but we should keep an eye out e.g. on places where things like |
I think the restriction should be removed for all types of IDs. |
I'm not sure. Are there any equivalent restrictions in glTF or iModel? |
From the tip of my head, I think the only place where "custom IDs" (as in "JSON dictionary keys") are relevant is in the vertex attributes, and these are not constrained, as far as I know (except for the leading |
Currently, property IDs must be alphanumeric:
This was to allow property IDs to be used as identifiers in GLSL / shading languages. However, I'm not sure if this is a strong enough reason. Clients can pretty easily do a mapping from unicode string to internal GLSL identifiers. In fact, we did this in CesiumGS/cesium#8785 for point cloud styling with the older batch table.
The problem now is we're finding it hard to pick appropriate alphanumeric property IDs for properties that are in other languages, e.g. for IFC input in the Cesium design tiler.
The text was updated successfully, but these errors were encountered: