RE: XQuery

a)       SQL is also indeterminstic (non-deterministic is probably the
correct English word, no?) as are other database query languages for the
reasons Michael explains below.

b)       Actually the reason why we removed three-valued logic was that
all predicates in XQuery and XPath are existentially quantified which
always maps the third truth-value to false. The only expression that
thus would preserve the third-value was an expression of the form $a eq
3 (if $a is ()) that is not part of a predicate. We considered this to
be a very small use case...

 

Best regards

Michael

 

________________________________

From: Kay, Michael [mailto:Michael.Kay@softwareag.com] 
Sent: Thursday, October 16, 2003 4:36 AM
To: Guido Moerkotte; Michael Brundage; 'Kay, Michael';
public-qt-comments@w3.org
Cc: Michael Rys; moer@pi3.informatik.uni-mannheim.de
Subject: RE: XQuery

 

> 
>   After writing this, I really look forward to your arguments 
>   a) in favor of Indeterminism 

I think all database query languages have to allow the implementation to
choose efficient access paths, and different access paths might or might
not hit errors. Therefore, I don't think there's any practical
alternative to saying that dynamic errors will depend to some extent on
the implementation. Note that database query languages have much more
stringent requirements here than conventional programming languages,
because optimizations (eg. of joins) give performance improvements of a
factor of 1000000, not just a factor of 2.

The adverse effects of indeterminism can be reduced if you reduce the
number of run-time errors, though this has to be balanced against the
desirability of reporting genuine programmer errors rather than giving
wrong answers. In some cases, like this one, I think we are reporting
errors that would be better treated as not being errors; and it would be
perfectly feasible to define the rules so that comparing an untyped
value against a typed value testing castability to the required type
before attempting the conversion.  

  
>   b) against NULL and three-valued logic. 
> 
Firstly, the XPath model doesn't need a NULL value that is separate from
(); in all cases where a null might be useful, a () will serve just as
well. We did at one stage have a three valued logic with the three
values being true, false, and (), and this works perfectly well.

The big problem with this 3-valued logic was its interaction with the
existential nature of the "=" operator. In SQL, a=3 returns null if a is
null. In XML, nodes can have multiple children, e.g. a book can have
more than one author, so in XPath author="Kay" was defined with
existential semantics: it's true if any author satisfies the condition.
This naturally means that if one side is (), the answer is false. Trying
to define the answer as () led to all sorts of inconsistencies.

Regards, 

Michael Kay