From: Adam Retter <adam.retter@de...> - 2005-12-20 19:34:53
If I have a query with the following predicate which makes sure a node
called pending inside a node called validation does not exist -
That works fine, from the eXist function declaration I can see that
not() returns a type xs:boolean. However if I change my predicate to -
[not(validation/pending) eq false()] or [not(validation/pending) eq
true()] then I get an error that eXist cannot convert from type
xs:string to xs:boolean...
Im guessing this is a bug? is it known?
Adam Retter wrote:
Here, your are "not-ing" a path expression :
A path expression is supposed to return a *node* sequence.
Quoting http://www.w3.org/TR/xpath-functions/#func-not returns, fn:not()
> Summary: $arg is first reduced to an effective boolean value by applying the fn:boolean() function. Returns true if the effective boolean value is false, and false if the effective boolean value is true.
The important concept is the " Effective Boolean Value"
So, suppose you have an empty sequence :
> If its operand is an empty sequence, fn:boolean returns false.
not will then return "true". This is the "predicate truth value"
> Otherwise, the predicate truth value is the effective boolean value of the predicate expression.
Now, suppose you have a node sequence :
> If its operand is a sequence whose first item is a node, fn:boolean returns true.
So not() returns false, which is your predicate truth value.
From here, everybody knows ;-)
> That works fine, from the eXist function declaration I can see that
> not() returns a type xs:boolean. However if I change my predicate to -
> [not(validation/pending) eq false()] or [not(validation/pending) eq
> true()] then I get an error that eXist cannot convert from type
> xs:string to xs:boolean...
Here, your are using a general comparison
... for which a preliminary process is applied :
> Atomization is applied to each operand. After atomization, each operand is a sequence of atomic values.
Then, the magnitude relationship is determined.
> If a cast operation called for by these rules is not successful, a dynamic error is raised. [err:FORG0001]
That is certainly what is happening (read your error message carefully).
Should you enforce type casting :
[fn:boolean(validation/pending) eq true()]
... you could have a result provided that the effective boolean value
computation is possible.
In conclusion : although these expressions look similar, they are not.
The first one is a path expression that deals with nodes (and should be
handled very quickly by eXist) whereas the second one is a general
comparisaon taht deals with atomic values.
I will, however add a reminder to the specs in the error messages.