Would you be interested in collaborating to develop a JSON Logic Specification?

[TotalTechGeek]

Hey @Viicos,

I stumbled across your implementation of JSON Logic and saw that it had some recent active development!

I'm trying to reach out to maintainers of JSON Logic implementations to try to consolidate differences, and perhaps collaborate to develop a more cohesive specification.

For example, I noticed that your project implements var differently. Honestly not a bad idea, though I'm a bit nervous about it not being backwards compatible.

EDIT - I think there might be an error in the Resolving variables documentation, and your proposal might be perfect. Assuming / refers to the 2 in { "": 2 }.

I wanted to reach out and see if you'd be interested in being a part of a community effort to try to reconcile some of the differences between JSON Logic implementations, and put together a more comprehensive specification and test suite?

I maintain json-logic-engine (JavaScript), and I'm currently communicating with the authors of datalogic-rs (Rust) and json-everything's (.NET) implementation of json-logic.

---

EDIT - I figured I'd also throw in my two cents about how I handled the variable resolution & scope.

JLE and some other modules implemented escaping from dot-prop notation to try to maintain backwards compatibility.

If there's a variable with a dot in it, we escape it with \, so someone can write { var: 'hello\\.world' } to escape the separator.

To access an empty string { "": 1 }, you can use { var: '.' }, and if you needed to access { "": { "": 2 } }, you'd use { "var": ".." }.

If you needed to access { ".": 3 } you'd use { var: "\\." }. Admittedly, it is a little awkward and less ideal than an existing RFC, but is backwards compatible with the implementation most engines use.

To handle scopes in iterators, JLE's approach was to implement Handlebars style data traversal.

So let's assume your data is stored as { x: 5 }

Let's say you wanted to add each element of an array to the x value, and to the index of the iterator, you'd write:

{ 
  map: [
      [1,2,3], 
      { '+': [{ var: '' }, { var: '../index' }, { var: '../../x' }] }
   ]
}

Anyway, this isn't an attempt to prescribe a solution -- I believe that the fact that folks have tried to identify different solutions indicates the need for discussion and a more rigid specification

---

Examples of issues I think need discussed & spec'd:

• Data: How do you access { '': 1 }?
• Data: How do you access { 'hello.world': 1 }
• Truthiness: straightforward, but a compat table might be helpful
• How do you handle { "!": [0] } vs { "!": 0 } -- this one is more straightforward; but a common compat issue.
• How do you handle { "!": { "var": "data" } } where data resolves to [0], is it treated like [[0]] or [0]?
• How do you access context in iterators? {filter: [{var: 'arr'}, {'===': [{var: 'item'}, {var: '../../choice'}]}]}; explanation: In most implementations, you're unable to access above context in your iterator, so you can't use data to add numbers together, or filter things out.
• .length, should var in JSON Logic have a dedicated handle to allow a user to fetch .length if the property does not exist on the object naturally? This makes logic incompatible in between interpreters; so should .length be treated as a special path, or be given a reserved operator 😉

[Viicos]

Hi @TotalTechGeek,

I also thought about first writing a proper specification before going into the implementation, but ended up giving it a shot to see the challenges I would face.

This Json-Logic implementation was designed to be extensible. Meaning:

• A registry pattern is available, so that you can define your own operators. The implementation provides a default jsonlogic.operators.operator_registry registry instance, but it does not include all the already existing operators.
• Variables resolving can be customized. By default, it uses the JSON Pointer format, but I also provide DotReferenceParser, aligned with the JS implementation:

  from jsonlogic import JSONLogicExpression
  from jsonlogic.evaluation import evaluate
  from jsonlogic.operators import operator_registry
  from jsonlogic.resolving import DotReferenceParser
  
  expr = JSONLogicExpression.from_json({"var": "my.data"})
  
  root_op = expr.as_operator_tree(operator_registry)
  
  return_value = evaluate(
    root_op,
    data={"my": {"data": 1}},
      data_schema=None,
      settings={
          "reference_parser": DotReferenceParser(),
      },
  )
  
  assert return_value == 1

Regarding the dot-prop notation, escaping the . with \\. should cover most use cases, but what if the key is actually some\\.data? e.g.

{"some\\.data": 1}

What's nice about the JSON Pointer spec is that special characters are safely escaped, and it is thus completely unambiguous.

The ../ syntax to deal with scopes is also an interesting alternative, although it also suffers from the same issue, if you want to escape ../ in some way.

---

As you can see, I wrote this library with customization in mind. If we were to write a formal specification, we'd have to find the right balance between giving freedom to the users (e.g. should we define a fixed set of operators? Should we use a single reference format?) and restricting the specification. My implementation is also tightly coupled with the JSON Schema spec, mainly to typecheck the JSON Logic expression, but also during evaluation.

When it comes to truthiness (and more generally how operators behave with certain data types), a specification would have to be language agnostic (and the current JsonLogic JS implementation relies on the JS behavior, which really is a bad choice as we all know JS is a pain with operators on data). Similarly, should the spec enforce the behavior (e.g. we allow >/< operators on strings, the truthiness of an empty array is false, etc)?

And most importantly one limitation that should be tackled in some way:

There's no way to mark a JSON object as being actual data, and not an operator. Say you want to evaluate:

{
    "if": [
        false,
        {
            "arbitrary": "data"
        },
        {"var": "/mydata"}
    ]
}

with data:

{
    "mydata": {"other_arbitrary": "data"}
}

That should evaluate to {"arbitrary": "data"}, but this expression is invalid because the implementation will try to look for an operator named "arbitrary".

[TotalTechGeek]

what if the key is actually some\\.data

Then you use { "var": "some\\\\\\.data" } which is admittedly a bit ugly 😉.

want to escape ../ in some way.

In that case, { "var": "\\.\\./" } and { "var": "\\.\\.\\/" } would work.

---

To be clear, I've no gripes with RFC6901; I think it's a great standard, and JSON Logic would likely be in a better place had it been implemented with it. (And I realize by doing the dotpath notation escaping thing, I've basically just produced an alt-standard 🙃)

However, JSON Logic is used enough in the wild to where I'm a bit concerned about changes that are likely to break existing logic.

But! I don't think that's for me to decide unilaterally 😂; I want to try to get a group of maintainers together to discuss some of the weaknesses in JSON Logic, and build out a more formal spec.

There's no way to mark a JSON object as being actual data, and not an operator

You're right! At least, not built into the mainline implementation.

JSON Logic Engine solves this in a few different ways, the recommended way is to use the built in preserve operator, which can be used to embed data in your template,

{ 
  "if": [
    true, 
    { "preserve": { "first_name": "John", "last_name": "Doe" } },
    null 
  ] 
}

I also allow you to specify it by overriding an isData method in the engine, or turn on permissive mode to keep something as data if it does not resolve to an operator.

However, I think standardizing a preserve-like operator might help the ecosystem & keep things more portable without requiring a bunch of interpreter configuration options to be added.

a specification would have to be language agnostic

I agree that this would be the way. I brought up the .length issue because it's not an agnostic behavior.

For the record though, a good chunk of the prescribed behaviors are actually from PHP, not JS.

The empty array being falsey for example 😄

---

At this stage, I'm mainly trying to ask: Would you be interested in participating in the spec discussions with other project maintainers? 😛

[Viicos]

Hi @TotalTechGeek apologies for the slow answer.

I think there's value in standardizing things. I answered in https://github.com/orgs/json-logic/discussions/1. I don't know yet how much free time I'll have to participate into this, but I can provide occasional feedback.