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