Skip to content

RFC: Report on Implementations' Statuses #314

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Julian opened this issue Nov 29, 2019 · 8 comments
Closed

RFC: Report on Implementations' Statuses #314

Julian opened this issue Nov 29, 2019 · 8 comments
Labels
enhancement An enhancement to the tooling or structure of the suite (as opposed to a new test).

Comments

@Julian
Copy link
Member

Julian commented Nov 29, 2019

There should be a mechanism by which implementers (currently mentioned in the README or otherwise) can submit their implementation to be automatically tested and displayed on each commit to the test suite.

Specifically, we would report on:

  • number of failing tests
  • supported drafts

At first thought, an easy implementation may be to have each participating implementation implement a black-box executable which:

  • takes one test as input on stdin, and one argument, the metaschema ID for the metaschema of the provided test
  • exits successfully for valid instances
  • exits with non-zero exit status for invalid ones
  • optionally writes to stdout an object in the draft2019-09 (or later) output format containing output about the validation process

Internally then (here in the test repo), we run each of these binaries via a GitHub action, collect the results, and expose them for viewing.

(This issue is very open for discussion from implementers -- comments welcome.)

@Julian Julian pinned this issue Nov 29, 2019
@Julian Julian added the enhancement An enhancement to the tooling or structure of the suite (as opposed to a new test). label Nov 29, 2019
@Julian
Copy link
Member Author

Julian commented Feb 9, 2020

@gregsdennis found https://cburgmer.github.io/json-path-comparison/ for a similar effort on JSON path.

@gregsdennis
Copy link
Member

I've invited him to do the same thing for us (or at the very least let us copy/modify what he's done).

cburgmer/json-path-comparison#27

@gregsdennis
Copy link
Member

Looks like it's a copy/modify, if people here are okay with going that direction.

@gregsdennis
Copy link
Member

@cburgmer wrote up some of the logic behind his test suite. It's a really good read and a lot of the reasoning applies well to JSON Path.

Primarily of note, there are no "expected" test results. He's truly performing a comparison between implementations and reporting on what he calls the consensus between them, determined by a majority-plus-one of the available implementations agreeing on the output. He does this because there is no specification for JSON Path, so no really "correct" response for any given query.

Since we have a specification, we don't need the consensus concept. Our test suite explicitly states the expected result, so we just need to report adherence to that result. The thing I like from his report is the report itself.

I'll work on modifying it so that it can at least run my implementation. I'd like other implementors to add their own libraries, but if I can work out how to do some of them, I'll start at the top of the implementation list on the site and work down.

@cburgmer
Copy link

If it helps you I can call out the complexity in the json-path-comparison:

  1. Consensus building
  2. Understanding the domain and define test cases
  3. Handle implementations across all languages

As 3. probably applies to your goal as well I can clarify this point:
3.1. Provide one view into the different languages.
3.2. Make results reproducible (reduce source of indeterminism)
3.3. Deal with the sheer amount of work that's different for every tool stack.
3.4. Make it work across operating systems (Docker)

@Zac-HD
Copy link
Contributor

Zac-HD commented Sep 30, 2020

It would be great to keep the consensus logic though, because this test suite isn't the only data we could compare implementations on.

If we have a blackbox setup for various implementations, I'd be happy to set up a fuzzing harness which uses hypothesis-jsonschema to generate random instances matching (or almost matching) both real-world or randomly generated schemas. It's been ridiculously effective for me, and I'd be interested in seeing the minimal examples about which implementations disagreed...

@karenetheridge
Copy link
Member

karenetheridge commented Nov 28, 2021

$ json_schema_evaluate --add_schema resource1.json --add_schema resource2.json --add_schema resource3.json --schema main_schema.json --data data1.json
{"valid": true }
$ echo $?
0

$ json_schema_evaluate --add_schema resource1.json --add_schema resource2.json --add_schema resource3.json --schema main_schema.json --data data2.json
{
  "valid": false,
  "errors": [
    {
      "instanceLocation": "",
      "keywordLocation": "/minimum",
      "error": 'value is smaller than 2"
    }
  ]
}
$ echo $?
1

@Julian
Copy link
Member Author

Julian commented Aug 30, 2023

I'm going to close this as well and say "Bowtie is this". Help + feedback definitely still welcome, or results are continuously here.

@Julian Julian closed this as completed Aug 30, 2023
@Julian Julian unpinned this issue Dec 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement to the tooling or structure of the suite (as opposed to a new test).
Projects
None yet
Development

No branches or pull requests

5 participants