Is there a way to do JSON validation that does case insensitive matching on property names? about json-everything HOT 8 CLOSED

@gregsdennis It does, thanks. I wish there was an easier solution. It is going to make adoption for us a bit more painful. It just seems silly to be case sensitive with json property names. It would be a fantastic opt-in feature to the tooling if it was ever added.

from json-everything.

JSON Schema in general doesn't support case-insensitive matching. You're going to have a hard time finding any validator that supports it.

You might be able to get around it by using patternProperties and creating regexes for each property. I don't know how complex your schema is.

For example, if you have the following data:

[
  { "foo": 5 },
  { "Foo": 5 }
]

you could validate this with

{
  "type": "array",
  "items": {
    "patternProperties": {
      "^[Ff]oo$": { "const": 5 }
    }
  }
}

Of course this would take some setup, but this is how you'd do it.

from json-everything.

If you'd like to propose case-insensitivity as a JSON Schema feature, you're welcome to open an issue in the spec repo: https://github.com/json-schema-org/json-schema-spec/issues

from json-everything.

Would this be something that is relatively easy to add if requested? We have situations where payloads may change casing of properties as they are handed off between different steps along a chain, and we want to still verify it meets the spec but case sensitivity caught us off guard. We are used to all of our implementations being case insensitive that this became a blocker for us implementing this type of validation. This seems more like a tooling implementation detail, rather than a change to the spec. That seems like it would be a much larger lift to request.

from json-everything.

Would this be something that is relatively easy to add if requested?

Possibly, but I'm unsure. I'd have to dig into it. I'm sure it's doable, but what that looks like and how easy it might be will require some investigation.

This seems more like a tooling implementation detail, rather than a change to the spec.

In general, tooling should meet the requirements of the spec. If the spec doesn't support case insensitivity, then the tooling shouldn't either (by default).

Tools can offer configurations that operate outside of the spec, but these configurations should be disabled by default so that they have to be explicitly set by the user. This way, the user is opting in to non-standard behavior.

Some applications use different property name casing rules when producing the JSON, but all of the consumers of the JSON are case-insensitive by default.

I recognize that this is the situation that you're in now, and fixing your ecosystem to unify all of your JSON producers may be a long job.

However this kind of inconsistent data formatting is the root of the problem, and I believe it should be addressed eventually.

We are used to all of our implementations being case insensitive...

Thinking through the various JSON functionality that I've built here and seen other places, I can't think of a specification that allows case insensitivity. The only place I can think that I've seen it is in serializers.

from json-everything.

Another option would be to perform some pre-processing on your JSON data prior to validation.

void CamelCasePropertyNames(JsonNode? node)
{
    if (node is not JsonObject obj) return;

    var propertyNames = obj.Select(x => x.Key).ToList();
    foreach (var propertyName in propertyNames)
    {
        // there's an issue going from snake-case directly to camelCase
        // go through humanize first resolves it
        var adjustedName = propertyName.Humanize().Camelize();  
        var value = obj[propertyName];
        obj.Remove(propertyName);
        obj[adjustedName] = value;

        CamelCasePropertyNames(value);
    }
}

This will normalize all of your names for you. It requires Humanizer.

from json-everything.

@JasonRodman does this answer you question (albeit probably not as you had hoped)?

from json-everything.

It just seems silly to be case sensitive with json property names.

FWIW, in my experience (which you can see from the extensive JSON support in this project), I've never seen any JSON-related technology support case-insenstivity (with the single exception of deserialization, and even that's usually opt-in).

JSON is basically always exact match on strings.

from json-everything.