Re: [xsl] XQuery basics

[Robert Koberg <rob@xxxxxxxxxx>]

On Wed, 2008-06-04 at 13:13 -0400, Wendell Piez wrote:
> At 12:59 PM 6/4/2008, Andrew wrote:
> >I reckon a future architecture is going to be standalone transforms
> >calling XQuery to get input - if a standard name for the initial
> >template can be settled on (for example "main") then you could point
> >your browser at whatever.xslt and the transform can be executed server
> >side fetching input from a variety of sources and constructing the
> >page, both languages working to their strengths.

I don't understand. What would be the benefit of pointing to an XSL with
nothing telling it what to do? I mean, how would XSL even know what the
request was for without something driving it? And if you have something
driving it, you have what we have now. What am I missing?

> >
> >Pretty much exactly how eXist works now with XQuery, but using a
> >standalone transform as the entry point.  I've mentioned it to
> >Wolfgang so hopefully a future version might support it...
> 
> Andrew, you must be right, since I've had the same thought myself.
> 
> For document processing alone, work on the transform layer. For 
> high-performance aggregation, filtering and sorting, get a boost by 
> working on the query layer.


If you use a small main Source XML with the minimum necessary
instructions for a transform, then you can bring in the bulk the
required XML through the document function (maybe with a URIResolver
that uses XQuery, but...)
o;?
Don't the XML databases work best with many small documents rather than
one or a few very large documents?

If that is the case (which I believe it to be), I wonder if using the
file system would give better performance and less memory usage for this
scenario. Wouldn't the XML DB need to make some kind of DOM (as
optimized as possible, hopefully). Then you feed it into a transform
which needs to make its own DOMish thing. If you use the file system you
can supply a stream to the transform and build one DOMish thing.

best,
-Rob