Hi Giuseppe,
Is this due to the fact that BaseX tries to convert the values of @n of all
div elements into a number and, if it happens that the @n values returned are all numbers, then an error is not raised (the comparison is then possible), otherwise it is? Is this BaseX specific? Thanks.
Exactly; that’s standard XQuery. You can use an additional predicate to restrict the comparisons to valid integers:
<xml> <div n='a'/> <div n='21'/> <!-- result --> <div n=' 21 '/> <!-- result --> </xml>//div[@n[. castable as xs:integer][. = 21]]
Using string comparisons is usually the easier way, and it’s better supported by our index structures. However, if your numeric data is irregular and has additional whitespaces (such as in the third <div> element in my example), string comparisons may be too strict.
A side note: I was surprised to see that Saxon EE 10 raises an exception for my example query. It seems that the predicates are swapped, and the comparison is evaluated before the cast check. Maybe the behavior has been adapted in a more recent version. – A workaround is to use the and expression:
<x>a</x>[. castable as xs:integer and . = 21]
In BaseX, a predicate with an and expression will automatically be rewritten to multiple predicates, as simple predicates can be further optimized more easily, and predicates will always be evaluated in the order they are written down.
Ciao, Christian