Have a way to easily validate JSON-AD

[joepio]

I'd like users to be able to validate JSON-AD in their browsers. It should not be too hard to build this, but it would be useful to have this and link to it from the Atomic Data Docs.

Approaches:

Part of atomic-data-rust (Rust, CLI + Server)

• Makes is available in the atomic_lib crate, inatomic-server as an Endpoint (which means we also have a GUI)
• easy to make validation function available in atomic-cli, too, which can be used in CI.
• Fastest, because the server can use cached resources (or should we not use these?)
• Allows API calls for validating data

Part of @tomic/lib (Typescript, data-browser)

• Means the validation is performed in-browser.
• I won't make a CLI tool (too much effort to maintain 2 CLIs).
• Will result in a prettier, more specific, potentially more powerful GUI

[jonassmedegaard]

Please consider writing this validation logic as a separate project, with a library and a simple command-line application. Atomic Server can then integrate the library for that endpoint you envision (without pulling in CLI-specific dependencies), while the command-line tool can be used e.g. in a git commit hook where you would not want to require online access for a syntax validator.

[joepio]

It will be an extremely small wrapper around functions that already exist in atomic_lib, so it will be part of that library. But I can also add it as a command to atomic-cli (which is pretty lightweight, and uses atomic_lib), that sounds reasonable.

[jonassmedegaard]

ok, I thought of atomic-cli as a helper tool for Atomic Server, but realize now that helper functions like --initialize are instead tied to command-line tool atomic-server.

Makes sense to add this to atomic-cli then, I guess.

For options convenient for using atomic-cli as a Code Quality Meta Tool, I recommend to read this blog post which was a precursor for its author abanding his old perl-based project tidyall and begin new Rust-based project precious.

[joepio]

Thanks! It also make sense to keep Git management in consideration here, since running these checks on commit would prevent issues #97

[jonassmedegaard]

For in-browser validating the ideal would again be to not depend on network access, by implementing a validator in JavaScript and shipping that both as an NPM library and wrapped as a plugin for Mozilla- and Chromium-based browsers.

[jonassmedegaard]

...or use that fancy WASM-based sandboxed compilation you have talked about, I guess :-)

[joepio]

For in-browser validating the ideal would again be to not depend on network access, by implementing a validator in JavaScript and shipping that both as an NPM library and wrapped as a plugin for Mozilla- and Chromium-based browsers.

It would still kind of depend on net access, though, since it will need to check if the properties are online and match the datatypes.

...or use that fancy WASM-based sandboxed compilation you have talked about, I guess :-)

Would be the coolest, but I don't have any of that working yet...

I think the rust approach seems the most realistic, although adding a validate function in @tomic/lib typescript is probably not that much extra work.

[jonassmedegaard]

It would still kind of depend on net access, though, since it will need to check if the properties are online and match the datatypes.

Ah, right. That information could be cached, though - spewing a warning if cached data becomes stale (and either option --no-network or env variable ATOMIC_NO_NETWORK is set, or auto-refresh of cache fails e.g. at a failing or missing network connection).