It depends on what the semantics of fn:count() are, i.e., is is supposed to do
the type checks that TreatIterator::nextImpl() does? If the point of the count
optimization is not to materialize the objects, then you (obviously) can't do
type checks. But is that legal?
However, I think (correct me if I'm wrong) that the presence of fn:count()
wrapped around an expression changes what the expected type is (to xs:integer)
and it also makes the quantization checks irrelevant since fn:count() works on
any length sequence.
If that's true, then TreatIterator::count() would simply call its child's count
without any other checks. I think the same would be true for skip().
Your team Zorba Coders is subscribed to branch lp:zorba.
Mailing list: https://launchpad.net/~zorba-coders
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~zorba-coders
More help : https://help.launchpad.net/ListHelp