-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reference spec when reporting violations #16
Comments
@wking This is a good idea but maybe hard to maintain the links all the time. How about we target this for 1.0? |
On Mon, Jan 25, 2016 at 10:19:31AM -0800, Mrunal Patel wrote:
There aren't that many releases left between now and 1.0, so I'd just |
On Mon, Jan 25, 2016 at 10:19:31AM -0800, Mrunal Patel wrote:
We're into 1.0.0-rc1, so I'd guess it's time to do this? I can start |
With #354 merged yesterday, we now have a way to do this. We still need to transition a lot of code to the new error model, but it's no longer blocking on designing the approach. |
Validators (e.g. the Nu Html Checker) often report errors with references to the specification requirement that was violated. To get a good user experience and protect against checking unspecified behavior, I think ocitools checks should be setup to link to the relevant spec wording for any check they perform. For example, a bundle with non-UTF-8 JSON would fail with a reference to this. If this sounds like a reasonable policy, we should write it up in the README or a CONTRIBUTING.md and open issues/PRs for adjusting any existing checks.
The text was updated successfully, but these errors were encountered: