I think the communty which is asking for this is, in fact, interested only in trivial transformations -- filtering and minor renaming or processing or annotating, no look-ahead or look-back and only a small amount of context carried forward -- the kind of thing that they could write as a trivial SAX application but would prefer not to. They'd like a high-level language to express these operations in, and I think we'd like that language to be closely related to XSLT/XPath/XML Query rather than having everyone reinvent the wheel and relearn how to use it.
Yes, it's a niche application, but may be one that's worth addressing. Some applications of XML Query would fit into this model -- eg extracting selected records from a customer history file. Also see the recent question in this mailing list about processing a huge file to simply rename the root element and filter out fields not currently of interest. An alternative would be to retain full XSLT, but make our processors _MUCH_ smarter about pruning the incoming data. However. I do suspect that a subset processor could be made to run smaller and faster, for those cases where the subset is sufficient. The hard part is defining what the subset should be -- figuring out exactly how the niche is defined, then resisting every attempt to add "just one more harmless little feature".
