[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: an XQuery API for Java

• To: "'Burak Emir'" <Burak.Emir@e...>
• Subject: RE: an XQuery API for Java
• From: "Michael Kay" <michael.h.kay@n...>
• Date: Mon, 5 Jul 2004 17:32:40 +0100
• Cc: <xml-dev@l...>
• In-reply-to: <40E96C98.4060606@e...>
• Thread-index: AcRioJUpUIdfNJkLQhO+Ow53fcVF1wADDOuQ

> Why don't you just return a string - I have been told it has very 
> pragmatic benefits ;->

It's very easy for users to construct strings, it's much harder to parse
them.

> 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
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.)

Michael Kay

• Follow-Ups:
  • Re: an XQuery API for Java
    • From: Burak Emir <Burak.Emir@e...>

• References:
  • an XQuery API for Java
    • From: Burak Emir <Burak.Emir@e...>

• Prev by Date: an XQuery API for Java
• Next by Date: Re: an XQuery API for Java
• Previous by thread: an XQuery API for Java
• Next by thread: Re: an XQuery API for Java
• Index(es):
  • Date
  • Thread