Proposal / Question - Embedded Empty Object & Undefined Operators

[TotalTechGeek]

Background

In JSON Logic, we interpret objects as operator invocations.

{ "+": [1, 2] } 

Determines that the operator is + and invokes it with the arguments [1, 2]

We need to formally decide:

• How do we handle empty objects embedded in JSON Logic
• How we handle objects that do not map to an operator

Proposal

Part A (Empty Objects)

I'd like to propose that empty object passes through, making it easy to use as a parameter or setting it up as a default parameter in a reducer.

[
  { 
    "description": "Empty object passes through", 
    "rule": {},
    "result": {},
    "data": null
  },
  { 
    "description": "Empty object passes through, even embedded", 
    "rule": [{}, {}],
    "result": [{}, {}],
    "data": null
  }
]

Most implementations of JSON Logic handle empty object this way.

Part B (Unknown Operator)

I'd like to propose:

• With 1 Key, if the operator does not have an implementation, it should throw "Unknown Operator"
• With multiple keys, it should throw "Unknown Operator"*

Something along the lines of

[
    { 
      "description": "Single key object, does not map to operator. Should fail.",
      "rule": { "UnknownOperator": true },
      "data": null,
      "error": { "type": "Unknown Operator"  } 
    },
    {
      "description": "Multi-Key Object, both keys are not operators. Should fail.",
      "rule": { "UnknownOperator": true, "UnknownOperator2": true },
      "data": null,
      "error": { "type": "Unknown Operator" } 
    },
    {
      "description": "Multi-Key Object, one key is a valid operator (valid, invalid). Should fail.",
      "rule": { "+": true, "UnknownOperator2": true },
      "data": null,
      "error": { "type": "Unknown Operator" } 
    },
    {
      "description": "Multi-Key Object, one key is a valid operator (invalid, valid). Should fail.",
      "rule": { "UnknownOperator2": true, "+": true },
      "data": null,
      "error": { "type": "Unknown Operator" } 
    },
    {
      "description": "Multi-Key Object, both keys are valid operators. Should fail.",
      "rule": { "+": true, "-": true },
      "data": null,
      "error": { "type": "Unknown Operator" } 
    }
  ]

* The door is kind of open to consider multi-key operators in the future, but the operators selected are not intended for multi-key use, thus should fail.

[TotalTechGeek]

I do want to mention:

@gregsdennis: I would expect truthy({}) to fail because {} would expect a rule key, and it doesn't have one.

I wanted to separate the truthiness portion from the inline portion:

@TotalTechGeek: So I guess this splits into two separate concepts:

• Can {} be expressed inline, or should it throw? (json-logic-js and json-logic-php allow it -- json-everything actually currently does too)
• Is {} truthy or falsy, regardless of source (output of an operator, like pulled from context, or from inline)

[gregsdennis]

You can't separate them in a statement like truthy({}). It's both a question of truthiness and it is also inline.

What is the use case for supporting objects as data? Currently they have special treatment because they're the building block of rules. If you allow them as data, you need a way to distinguish the rule object from the data object. This needs to be discussed and resolved before the question of object truthiness can be addressed.

If objects are only rules, then the question of truthiness is moot.

If objects can be data, then we can discuss their truthiness.

[TotalTechGeek]

@gregsdennis Objects can be data, because you can pull them from context.

.github/tests/val.json

Line 67 in 8b79b20

"result": { "": 21 }

This is useful because you might want to return an object from an if statement or something like that.

In your implementation of JSON Logic (and I think all of them), you can fetch objects from context, example:

[ 
  {
    "rule": { "var": "x" },
    "data": { "x": { "name": "Greg", "tc": true } },
    "result": { "name": "Greg", "tc": true },
    "description": "Can pull an object from context"
  }
]

[TotalTechGeek]

Now, (and I believe this to be a separate issue), if someone wanted to embed object data inside of logic, and not pull it from context, the way json-logic-engine handles this is with a preserve operator.

So I can do:

{ "if": [true, { "preserve": { "name": "Bob", "age": 23 } }, null] } 

But I do believe as JSON Logic currently exists, objects already can be passed around because of var / val.

[gregsdennis]

the first key does not map to an operator

Objects are unordered so there is no "first" key. More critically, some languages are non-deterministic when iterating over object keys, and you'll never be able to determine a "first" key.

[TotalTechGeek]

I'm happy to revise this section; I was aware that different engines don't preserve key order.

From https://github.com/orgs/json-logic/discussions/17#discussioncomment-11679280

It introduces a ton of ambiguity in what the operator is vs what is an additional argument. Some implementations of JSON do not preserve key order, (postgres with jsonb will silently rearrange fields in your objects).

and Slack,

@TotalTechGeek: The challenge with multi-key operators is that there is no key-ordering requirement in JSON, and you'd need to figure out that try & catch go together,
Most languages try to keep the ordering anyway
@gregsdennis: Right. Similar to how + must be by itself, try must also have a catch and nothing else in the object.

In this case, I wasn't expecting the key order to necessarily be preserved, and just meant the "first key you can fetch from the object in your parser", which I realize causes differences between implementations, which isn't acceptable.

One choice is to define it to throw when multiple keys are used. This seems like the most straightforward option to me.

But I know that you had expressed interest in multi-key operators, which is a bit of a divergence from what JSON Logic currently supports . . . 🤔

[TotalTechGeek]

Funnily enough though; my test case is written in such a way where it does indicate it should return the "first key", the "key" portion of the error was thrown in as an after-thought, not really thought through 🙃

[TotalTechGeek]

@gregsdennis I have tweaked the proposal to get rid of the mention of first keys, and have set it up to throw if multiple keys are used in an invocation.

The door is not completely shut on multi-key operators, as the operators selected for the test shouldn't be multi-key compatible, but this does kind of lean against it.

[TotalTechGeek]

Self +1.

Current Votes

Aggregate	TC Votes in Favor	Votes
3	3	@TotalTechGeek (+1) @gregsdennis (+1) @codetiger (+1)

Here is a link to our voting procedures.

[codetiger]

+1