Michael Kay wrote:

>>More seriously, why don't you return an net.sf.saxon.om.NodeInfo or 
>>SequenceIterator and let the caller make a wrapper if he wants to?
>>    
>>
>
>That's one of the options available (the result is in general a sequence of
>items, each item being an atomic value or node, and the most basic
>representation of this is as a SequenceIterator returning a sequence of Item
>objects, whose subclasses are AtomicValue and NodeInfo).
>
>But if the result of the query is a document and you want to serialize it,
>or deliver it as a stream of SAX events, then there's no need to materialize
>the result document as a tree in memory, so sending the result to a JAXP
>  
>
If the result is not materialized, then the (physical) execution of the 
query is somehow delayed.

Does the use of SequenceIterator imply that the result is materialized 
in memory, excluding delayed execution ?
Couldn't there be an implementation of the interface that just defers 
execution ?

>Result object is a useful alternative. (This is something that XQJ is
>missing at the moment. There may be a reason for this in terms of expected
>usage patterns: whereas with XSLT the result tree is often much bigger than
>the source, people may be expecting XQuery results to be small compared with
>the source.)
>
>  
>
If XML is used in an OO context because more lightweight messaging and 
persistency in distributed systems is desired, my feeling is that 
in-memory is just fine.
For document transformations, I think a JAXP result does not help much 
either - because if I understood it correctly, it can only be used for 
the "last step" - you cannot run queries or transformations.

What you really want is to compose a bunch of queries and 
transformations (like function composition) and *then* run the whole 
thing. This brings us back to composition of queries/xslt stylesheets, 
optimization potential (like "deforestation", the removal of 
intermediary results), and the inadequacy of strings.

Some domains have certainly more potential for query optimization than 
others (e.g. stuff that conforms to a schema) - the user could supply 
optimizers that the XQuery API implementor cannot provide. But with 
strings as queries (and strings as results), this is of course impossible.

cheers,
Burak