Introductions

[TotalTechGeek]

Hey folks and @json-logic/core 👋🏻

We haven't quite heard from everyone yet,

But so far, of the people in the organization we have representation across:

• C
• C++
• C#
• Python
• Rust
• Ruby
• JavaScript
• Elixir
• Kotlin Multiplatform (So JVM + Swift)
• Java
• Go
• Haskell

I wanted to build a table of project maintainers

Project	Language	Maintainers Represented
json-logic-php	PHP	@jwadhams (Creator)
json-logic-js	JavaScript	@jwadhams (Creator)
json-logic-engine	JavaScript	@TotalTechGeek
datalogic-rs	Rust	@codetiger
json-logic-rs	Rust	@jstewmon
json-everything's JSON Logic	C#	@gregsdennis
JsonLogic.Net*	C#	@yavuztor
JsonLogic.Net*	C#	@pandaGaume
JSON Logic (Go)	Go	@diegoholiveira
go-jsonlogic	Go	@the729
json-logic-ruby	Ruby	@Stashchenko
jsonlogic (Python)	Python	@Viicos
panzi-json-logic	Python	@panzi
jsonlogic-c	C	@panzi
johnzon-jsonlogic	Java	@rmannibucau
json-logic-kmp	Kotlin Multiplatform (JVM, Swift)	@KTGypsy
json-logic-cpp	C++	@gabrielkim13
json-logic-java	Java	@jamsesso
json_logic_elixir	Elixir	@liuming
json-logic-haskell	Haskell	@JTeeuwissen

* These implementations are different

We also have @dslmeinte who worked on the CertLogic specification for the EU, which is a subset of JSON Logic, and responsible for developing a few implementations.

We also have a few folks from OpenFeature, (@toddbaert, @beeme1mr), and some folks who have been active in the JSON Logic community (@addonovan, @josephdpurcell)

If I've missed a maintainer, I apologize, I'll try to keep this table of implementations up to date!

But say hello!

[josephdpurcell]

Thanks for organizing this, it's very exciting to see!

[codetiger]

Thanks for putting the list together. Let me try to cover this list in the compat table test suite repo.

I feel this list should be easily accessible from the home page.

[codetiger]

I've added libraries from JS, Rust, Python and Go. I need some help in reviewing and sharing feedbacks.
https://github.com/json-logic/compat-tables/blob/main/README.md
Especially the library https://github.com/Viicos/jsonlogic tests needs some review.

[codetiger]

Once we have the official spec rolled out, we can split the test cases to core and optional extensions so that is easy for maintainers and users understand the compatibility

[jwadhams]

yeah love this idea, I feel like I've fielded lots of issues where someone wants a new operator, but especially before this community existed, there was no great way to persuade all the other implementations to adopt it. Letting individuals provide new operators helps, but we're missing something like a plugin ecosystem where we could share clusters of operations as libraries (dates would be popular, for instance).

[dslmeinte]

“Once we have the official spec rolled out” sort-of suggests a big bang-style release of said spec. I can really advise doing things in an iterative/incremental way: specify one construct (literal, operation, etc.) to bits (including fault scenarios and how to respond to those, ideally), including a construct-specific test suite, and give every implementor the chance to check for compatibility w.r.t. that construct, before moving on to the next. This gives you also the chance to finetune the exact format of the specification without committing to delivering the whole thing in one go — and possibly needing to revise the whole thing a couple of times.

[codetiger]

Yes, agreed. The repo Compat table take the test.json as input and builds the compat table for all available libraries. The initial version of spec is going to use most of the currently common operators across libraries, that's my understanding based on other discussions in this forum.
Meanwhile, the test suite supports modifying the test data and categorization later. The entire report is generated based on how the test data is categorized. So changing the test data later and re-running the script is all we need.
Also if a maintainer wants to check their language specific libraries or a specific set of test cases, they can use a custom test data and use the suite unmodified.

[TotalTechGeek]

Heya; full agreement w/r/t doing things incrementally.

Right now we're using the tests.json file that came from jsonlogic.com, but in the very near future we'll start breaking down the test suite into different operators and add more tests for each.

Some decisions do need to be made before this happens (val, whether we document coercion principles into the comparison operators, etc), but I think we'll be reaching that point soon.

Then we'll end up with test suites for each of the operators, some might be grouped into families though: core/substr.json, core/val.json, core/comparison.json, core/arithmetic.json, legacy/var.json type of deal

I think we'll reevaluate each operator to ensure we define behaviors that may have been previously ambiguous.

[jwadhams]

Yeah I agree with breaking up the tests wholeheartedly, that file was probably too long to reason about when I committed it (that's why it needs the comment syntax).
A refinement I'd propose is that we start versioning the spec and therefore the unit test files. As we change or add operators, all the language implementations (and installed versions) won't move in lockstep. A versioned spec lets implementing libraries or even shared rules express "I was tested with spec x.x.x"

[jwadhams]

I really like @dslmeinte 's recommendation that we document and shore up 1.x incrementally, and also, depending on people's appetite, we might form a team that's interested in a big bang v2.0.0 too. For example, the language has never been good at "rules can be in any arbitrary position inside a huge JSON file" (which Amazon's CloudFormation is good at) but that might require operators moving to a namespace where they are more unlikely to clash with data. (e.g. {"!var":["apple"]}) With years of hindsight and issues, I think the single-argument syntactic sugar was a terrible idea (so removing {"var":"apple"} and {"!":false}). The map and filter tools also appear to require a big bang fix to make their power users happy. There are use cases of the unversioned spec where I might have painted us into a corner we can't escape with incrementalism.

[TotalTechGeek]

Hey @jwadhams, do you have some time to catch up / potentially huddle today / soon?

There've been a handful of discussions I'd love to loop you in on / summarize. I'd also like you to be on the TC, even though we fully acknowledge the mixed availability.

A heads up:

• Some operators might end up designated as a "Legacy Extension" (var, missing, missing_some) which will continue being tested in compatibility tables and encouraged for implementation
• Some operators might be introduced to replace them for "Core", like val, which removes path parsing semantics from the operator, and makes it fully AST-like {val: ['hello', 'world']}. This fixes some issues with empty keys and such without adopting a new path notation. It also allows for things like { val: { rfc6901: '/hello/world' } }

where I might have painted us into a corner we can't escape with incrementalism

We might not be able to retrofit some of the operators; but I think we can define substitutes as described above.

But I really think most of JSON Logic will be easy to pull forward into "Core".

[TotalTechGeek]

With years of hindsight and issues, I think the single-argument syntactic sugar was a terrible idea

On this issue specifically -- I believe there's a way to modify this behavior slightly so that backward compatibility doesn't get busted, but enables operators to be chained together much more seamlessly. (As seen above in the val and rfc6901 custom operator, rfc6901 returns an array, which is used as arguments for val).

This enables use-cases where I could do { max: { map: [{val: 'people'}, { val: 'salary'}] } }