Add JSON schema and validation script

[psvenk]

Closes #15. This schema is written to fit the current format of JSON scheme descriptions. As discussed in https://github.com/sanskrit/sanscript.js/pull/13, some further work should be done after this PR to improve this format to be more consistent and to capture some of the details that are currently expressed in code (e.g. the definition of the Kolkata scheme and the Brahmic/roman distinction).

[psvenk]

Perhaps we should try to integrate validate.js into the unit tests. I think ajv supports browsers, so we could just load it in test/index.html from node_modules as we load QUnit now.

[rramphal]

Ideally, both the validate and the test steps would be their own build steps runnable via npm scripts. That doesn't mean that we can't also use them within the test/index.html file, though. I think your current approach takes us in the right direction.

[psvenk]

Ideally, both the validate and the test steps would be their own build steps runnable via npm scripts.

I agree. The test script seems to be failing now because QUnit cannot find the definition of the Sanscript object. I see two solutions to this:

• Run QUnit as qunit --require ./sanscript.js. This would mean either including the module.exports boilerplate in such a way that a browser will safely ignore it or making the build process strip it out or make a separate version of sanscript.js that is a CommonJS (or possibly ES6) module.
• Make the build process concatenate the generated sanscript.js with the source tests.js to produce the tests file. This would introduce less complexity to the build process, and anyway running the build process is required to run the tests (because tests/index.html references ../sanscript.js).

As for validation as one of the tests, I now realize that this would not be possible in a browser because filesystem access is needed (unless validate.js goes through a build process that integrates the contents of the JSON files, but that is a lot of complexity for little gain), so it would probably be better just to have validation separate from unit tests (especially considering that the sorts of changes that would trigger errors in each are mostly orthogonal to one another).

[psvenk]

@vvasuki Is this ready to merge?

[vvasuki]

Sure - go for it (generally plz don't wait on me - Some of the tech is new to me, and you seem to have good judgement.)