We extended the specification to allow giving a parameter to the engine to change the severity level when a result is a violation. Now there are violating and non-violating results. Only the violating result will change the sh:conforms to false.

That led to two follow-up issues:

1. The validation report doesn't contain enough information to explain which severity level had an impact on the sh:conforms value.
2. There is now the severity level sh:Violation and violation as an attribute for severity levels, which can be set with a parameter to the engine. Before, the specification defined sh:Info and sh:Warning already as violations. That was confusing, but consistent in that way, that all results have been violations. Now that's no longer the case.

Ideally, we find a way to extend the validation report data structure to contain enough information to be able to reproduce the result of sh:conforms, and the same definition avoids the problem of dealing with the violation attribute.

There have been multiple proposals:

• A property sh:conformanceDisallows could be added with a list of severity levels, which will change the sh:conforms to false if a result of that level shows up. e.g.: [] sh:conformanceDisallows (sh:Violation sh:Warning) .
• sh:order could be attached to the levels, and a threshold could be written to the report where every level above that threshold has an impact on sh:conforms.
• Results without impact on sh:conforms could be added with a different property sh:informativeResult. The existing definition that any result attached with sh:result leads to a sh:conforms equals false could be kept.

In our last weekly call, it was already mentioned that the solution with sh:order could cause problems if the level is changed afterwards. That could be a change of sh:order but also deprecating the level.

The last solution, using the property sh:informativeResult, would be the one with the smallest impact, but I tend towards the first solution. The sh:conformanceDisallows property, just for the severity levels, would give us the option to add other properties to group the results based on other attributes. That could be again the severity level, but selected for a different use case, like what should be shown in the UI. With the sh:informativeResult, we would be somehow settled on how results will be grouped.