LGR files are validated as part of Registry System Testing. This validation is facilitated by a set of tools that are based on a modified version of lgr-core. The modifications expand the focus of lgr-core from manipulation of LGR files to also include validation of LGR files. This PR contains those modifications.
The validation is supported by the following means:
A new concept of test labels is introduced.
Already existing tests are given labels, e.g. "valid_unicode_version" and "metadata_language".
New tests are added and labelled, e.g. tests for the "validity-start" and "validity-end" elements.
Validation results are aggregated in terms of labels.
A policy can be set to determine how a failing test should be reported for each label (ignored, warning or fail).
A method is added to calculate the final validation result in terms of severity levels in the policy.
A new tool is added that generates validation reports. It also serves as a demonstration of the new validation feature.
The goal of the proposal is that it will not affect current applications, i.e. even though the API has been expanded with new feature, current calls will work as before.
Please note that while this PR includes API documentation of (the most important) the new interfaces, it does not include any mention in the high-level documentation of the new validation tool, the validation feature, nor of the test labels.
Edit: Also, this PR contains no unit tests for the new code.
Edit 2: An effort was made to make the changes as new code instead of changing existing code when possible. This should avoid introducing breaking changes and make review easier. On the other hand it introduces some duplication which is less than ideal for other reasons.
LGR files are validated as part of Registry System Testing. This validation is facilitated by a set of tools that are based on a modified version of lgr-core. The modifications expand the focus of lgr-core from manipulation of LGR files to also include validation of LGR files. This PR contains those modifications.
The validation is supported by the following means:
The goal of the proposal is that it will not affect current applications, i.e. even though the API has been expanded with new feature, current calls will work as before.
Please note that while this PR includes API documentation of (the most important) the new interfaces, it does not include any mention in the high-level documentation of the new validation tool, the validation feature, nor of the test labels.
Edit: Also, this PR contains no unit tests for the new code. Edit 2: An effort was made to make the changes as new code instead of changing existing code when possible. This should avoid introducing breaking changes and make review easier. On the other hand it introduces some duplication which is less than ideal for other reasons.