You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As already discussed in #270 , I think there should be functionality to make a distinction between an ERROR (e.g. breaking a build) and a WARNING (something that should be changed in metadata, not blocking problem).
I would add a key errorLevel, with levels "error", "warning", "deprecated" and add this to the validation errors.
The text was updated successfully, but these errors were encountered:
Hi, thanks for bringing this back up. It's been a while and revisiting old topics is often useful.
I'm actually the primary member leading the effort for the specified output formats. You can follow the output label to see relevant issues.
I think my stance as stated in that issue remains unchanged. Essentially, feel that "error level" is an application-level concern. Different applications will have different priorities for the errors, and it's their responsibility to interpret what a validation returns.
Also, with the output format that is now specified, applications have much more information available to make that determination than they did when that issue was active.
I don't think the specification has the purview to determine for everyone which errors can be considered warnings or critical. We just report that something didn't match what was expected and leave interpretation to the consumer.
As already discussed in #270 , I think there should be functionality to make a distinction between an ERROR (e.g. breaking a build) and a WARNING (something that should be changed in metadata, not blocking problem).
I would add a key errorLevel, with levels "error", "warning", "deprecated" and add this to the validation errors.
The text was updated successfully, but these errors were encountered: