OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: Procedural vs Declarative XML transformation approaches

[ Lists Home | Date Index | Thread Index ]
  • From: Gavin Thomas Nicol <gtn@ebt.com>
  • To: xml-dev@lists.xml.org
  • Date: Sun, 05 Nov 2000 11:10:30 -0500

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS