ISSUE-76: Can errors be treated as false?

Peter, as far as I understood it, your proposal in the recent meeting 
was to treat (recursion) errors to mean "false". For example if a Shape 
would be defined as A OR B and A leads to infinite recursion while B 
evaluates to true then the overall Shape would still be true. Likewise, 
if S = A AND B and A leads to an infinite loop then the overall result 
will always be false, regardless of B.

I have not made up my mind yet whether this interpretation makes sense. 
My understanding was that infinite recursion (or any other fatal error) 
means "I don't know"/"unknown", and that these fatal errors are always 
propagated up to the outside caller(s) to make sure that the user gets a 
meaningful error message. Your suggested interpretation basically says 
that infinite recursion means "false", and errors would not be 
propagated up.

Are we sure this interpretation is desirable and well-defined? I have no 
strong opinion (others in the WG have thought more about recursion than 
I have) but I guess we should then apply the same changes to 
sh:valueShape, XOR and NOT.

If nobody sees problems, then I'd appreciate a proposal so that we can 
move on. But as long as there are doubts that this alternative is 
well-defined, I'd prefer to play it safe and continue with the current 


PS: Arthur asked about why an rdf:List is used instead of direct 
properties. Whatever we decide about the execution order, I still 
believe we need an rdf:List so that tools can display consistent 
expressions - if they are unordered triples, there is no way to have 
users enter "A OR B" and then always get "A OR B" in the display back. 
An alternative design would be to limit AND and OR to two operands, 
sh:left and sh:right, but that sounds rather ugly.

Received on Monday, 3 August 2015 04:13:52 UTC