[tjradcliffe]

Having seen ideas come and go, I think it's more that the problem XSLT sets out to solve--generic tree transformation from XML to anything more-or-less well-formed, with special casing for HTML--is difficult to represent in a clean and sensible way. DSSSL [#] failed. DSSL-O failed. XSLT almost failed.

I use XSLT as part of a reporting engine that generates HTML from fairly complex XML documents on the back end, and whenever I touch it I'm amazed by a) how powerful it is and b) how painful it is to use.

It isn't clear that it's possible to get similar power without similar pain, though, and I think it's beholden on anyone who claims it is to step us and give us an example. A lot of really smart people were involved in DSSSSL and XSLT, and they couldn't solve the problem. Even stripped of the awkward, ugly, syntax, the kind of thing you want to specify in XSLT is complicated and messy.

"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 while you can argue that only badly designed document formats require things like "the third element" to be specified, the world we actually live in is full of such things. And because we will always re-purpose document formats to ends their designers never envisaged, it will always be the case.

[#] I can't actually remember how many S's DS*L has in it, although I once did know most of the words to the DSSSL Song.

[jbn]

it's 3 S. "DSSSL" is right.

[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.