crystal-lang / crystal

The Crystal Programming Language
https://crystal-lang.org
Apache License 2.0
19.26k stars 1.61k forks source link

Crystal should be able to handle XSD validation #12131

Open renich opened 2 years ago

renich commented 2 years ago

Discussion

Blacksmoke16 commented 2 years ago

Ultimately this discussion needs to yield an answer to two question:

  1. Is this something we want to have in the stdlib versus an external shard
  2. If so, what the API/implementation should look like
beta-ziliani commented 2 years ago

I suppose the best way forward for such a proposal is to start as a shard, and then if probed useful move it to stdlib. But definitively this can be a place to discuss a possible API.

stellarpower commented 2 years ago

Would there be any feasability of a common validation framework that could encompass features from a variety of data languages? I have just been trying to use the Json Schema shard without enormous success, although I tihkn half of this is that last time I worked with JSON schemata it was not pleasant, and seems to be a headachey system - the website examples did not work with the CLI tool I have downloaded.

Presumably, when serialising and deserealising from any language, there is a certain amount of common work - macros to generate classes, basic validation of values, some sort of parsing infrastructure. If possible, it might be nice to see some of this encapsulated in a common way, that can then be specified and tailored for different languages (JSON, YAML, XML, TOML, I don't know what else off the top of my head...).

Also an aside, but I have just come across TypeSchema trying to see if there's an alternative I could use more easily. NOt so relevant for XML, but supporting osmehting cross-language like this may be an interesting thing if someone wanted to pick it up.

Edit: Nicolab/crystal-validator seems to be doing something like this

Let me reword this slightly - in order to apply the DRY principle, when different document/data languages are serialised or deserialised, they are working around a common way to represent data in the language (classes and structs, or arrays and hashes, of course. We also have the macro system to support generating boilerplate at compile-time, and schema parsers can utilise this to generate their classes automatically). In parallel, I would like to see a common way of validating data within Crystal, and then, for validators specific to languages that crystal can serialise and deserialise to/from hook into that generic validation framework, in order that each language validator need then only tailor the generic features to the semantics of what that language is able to provide or requires.

Blacksmoke16 commented 2 years ago

I would like to see a common way of validating data within Crystal, and then, for validators specific to languages that crystal can serialise and deserialise to/from hook into that generic validation framework, in order that each language validator need then only tailor the generic features to the semantics of what that language is able to provide or requires.

By language do you mean format? Because I think there are few somewhat separate things being discussed:

  1. Validation based on external format specific schemas. E.g. XSD, or JSONSchema. Which is what this issue is about (for XML at least).
  2. Representing data in Crystal after deserializing it from possibly different formats various formats. Which is what JSON::Serializable and YAML::Serializable are intended for.
  3. Validation based on business logic defined in Crystal. Which is what that shard you mentioned handles. Is also Athena Validator FWIW.

Depending on how you're envisioning this to work, a forum thread (or at least a separate issue) might be a better starting point. As this one is purely focused on:

Given an XML string, how can I validate it with an existing XSD file

PhilAtWysdom commented 1 year ago

This is something that we're have been planning to use a binding to libxml2 for, in our application. It would be much nicer though, if it were as a shard or ultimately, built-in, for sure.