About extensions and enum validation

[javagl]

Enums are usually specified to follow the pattern of

            "anyOf": [
                {
                    "const": 5120,
                    "type": "integer"
                },
                {
                    "const": 5121,
                    "type": "integer"
                },
                ...
                {
                    "type": "integer"
                }
            ]

The last object that only declares the type integer is intended for extensions. When there is an extension that adds a new valid value to that enum, then this should still be compliant to the schema itself.

The validator goes beyond schema matching. It will therefore issue an error for such an enum value, unless there is a known extension that declares the new enum value to be valid.

There is one specific example for this right now, namely the EXT_texture_webp extension, that adds image/webp as a valid value for the image.mimeType. From quickly skimming over the code, this is accomplished by storing the imageMimeTypes in the context (pre-populated with the core MIME types), and adding WEBP to that list during the initialization of the extensions.

Now I wondered about the general approach for this. Namely, how extensions can sensibly add new valid enum values. If an extension was supposed to add, for example, a new meshPrimitive.mode, then the only solution that I'd come up with right now would be to first update the "core" validator, by adding

final List<int> meshPrimitiveModes = <int>[gl.LINES, gl.LINE_LOOP, 
  gl.LINE_STRIP, gl.TRIANGLES, gl.TRIANGLE_STRIP, gl.TRIANGLE_FAN];

to the context, and changing the place where the mode is obtained from

final mode = getUint(map, MODE, context,
  min: gl.POINTS, max: gl.TRIANGLE_FAN, def: gl.TRIANGLES);

to

final mode = getUint(map, MODE, context, list: context.meshPrimitiveModes);

So the question that came to my mind was:

Is there (or should there be) a generic mechanism that allows extensions to "hook" into all open-ended enums?

(The alternative would be that contributors that add support for a specific extension also have to add changes like the one described above, but it is hard to be sure that this does not have undesired side-effects...)

[lexaknyazev]

These are all great questions.

• On the spec or extensions level, extending enum sets should be done very carefully as it may lead to unintended side-effects. For example, a WebP image can be used only by a texture extension object, not the core texture.source. It's not clear how to extend "non-leaf" core objects without making the extension required.
• From the code maintainability point of view, we should eventually generalize all enum sets.