Suggested redesign of Operations section

In the current draft, section 10 defines several entry points that SHACL 
systems should be able to handle - operations to validate a given graph 
or a given node. I have so far used pseudo-code that is ambiguous, hard 
to test and hard to understand.

I am suggesting to use a Reference Implementation using real, executable 
Java code instead of pseudo-code. I have attached the current design of 
the main class of that API that does the control logic (just excluding 
SPARQL execution). The spec would include key snippets such as the 
following, together with documenting prose:


     void validateGraph(String minSeverity) {
         for(Node shape : getAllInstances(iri(SH.Shape), shapesGraph)) {
             validateShape(shape, minSeverity);
         }
     }

     void validateShape(Node shape, String minSeverity) {
         for(Node focusNode : getNodesInScopeOfShape(shape)) {
             validateNodeAgainstShape(focusNode, shape, minSeverity);
         }
     }

     boolean validateNodeAgainstShape(Node focusNode, Node shape, String 
minSeverity) {
         boolean hasResults = false;
         if(isNodeValidForFilterShapes(focusNode, shape)) {
             for(Node constraint : getConstraintsOfShape(shape)) {
                 if(hasMinSeverity(constraint, shape, minSeverity)) {
                     if(isNodeValidForFilterShapes(focusNode, constraint)) {
                         hasResults |= 
validateNodeAgainstConstraint(focusNode, constraint, shape);
                     }
                 }
             }
         }
         return hasResults;
     }

This API is actually executable but is implemented against a very simple 
platform-neutral API with interfaces Node, Triple, Graph and Dataset. As 
a proof-of-concept, I have implemented those interfaces against Jena and 
now have a new engine implementation that passes all test cases. A port 
to other libraries such as Sesame or even other languages like 
JavaScript should be trivial. Note that the API has been designed for 
conceptual clarity instead of performance.

My proposal is to rewrite section 10 based on this redesign.

Thanks,
Holger