[phkahler]

>> Emit X when you encounter P except if the third element of type Z (if it exists) of the grandparent of P is a Q with attribute TUESDAY having value FIZBIN emit Q's content transformed according to rule Y" is never going to be pretty

And that is the logic that does not belong in the view. You've failed at properly separating the M,V, and C.

[empthought]

It's a reporting engine. There's nothing else besides the "view," and as it is a reporting engine, the view is complex.

[phkahler]

>> It's a reporting engine. There's nothing else besides the "view," and as it is a reporting engine, the view is complex.

The database query is complex. The presentation of data should not be. Mixing these together is a design failure to a lot of people. TFA even mentions this, if you subsequently need to generate a .pdf you're going to embed a redundant copy of the logic in that display code too. If you get the logic down at the lower level where it can be shared, then you can have as many views as need be without duplicating logic that doesn't belong there anyway.

[empthought]

Nothing about "Emit X when you encounter P except if the third element of type Z (if it exists) of the grandparent of P is a Q with attribute TUESDAY having value FIZBIN emit Q's content transformed according to rule Y" has anything to do with a particular presentation of the data.

What one does is transform different input sources (using XSLT) into a common XML data format, applying stupid rules like the above. Then one applies another transform from the common data format (again using XSLT) to something like HTML, or XSL-FO, or CSV.

"Separation of presentation and query" is really orthogonal to both the use of XSLT and the inevitability of needing to apply complex rules when processing real-world data. XSLT and XPath just happen to be better at expressing those transformations than most other languages, and they certainly have the largest installed base.