Saxon

Possibly related:

let $v := xs:date('2001-01-01')
return switch($v)
  case $v return 1
  default return 2

This query raises the error »Dynamic context missing: Unknown implicit timezone«.

Thanks for reporting it. Looking first at the QName case:

I have made this into QT3 test case switch-014 (yes, the test number gives a clue that the test coverage for this new feature is somewhat minimal...)

The switch expression compiles internally into a construct that uses an EquivalenceExpression, presumably on the basis that the comparison semantics for switch are sufficiently different from other comparison expressions. The EquivalenceExpression in turn is making use of an AtomicSortComparer, but this is designed primarily to do ordering comparisons and it is failing on values that do not support ordered comparison. Specifically, it fails because it calls getXPathComparable() on each of the operands, and getXPathComparable() on an xs:QName returns null, and if either comparison key is null the comparison is deemed to return false.

It seems the EquivalenceExpression is used only for this purpose. It's not immediately clear why we need it. The semantics of the switch expression are described in terms of a call on deep-equal(). I tried generating a deep-equal() call in place of the EquivalenceExpression, with appropriate addition of Atomizers and CardinalityCheckers, and I get one test failure: switch-902. This appears to be because deep-equal is returning a false() result before the cardinality check activates. However, closer examination reveals why it wasn't implemented this way: an EquivalenceExpression makes the code eligible for optimization to use a hash lookup when the keys are constants.

It seems incorrect that the EquivalenceComparer should inherit from AtomicSortComparer. What deep-equal() does is to use a GenericAtomicComparer, but customised with NaN=NaN semantics. It would be good to allocate a more specific comparer if the types are known statically.