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:
Post to     :
Unsubscribe :
More help   :

Reply via email to