[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Procedural vs Declarative XML transformation approaches
> 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...
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|