Order of pattern properties matter!

[girish-tharwani]

Hello Expert,
Of course you would know this but I learned this the hard way today. This is a simplified and sanitized version of a schema that I thought was working fine

{
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "properties": {
        "foo": {
            "type": "object",
            "patternProperties": {
                "^[Bb][Aa][Rr]$": {
                    "type": "string"
                },
                "^.*$": {
                    "type": "number"
                }
            }
        }
    }
}

It was enforcing the type string on the properties that were named BAR, bar, Bar etc and for anything else (eg baz, bars, rebars), it was enforcing number type.

But when the order was reversed like this:

{
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "properties": {
        "foo": {
            "type": "object",
            "patternProperties": {
                "^.*$": {
                    "type": "number"
                },
                "^[Bb][Aa][Rr]$": {
                    "type": "string"
                }
            }
        }
    }
}

It started enforcing type number on Bar, BAR etc also.

Now I am trying to figure out a regex that matches "everything but all case variations of the bar" which I can use in place of ^.*$" so that order of pattern properties does not matter. And I am really struggling with it, specially since it will require regex negative lookahead which may not be supported universally and uniformly.

Is there any other workaround to it?

[Julian]

That sounds like a bug in whatever implementation you are using, though I suspect you're not actually using a validator but some other kind of JSON Schema tool -- JSON objects (let alone within JSON Schema) are unordered, and indeed no matter what order you apply the constraints there, the JSON Schema specification would say that that schema would never match any instance with a property called "bar" (or the like) as indeed it would always require that property to simultaneously be a string and number.

EDIT: Though I haven't answered what I assume your actual question must be -- which is how to write a schema which does one thing for bar and another for any other kind of property name?

[girish-tharwani]

I noticed the behaviour above in VS Code. And yes I understand the flaw here that "bar" will match both patternproperties of this schema, and the right solution is to fix the regex pattern ^.*$" so that it matches everything but bar (and its case variations). I am trying to work out that regex. Proving to be harder than expected.

[Julian]

In your simplified example that should be pretty easy, just use additionalProperties instead, i.e.:

{
    "patternProperties": {
        "^[Bb][Aa][Rr]$": {
            "type": "string"
        }
    },
    "additionalProperties": {
        "type": "number"
    }
}

If that doesn't work for your real example you'll probably need to expand your simplified one, but hopefully that helps.

[Julian]

And regarding VSCode specifically (or really its JSON language server, which I have access to via neovim) -- I don't really understand what it's doing with your schema, it seems to be slightly more complicated/random than just order, but it does seem to be a VSCode bug. Unfortunately that's not hard to come by though, you can see from VSCode's Bowtie report that it fails a large number of tests unfortunately, and I can see from the same report in Bowtie that it fails a number of them related to patternProperties (in particular a test called "multiple simultaneous patternProperties are validated" which seems likely to be relevant though I won't look further into it :).

[girish-tharwani]

In your simplified example that should be pretty easy, just use additionalProperties instead, i.e.:

{
    "patternProperties": {
        "^[Bb][Aa][Rr]$": {
            "type": "string"
        }
    },
    "additionalProperties": {
        "type": "number"
    }
}

If that doesn't work for your real example you'll probably need to expand your simplified one, but hopefully that helps.

this will work in some of the instances in my case but of course better option will be to have properly constructed non-overlapping regex

[girish-tharwani]

And regarding VSCode specifically (or really its JSON language server, which I have access to via neovim) -- I don't really understand what it's doing with your schema, it seems to be slightly more complicated/random than just order, but it does seem to be a VSCode bug. Unfortunately that's not hard to come by though, you can see from VSCode's Bowtie report that it fails a large number of tests unfortunately, and I can see from the same report in Bowtie that it fails a number of them related to patternProperties (in particular a test called "multiple simultaneous patternProperties are validated" which seems likely to be relevant though I won't look further into it :).

Well that explains a lot. I am glad that it wasn't a flaw in my my limited understanding of json / json but a bug instead.