Claudio,
At 09:19 AM 7/4/2003, you wrote:
I agree with you, which comes back to my first expression. Why don't keep
XSLT for what it was created, presentation purposes (as Michael recalled
from the w3c sentence), and leave the process in the server level with
more specific elementary process programming under C, Java, Assy, compiled
language, giving the necessary XML view for the XSLT.
Because notwithstanding the ostensible purpose of its designers (as
indicated in the sentence Mike cited), XSLT turns out to be *really good*
at lots of middleware types of operations. "Middleware" too benefits from
being specified declaratively, and so often the same people are designing
the back-office processes as are designing the targetting of presentations
(indeed, as has been pointed out they can often be seen as species of one
another -- a process targetting an interface), that it makes sense to unify
on a single technology to do both, if it happens to be suited to the task(s).
Understanding the "intent" of the design of XSLT is really helpful to
understand why and how it has particular limitations ... but ultimately we
are limited by the technology's intrinsic capabilities, aren't we, not the
intentions of its designers? (The good designers know that.)
Cheers,
Wendell
___&&__&_&___&_&__&&&__&_&__&__&&____&&_&___&__&_&&_____&__&__&&_____&_&&_
"Thus I make my own use of the telegraph, without consulting
the directors, like the sparrows, which I perceive use it
extensively for a perch." -- Thoreau
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list