A simpler proposal for reporting SHACL results - ISSUE-51

Here is a proposal for handling SHACL errors and validation results.


An invocation of a SHACL processor is an attempt to perform zero or more
validation tasks.

Errors:

A SHACL processor can encounter errors in trying to perform these tasks,
such as
- communications problems, e.g., the inability to access a required document
  or service;
- incorrect syntax, e.g., a syntactically malformed SHACL construct;
- incorrect control information, e.g., trying to start validation using a
  node that is not in the data; and
- resource exhaustion, e.g., exceeding allowable processing time.
When an error is detected the SHACL processor MUST signal the error, using
means different from reporting violations, and MAY terminate its work at
that point.  The processor MAY report on the violations that it had
discovered before it encountered the error.

Violations:

The execution of a validation task results in a number of violations.  If
there are no violations then the task is a success, otherwise it is a
failure.  Each violation is reported in a simple minimal form that is
suitable for futher processing.  There are are no sub-types of violations
such as warning violations or error violations.  There are no severity
levels for violations.

The execution of zero or more validation tasks is performed by executing
each of the tasks in some unspecified order.

Discussion:

Fine-grained control and reporting can be done by using separate invocations.
If some violations are errors and some are only warnings, they can be run
in separate invocations and processed differently by whatever calls the
SHACL processor.  If there are multiple severity levels for errors, then
each severity level can be run in a separate invocation.  If there are
multiple validation tasks that each need to have violations handled
differently, then each can be run in a separate invocation.




Peter F. Patel-Schneider
Nuance Communications

Received on Tuesday, 4 August 2015 16:55:08 UTC