Skip to content
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

Open
lilleyse opened this issue Mar 12, 2025 · 5 comments
Open

Remove alphanumeric restriction on property IDs, support unicode #797

lilleyse opened this issue Mar 12, 2025 · 5 comments

Comments

@lilleyse
Copy link
Contributor

lilleyse commented Mar 12, 2025

Currently, property IDs must be alphanumeric:

"A dictionary, where each key is a property ID and each value is an object defining the property. Property IDs shall be alphanumeric identifiers matching the regular expression ^[a-zA-Z_][a-zA-Z0-9_]*$.",

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.

@lilleyse
Copy link
Contributor Author

Note: a property's name and description are allowed to be unicode since they are for display purposes. But it would be nice to allow this for property IDs as well.

@javagl
Copy link
Contributor

javagl commented Mar 13, 2025

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 This \"key\" looks strange; DROP TABLE metadata; http://example.com/ 😀 as a property name, but I'm curious).

Will the restriction be kept for class- and enum IDs?
(And the schema ID?)

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 sanitizeGlslIdentifier are called, and whether these places might be affected by such a change.

@lilleyse
Copy link
Contributor Author

Will the restriction be kept for class- and enum IDs?
(And the schema ID?)

I think the restriction should be removed for all types of IDs.

@lilleyse
Copy link
Contributor Author

Right now, the suggestion is to remove the alphanumeric restriction. Will there be any other restriction afterwards?

I'm not sure. Are there any equivalent restrictions in glTF or iModel?

@javagl
Copy link
Contributor

javagl commented Mar 13, 2025

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 "_" for custom ones, with KhronosGroup/glTF#2111 still pending).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants