Support error "level"

[adourish]

We often need to distinguish the types of errors that are generated. Some errors are not serious. Adding an error level would be very helpful.

"level" = ["critical","error", "warning","success";

e.g. Prevent large amounts of data from getting stored into a repository. This feature would add some complexity to the result object.

schema:
{
"type": "string",
"level": "critical",
"maxLength": 50000
}

[epoberezkin]

I don't think it is in the scope of the specification. It is related to a wider issue of error reporting, which is not covered here.

[handrews]

@adourish Are you talking about schema validation errors, errors in HTML forms, API request errors, or all of the above? For more discussion see #148 which is a similar request. I mostly agree with @epoberezkin but think that if we do a JSON UI Schema per #67 that this sort of thing could go there.

[adourish]

• It is related to error reporting.
• It is not limited to UI.
  -- HTML forms
  -- Api calls
  -- Android app data validation
• The "messages" property would help cover this use case
• I still think that a "level" or "group" property is needed to differentiate the severity of an invalid item.
  JSON.Schema seems to be the perfect way to unit all the ways that you might need to validate data.

[dret]

as one data point: for reporting API problems, https://tools.ietf.org/html/rfc7807 might be interesting to look at.

[handrews]

See also #396

[awwright]

I think this suggestion is for a more general purpose ability to specify different courses of corrective action for different assertions. Here, type: "string" might be "critical", but another assertion maxLength: 5000 might be "error".

To this extent, this seems rather similar to e.g. providing localized error messages. I think we can close this out as a duplicate of that concern. I think #148 covers this. This is essentially a UI related proposal, though.

[handrews]

@awwright Yeah, I think that the non-UI parts of this are covered by some combination of #148 (specific error messages in the schema) and #396 (general standard output and error format).

We could consolidate the "level" concept into #148 as they are closely related.

[philsturgeon]

I'm not sure in what context I'd ever need see a difference between critical. error or a warning. Could you provide a use-case of when and how this would be used?

However it's planning on being used, it seems certain the initial example certainly would not fit. A property is not more or less important than any other, that's the job of required to make it optional or not, right?

Is it not possible for a specific implementation to infer the importance of specific types of error based on the context its running at? With #396 you could, for example, chose to ignore any errors that have the keyword failure reason as "format" if you don't care about format.

[gregsdennis]

I think this is an application-level issue. The people who really care about this are the consumers, and they'll use an implementation that returns errors that can be easily identified by the application. Prioritization is an interpretation of the errors.

That said, perhaps the spec can indicate well-known error codes to be optionally included in the error reporting. This, then, leads us into the realm of #602 where each keyword carries with it certain meta-data which can be incorporated into the meta-schema (or some external document).

[Relequestual]

Maybe this sort of behaviour could exist in a vocabulary which requires that sort of information.

For now, I feel it makes sense to close it. Maybe it could form part of an extended validation and reporting vocabulary, but I feel "validation" is not the right place for this.

#643 should be resolved before further discussion, if any.