XSLT does not mandate the implementation, but pratically XSLT processors build the whole tree in memory. In any case, if you want to be able to use arbitrary XPath expressions on a document, you pretty much need to have it all in memory.

It would be theoretically possible to build really smart XSLT engines that would look at the code and do some clever optimization to only build parts of the tree, but I am not aware of any one that actually does this.

Directly as a DOM tree or something less prosaic like a collection of SAX events or an infoset?

Whilst it is far from an ideal example XML::XSLT uses an XML::DOM object underneath. In processing XSLT it is often necessary to access nodes in a random order and having the whole parsed tree in memory makes this easier.

/J\

Whatever format the XSLT processor uses it is still a full tree, no necessarily exactly a DOM tree, but necessarily something conceptually equivalent.