Reason for creating this library?

[k7sleeper]

I'd like to know why development of this library was started although there are JSON schema validation libraries out there? What are the features of this library which make z-schema different from other libraries (i.e. natesilva/jayschema)? Is it the Promises/A+ based API?

[zaggino]

Promises API wasn't the main reason although I quite like to have it this way. Main reason was that I made some quick tests about the other implementations and realized that no-one had something like strict mode (https://github.com/zaggino/z-schema#strict-validation) or schema compilation. Plus some implementations I tested weren't covering all of the JSON v4 specification.

At first I thought of making a pull request for an existing implementation but then I found myself with quite a lot of free time so I've decided to read JSON schema specification word by word and implement it the way I like it to be.

It might not be the fastest implementation out there, but it's fast enough in cases where I use it (certainly not a bottleneck thing). It's also covering a huge amount of tests (https://github.com/json-schema/JSON-Schema-Test-Suite) and I'll definitely try to fix all the bugs the people can find.

[k7sleeper]

Thank you, for that detailed explanation! It helps me a lot.

If z-schema supports schema compilation but is not the fastest, what's the reason of schema compilation, and why are other libraries without schema compilation faster than z-schema?

[zaggino]

I haven't said its not the fastest, I never did any tests for speed and it would be quite hard to effectively compare async implementation vs sync one. This implementation is focused on features rather than speed.

Goal of schema compilation is mainly to download remote schemas that are references by your schema. See this test for example https://github.com/json-schema/JSON-Schema-Test-Suite/blob/develop/tests/draft4/refRemote.json

It would not be possible to download remote references in sync implementation. Compilation is there so you don't download it over and over again when validating tons of objects against the same schema.

[zaggino]

Let's leave it open if others had the same questions as you did ;-)

[zaggino]

I put together some performance benchmarks, results are currently like this:

$ node benchmark.js
tv4#basic x 29,134 ops/sec ±0.24% (99 runs sampled)
jayschema#basic x 935 ops/sec ±1.02% (96 runs sampled)
z-schema#basic x 13,854 ops/sec ±1.85% (90 runs sampled)
Fastest is tv4#basic
tv4#advanced x 3,668 ops/sec ±1.37% (97 runs sampled)
jayschema#advanced x 158 ops/sec ±2.28% (82 runs sampled)
z-schema#advanced x 4,046 ops/sec ±0.45% (100 runs sampled)
Fastest is z-schema#advanced

[statico]

@zaggino Also, it seems that your module is one of the few that populates defaults in the resulting objecting. However, I don't see a test for that — is that the case?

[zaggino]

Does it? I don't think so. But support for this (and any other fully customizable behaviour) is planned soon in #24

[zaggino]

Performance benchmarks are available here:
https://rawgithub.com/zaggino/z-schema/master/benchmark/results.html

[arunkjn]

thanks @zaggino great library.

[zaggino]

FYI

version 3.x will be a complete rewrite of everything done here (all tests and features will be of course migrated), so far it's looking good: https://rawgit.com/zaggino/z-schema-3/master/benchmark/results.html