The important thing to remember about XSLT is that it is a declarative language, not an iterative one. In other words, when you create an XSLT stylesheet, you're not specifying a list of things you want to happen in a specific order - instead, you're defining how you want the result to look. Many programmers (especially the scripting types) are trying to use XSLT as a replacement for iterative langages, and getting frustrated when they can't get the results they want easily.
Personally, I use XSLT for simple presentation tasks - that's it. If I need to do pivots, aggregation, or anything else that's relatively complex, I write a little bit of code in an iterative language to take care of it for me. Yes, I lose some platform portability, but on the flip side the code I create isn't completely inscrutable.
Say what you will about Microsoft - and many of you have - but they really got it right with their XmlReader class in.NET. It streams the document like SAX (the "callback" interface Tim mentions in his comments), but allows the programmer to cursor over the document manually rather than having to handle everything in thrown event handlers (which I agree can be a real headache, especially in highly variable or deeply nested documents.)
XML is just one of the tools in our collective toolbox. Use it where it helps you solve a problem. Don't bother if it doesn't.
Personally, I use XSLT for simple presentation tasks - that's it. If I need to do pivots, aggregation, or anything else that's relatively complex, I write a little bit of code in an iterative language to take care of it for me. Yes, I lose some platform portability, but on the flip side the code I create isn't completely inscrutable.
XML is just one of the tools in our collective toolbox. Use it where it helps you solve a problem. Don't bother if it doesn't.