Type validation for variables

[clbarnes]

This may relate to #18 .

JSON Logic is, reasonably, designed around JSOs, which are very dynamic and flexible. But for many languages, that flexibility is not built in, and so only represents a potential source of error which the host language is designed to prevent, so using JSON Logic introduces a new class of error. The use case I'm thinking of is that a server knows the type which will be passed in to the rule, but has to accept the rule from an external source. It would be nice to be able to immediately validate the rule itself against the known input type, rather than have to fabricate an input instance and wait for an error.

A half-baked proposal is to optionally allow type information in a "var" (or "val") block, probably in typescript, JSDoc, or even JSONSchema format. Something like

[
  {
    "description": "Adds two numbers together",
    "rule": { "+": [1, {"var": "a.b.c", "type": "number"}] },
    "data": {"a": {"b": {"c": 1}}},
    "result": 2
  },
  {
    "description": "Adds two numbers together",
    "rule": { "+": [1, {"var": "a.b.c", "type": "number"}] },
    "data": {"a": {"b": {"c": "potato"}}},
    "result": Error
  }
]

An implementation in a statically typed language could parse the rule for those type fields and check them against the types of the fields.

Downsides are that this could lead to bloating of the rules, especially if type information is repeated (in which case it could also be self-conflicting, although this could also be detected at rule "compile time"). It may be awkward to actually implement even in static languages if they don't have runtime reflection.

[dslmeinte]

In essence, you propose to explicitly add a type system to JSON Logic.

There are some downsides to this. Bloating of the rule definitions is one, but the type system also represents a significant addition to the specification. An alternative would be to have a type-checking operation: at least then you don't have to overload the existing var operation with optional type information and corresponding runtime semantics.

If you want to stay on the static side of things, you could also think of validating (a set of) rules against a given JSON Schema (or some other JSON spec. format), or vice versa: deriving a JSON Schema (or some other JSON spec. format) from (a set of) rules.

[TotalTechGeek]

I need some time to fully digest this.

Incorporating type information into the AST could lead to better optimizations in the runtime performance, and some better safety, but requires a lot of scaffolding to make use of it.

My implementation actually does have some primitive checking at build time for certain operators (though it only validates on values it could acquire at comp-time),

logic.build({
  '+': ['hi', { val: 'a' }]
})

Would error at build time, rather than at run time, because of checks it performs at compile time for that operator.

My gut reaction to just validating val or var is: "What if instead, y'all just used JSON Schema on the context?" Although, that may not be ideal if the JSON Schema came from an untrusted source (could define a dangerous pattern which could lead to a redos attack).

--

I need some time to digest, I could see us adding a Community Extension to JSON Logic that introduces validation operators.

But I think mandating a comp-time type system to JSON Logic might require an aggressive rewrite of every implementation, so I'm uncertain if that's the direction we'd take for JSON Logic Core.

[TotalTechGeek]

While we might not mandate a compile time type system, we might consider publishing some sort of lint tool, that wouldn't necessarily need to be baked into every implementation of JSON Logic.

This wouldn't address every issue, but could address some of them.

[clbarnes]

I think a lint tool may be the way to go, with some understanding of what kinds of operands are valid for which operators. That understanding could maybe include settings for "would this work in a sensible type system" (/ strict) or "would this work in javascript" (/ wat) mode.

[dslmeinte]

Throwing shade JS's way, are you? 😃 No worries, as long as it's accompanied with a reference to “wat” it's alright!

I'd prefer to use the term “checker” because linters are usually about coding smells and style, but we're talking about constructs that will never work against data adhering to a certain JSON schema here.