Closed pfps closed 7 years ago
The shacl-shacl.ttl graph does not claim to test all possible errors.
It is too late for such a "should" change. We had discussed this topic many times and did not come up with a better compromise than what we currently have.
It is not too late for changes.
I do not recall any discussion of what SHACL implementations that do not handle recursive shapes should do in the presence of recursive shapes.
There was a lengthy discussion that produced the decision reflected in the specification - to leave this to implementations. The spec says "The validation with recursive shapes is not defined in SHACL and is left to SHACL processor implementations. For example, SHACL processors may support recursion scenarios or produce a failure when they detect recursion."
Defining specific dialects of SHACL (subsets of recursive shapes) where recursion is well-defined is on the postponed features list.
So this is left as a source of silent interoperability problems.
The shapes graph that is supposed to check for syntactic validity of shapes graphs does not include any check for recursive shapes. As the behaviour of recursive shapes is undefined in SHACL this produces a significant interoperability problem.
It should be a requirement that a SHACL implementation that does not support recursive shapes must signal an error if it is given a shapes graph with a recursive shape in it.