3 ms·

LIVR: Language Independent Validation Rules

50 points by based2 6y ago

ethbro 6y ago
Out of curiosity, are there any other major libs in this space? (It's not something I've spent a lot of time looking at)
- gioazzi 6y ago
  https://cuelang.org/ https://cuelang.org/ Not entirely the same, but some use cases overlap.
- devj 6y ago
  JSONLogic - http://jsonlogic.com/ http://jsonlogic.com/
- devj 6y ago
  CEL spec: https://opensource.google/projects/cel https://opensource.google/projects/cel
correct_horse 6y ago
All the examples are for validating JSON, and the documentation repeatedly mentions JSON, but I can't tell if this project is usable with non-JSON serialization formats. It never explicitly mentions that it is JSON-only.
- sradman 6y ago
  It looks like it is more about declarative data structure validation in various language runtimes. Some of the implementations [1] (the interpreted languages like Perl, PHP, Python, and Ruby) seem to use the language's natural literal notation instead of JSON (or JavaScript Object Literals). It seems to be missing the "step" constraint from HTML5 Form Validations and nullability constraints from SQL (though there is overlap with 'required'). [1] https://livr-spec.org/introduction/implementations.html https://livr-spec.org/introduction/implementations.html
deleted 6y ago
[deleted]
melbourne_mat 6y ago
In case you missed it, this is not a programming language parser/validator: it's to validate data objects in an information system. Validating a form submission would be a good example. It looks to be along similar lines to JSON schema. From the LIVR docs: "Rules should be able to change results output" My opinion is that if you're going to use a declarative validation engine like this then it should not be able to modify the data entity being validated.
- sedatk 6y ago
  I think that applies to normalizations (trimming, case changes etc). It makes sense to have those declarative and universal too.
CraigJPerry 6y ago
Rather than having independent language implementations of LIVR which can diverge, stop being maintained etc. etc. What about having a common description of the supported behaviours then compile these to each supported language? Like AWS generates its language bindings API descriptions: https://github.com/aws/aws-sdk-js/tree/master/apis https://github.com/aws/aws-sdk-js/tree/master/apis https://awsfeed.com/whats-new/open-source/generate-python-java-and-net-software-libraries-from-a-typescript-source https://awsfeed.com/whats-new/open-source/generate-python-ja...
- dangoor 6y ago
  Isn't this essentially an implementation detail? For example, there could be a tool that takes LIVR spec as input and generates nicely typed Go could that returns properly validated input?

50 points by based2 6y ago

Out of curiosity, are there any other major libs in this space? (It's not something I've spent a lot of time looking at)

gioazzi 6y ago
https://cuelang.org/ https://cuelang.org/ Not entirely the same, but some use cases overlap.
devj 6y ago
JSONLogic - http://jsonlogic.com/ http://jsonlogic.com/
devj 6y ago
CEL spec: https://opensource.google/projects/cel https://opensource.google/projects/cel

correct_horse 6y ago

All the examples are for validating JSON, and the documentation repeatedly mentions JSON, but I can't tell if this project is usable with non-JSON serialization formats. It never explicitly mentions that it is JSON-only.

sradman 6y ago
It looks like it is more about declarative data structure validation in various language runtimes. Some of the implementations [1] (the interpreted languages like Perl, PHP, Python, and Ruby) seem to use the language's natural literal notation instead of JSON (or JavaScript Object Literals). It seems to be missing the "step" constraint from HTML5 Form Validations and nullability constraints from SQL (though there is overlap with 'required'). [1] https://livr-spec.org/introduction/implementations.html https://livr-spec.org/introduction/implementations.html

deleted 6y ago

[deleted]

melbourne_mat 6y ago

In case you missed it, this is not a programming language parser/validator: it's to validate data objects in an information system. Validating a form submission would be a good example. It looks to be along similar lines to JSON schema. From the LIVR docs: "Rules should be able to change results output" My opinion is that if you're going to use a declarative validation engine like this then it should not be able to modify the data entity being validated.

sedatk 6y ago
I think that applies to normalizations (trimming, case changes etc). It makes sense to have those declarative and universal too.

CraigJPerry 6y ago

Rather than having independent language implementations of LIVR which can diverge, stop being maintained etc. etc. What about having a common description of the supported behaviours then compile these to each supported language? Like AWS generates its language bindings API descriptions: https://github.com/aws/aws-sdk-js/tree/master/apis https://github.com/aws/aws-sdk-js/tree/master/apis https://awsfeed.com/whats-new/open-source/generate-python-java-and-net-software-libraries-from-a-typescript-source https://awsfeed.com/whats-new/open-source/generate-python-ja...

dangoor 6y ago
Isn't this essentially an implementation detail? For example, there could be a tool that takes LIVR spec as input and generates nicely typed Go could that returns properly validated input?