Description:
------------
I would really like an additional argument to the expand() method (which I do like). I think the biggest problem will be that the result should become some kind of semimanufactured DOM tree. Using the expand() method I'll get the complete tree (which can be huge on higher depth levels). Minimizing it to a number of levels would really limit the mem.footprint it'll create.

For example, I have a huge XML document with all sorts if nested resources. Using XMLReader i'll find the first on (city). I'd like to expand it, but not all the streets it has inside. I'd like to limit the depthOffset to 1 (only the direct childs). Because it can skip a lot of parsing, it'll minimize processing costs and will consume less mem. 

Now I'd like to parse the streets. I decide to destruct my DOM-tree to save mem, and continue searching for streets in my 'city' using XMLReader. At last, I found one. I'd expand() it, but not all the way (I still don't want to know the details of all the houses, actually, I never want it). I limit my expanding to the depthOffset 1 or maybe 2 (if house are nested in another layer of elements). When I finished handling my street, I can destruct the DOM-tree and go XMLRead the next one.


How bigger (and nested) the input is, the more memory I'll save limiting the expand. Other options for the expand could be helpfull either (first 5 childs etc.) but it shouldn't become too fullfeatured because it probably bring down performance.


Is it possible to add some sort of 'depthOffset' argument/config-setting to the expand()-method? 

Test script:
---------------
500MB of heavily nested XML-data.

Expected result:
----------------
Only mem. footprint for what I'd actually use the expand() for.

Actual result:
--------------
Huge processing/mem. footprint for everything that's inside of the current node (parsed to DOM).