-----------
In general, XML technology is not geared to big documents. It is more oriented to small result sets.
----------

This is incorrect.

I think what you mean to say is that in general DOM-oriented XML parsing is not geared to big documents Although this isn't strictly true, it's nearer the truth than what you said.

The reason it isn't strictly true even to say that the DOM isn't capable of handling large documents is simple: nothing requires an XML engine to put the tree entirely in memory <g> !

Think of it this way: VFP handles cursors and edits large documents very flexibly, transparently moving things between memory and disk. It's possible to write a DOM engine that works the same way. People are doing this, it's just a relatively new phenomenon.

But leaving DOM aside entirely....

Folks here might want to think about using SAX parsers rather than DOM-style parsing when it comes time to dealing with really big XML documents (100s of megabytes in size or more). It's a completely different API.

Because SAX just fires off events as a stream is processed, you don't have the same issue of a model of the document in memory.

SAX and the new MS XMLReader API are both forward-only processes, and it is true that the DOM lets you navigate a tree in a more flexible manner. But please don't make the mistake that the DOM is the only way of handling XML or that the DOM "is" XML.

FWIW, if you do much XSLT you find out that it hardly matters how the XML is being traversed, you're not even supposed to think about which method the processor uses. If you did, you'd make the mistake of thinking you knew what order the nodes would be processed in. Accordingly, you're not supposed to think about whether the XSLT processor is DOm- or SAX- based.

>L<