[data-shapes] Definition of sh:conforms / handling of non-violating validation results (#453)

bergos has just created a new issue for https://github.com/w3c/data-shapes:

== Definition of sh:conforms / handling of non-violating validation results ==
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.


Please view or discuss this issue at https://github.com/w3c/data-shapes/issues/453 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 29 July 2025 19:17:08 UTC