Remove alphanumeric restriction on property IDs, support unicode

[lilleyse]

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]

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]

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]

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]

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]

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).