----- Original Message -----
From: "Dimitre Novatchev" <dnovatchev(_at_)yahoo(_dot_)com>
"Joshua Allen" <joshuaa(_at_)microsoft(_dot_)com> wrote in message
news:0E36FD96D96FCA4AA8E8F2D199320E52BA807D(_at_)RED-MSG-43(_dot_)redmond(_dot_)corp(_dot_)microsoft(_dot_)com(_dot_)(_dot_)(_dot_)
Well, doing so partially defeats the purpose of using XSLT, since it
means your stylesheets will not work in many other systems. It begs
the
question, if you find that Java is needed, then why use XSL at all?
Why
not just write the app in Java?
If one is already working in an infrastructure supporting
transformations, an extension can take advantage of working with a
parsed object and established (and possibly memory resident) stylesheets
and write just the code required to supply what is wanted.
Portability is not the main issue with using extension functions.
The portability of the message is the significance of XML. The
portability of stylesheets is often a secondary concern. Local
processing of the message is often dependent on local requirements.
In many cases an application is designed to work only within a certain
known
platform/environment (e.g. intranet), which is not going to change.
While *not going to change* is a forceful and often mistaken assumption,
there are obvious examples within a discrete application. Outward
facing stylesheets prefer portability, inward facing ones, such as those
intended to improve data-hiding and encapsulation, usually have a
controlled execution environment.
We need to have a special section in the XSLT FAQ about extension
functions
and why functions with side effects are generally harmful in a
functional
language.
Dimitre, could you refer us to a general discussion or monograph which
illustrates the problems for functional languages, not specific to XSLT.
I understand that the absence of side effects is a design goal for
functional languages. Beyond provability and state reliability, are
there any other challenges? A better understanding of the danger
allows for an improved assessment of risk.
Mike
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list