OSI-level validations?

[siljamardla]

What are the ideas around validations of the semantic layer? Should this be left fully on the tools that import/export or should there be an OSI validation "engine" included?

There are several validations I would care about:

1. Field and metric names being unique (within the context of a semantic model)
2. SQL being valid - with the current spec the metric definitions could be arbitrary text resulting in invalid SQL

[kurtStirewalt]

I personnally think we should lean into validation by providing parsers and type checkers that help ensure the quality of a model in the OSI. That gets harder to do the more we try to support different dialects.

[ralfbecher]

How about adding a JSON schema for YAML validation? This could at least help with basics when editing the YAML file..

https://github.com/ralfbecher/OSI/blob/json-schema/core-spec/osi-schema.json

[ralfbecher]

Also added a validator here:

https://github.com/ralfbecher/OSI/blob/json-schema/validation/validate.py

[redblackcoder]

How about using some of the more modern config templating languages?
#62

[djwaldo]

Related gap noticed while building the ThoughtSpot converter (#285): converters/README.md step 1 tells an export converter to validate its source OSI model, and step 9 validates the vendor output against vendor tooling. Nothing tells an import converter to run validation/validate.py on the OSI document it produces, even though the validator's four checks (schema, uniqueness, references, expression parse) are exactly the contract that output must satisfy. We're doing it anyway and it caught real issues. Suggest adding it as an explicit step in the converter guide.