💭 [REQUEST] - Validator 3.0

[jondavid-black]

Reference Issues

681

671

This is a blocker for #675

Summary

As an AaC developer, I want to simplify the modeling, creation, and usage of validators so that plugin development is simpler.

An expected advantage would be the elimination of duplicated validation execution and an increase in runtime performance.

AC:

• [x] Must establish a context_validator that applies to the global context of the model.
• [x] Must establish a schema_validator that applies to specific structural model declarations.
• [x] Must establish a primitive_validator that apples to specific value model declarations.
• [x] Must update gen-plugin to simplify development of validators from a plugin/validator model.
• [x] The validation command should only provide errors unless commanded by the user
• [x] Add a parameter to the validation command to allow for verbose reporting (warnings and info)
• [x] Add a parameter to the validation command to allow for handling warnings as errors
• [x] Validation errors must provide the lexeme that caused the error in the ouput.
• [x] Do not treat validators as plugins in the plugin-manager (they cannot be enabled/disabled individually)
• [x] Must streamline validator execution so that a validator is run only once per item under evaluation.
• [x] Must change the names of things to align with recommendations from #671

Basic Example

The context validator would be very similar to the existing validators but would not provide a unit under test in the execution api. The root_keys validator is probably a good example of a context validator and would require only minimal updates.

The schema validator is really just the validator we currently use. The required_fields validator is a good example of this.

The primitive validator is going to be similar to existing primitive validators. The validators under primitive_type_check are example of this.

The validator definition will be changed to not use behavior explicitly, but will contain many of the same behavior fields. Each validator should be stand-alone, and not have a list of potential behavior defined in the model. While the idea of reuse was good here, it doesn't align as well as it could with how validators work in the AaC system.

What are the drawbacks/impacts of your feature request?

No drawbacks/impacts are currently known. There are no validator developers outside the AaC team, so nobody should be impacted. We will have to update the 3rd party plugin once this is completed.

Unresolved questions

There's been good discussion here, so I don't believe we have any unresolved questions at this time.

[jondavid-black]

I made some progress on this, but it has kind of exploded. One thing just keeps leading to the next. It got to the point that I abandoned the branch and started working a new internal API to make some of this workable. Details are in #691.

[lizzcondrey]

Believe the majority, if not all, of this got incorporated within the 0.4.0 rebaseline effort as seen in PR #714 , so this task should be able to be closed once that PR has been merged.

[lizzcondrey]

714 was completed and merged in, the requests outlined above were all met in that new baseline effort. Closing this request.