Case Insensitive Enums?

[Pluckerpluck]

I have now worked on a number of existing APIs that have operated in case-insensitive ways, and the inability to create a case insensitive enum has frustrated me. So will we ever see support for case insensitive Enums?

JSON Schema already supports regex, which is platform dependent. The simple suggestion here is to "avoid using features that aren't common accross most regex engines".

So I believe a similar thought process could be defined here. The same way toLowerCase is defined in JavaScript to be locale insensitive, a basic implimentation in the Schema could be likewise defined. Just like JavaScript we could use the locale independent mapping provided by the Unicode Character Database (therefore this is fully standardized)

Alternatively, the option to be locale specific could be included in the settings. Support for this functionality would then be engine dependent, but I know that at least JavaScript supports this under toLocaleUpperCase. Something else to consider would be the ICU libraries if we wanted locale sensitivity. They already handle case conversion, and wrappers exist in many languages.

You can see the JavaScript implementation here, which references the Unicode Default Case Conversion algorithm.

---

I know best practices would not have case insensitivity in APIs. But in practice it is not uncommon. As a result I've been forced to implement my own validation on enums that works case insensitively.

I hope this is the right place to bring up this discussion. I honestly am unsure.

[jdesrosiers]

I agree that JSON Schema needs a better solution for this. Something I've considered is adding a way to pass regex flags for a pattern. In this case, the i flag for case-insensitive matching.

{
  "pattern": "^any-case$",
  "patternModifiers": "i"
}

Of course this wouldn't work for patternProperties. Ideally, patterns would be surrounded by /s allowing for modifiers.

{
  "pattern": "/any-case/i"
}

But, that would be a breaking change, so we would have to be really sure want to make that change.

[Pluckerpluck]

I'm not sure pattern modifiers is the best solution in general though, as many of the modifiers aren't really applicable or require specific implementations themselves which we would need to define. There's dgmsuy as all valid javascript flags, for example. So you'd need to be specifying which modifiers work, and which doen't, at which point seperate dictionary keys may be clearer. Of course, as you said, this doesn't make patternProperties very simple.

But pattern modifiers also don't actually help in the case of enums either (which is the situations I've found affecting me more). Enums aren't using regex, so using the // format wouldn't help.

So I don't really know the best solution here. I just know I have regularly needed case insensitive matching on my enums and been forced to avoid JSON Schema simply as it can't handle this case.

[karenetheridge]

There already is syntax for flags inside of regexes - they can even be nested -- but it's up to your particular language as to whether they are supported. "any-case" as a case-insensitive regex would be ^(?^i:any-case)$.

[jdesrosiers]

The spec says regexes "SHOULD be valid according to the ECMA-262 regular expression dialect.", which unfortunately doesn't support this syntax 😢. So, it might work in some implementations, but isn't an interoperable solution.

https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.7.3.8

[willfarrell]

In ajv, a js implementation of the spec, there is a plugin (aka keyword) I wrote way back in 2018 (ajv-validator/ajv-keywords#64) to allow & coerce case insensitive enum values (https://github.com/ajv-validator/ajv-keywords#transform). @Pluckerpluck can this help you in the near term?

[gregsdennis]

It also needs to be noted that the opening comment assumes string-only enums. Enums may be of any JSON value, including objects and arrays.

Maybe what's needed is a new keyword (vocab suggestion) such as namedValues that only accepts strings. It could be case-insensitive, or you could have a secondary namedValuesCaseInsensitive that takes a boolean.

[handrews]

@Pluckerpluck JSON Schema now has support for extension vocabularies, so you could publish your keyword specification that way and others could implement it and use it in an interoperable way (although not with AJV which has refused to implement vocabulary support and stuck with its own non-interoperable extensions instead).