xml-dev - RE: Procedural vs Declarative XML transformation approaches

[Gavin Thomas Nicol <gtn@ebt.com>]

> Maybe I have been barking up the wrong tree to assume 
> that XSLT is a "declarative" and that the declarative/procedural
> debate in related disciplines sheds much light on the question of 
> what we can do to to make XML transformation easier for our users. 
> Just as few end users care much whether their authoring tool 
> produces Postscript or PDF, perhaps XML end-users will soon not 
> care much whether their transformation tools work with DOM+script, 
> XSLScript or XPathScript, or good ol'  XSLT under the hood, so 
> long as there is a reasonable UI and the technology is reasonably 
> vendor-neutral and portable.

I think it depends on what you're trying to accomplish... I think
a good example of the tradeoffs in language design is JavaScript.

For stuff like onSelect handling, forms submission etc. the code
is very simple and easily analysed. However, the language is such
that you cannot build an editor that does much beyond treating
the code as a black box, and offer a preview mode, because 
complete static analysis of arbitrary JavaScript is impossible.

XSLT is better than JavaScript, but stylesheets can easily become
complicated enough that static analysis is prohibitive at best.
Given the fact that it's turing complete...

FWIW. I think carefully designed declarative systems can be
tremendously valuable in managing complexity, but are only
applicable in well-defined areas. Typically, you have to augment
them with some "escape" hatches...