xml-dev - Re: Doing it the other way around (Re: transformations)

[Alexey Gokhberg <alexei@bluewin.ch>]

Richard Lanyon wrote:
> 
> ... surely there should be a nicer way to do
> things than a hybrid of several different programming languages. A
> "pure" XSLT problem really shouldn't require a chimera
> XSLT/ECMAScript/extension solution.
> 

There is nothing unusual in combining several programming languages
together. The common example (already cited in this thread) is SQL. The
SQL technology could not be really useful without the call level
interface, on one hand, and the mechanism of stored procedures, on
another hand. The typical RDBMS application could mix code written in
C++, SQL and any vendor-specific language for stored procedures (PL/SQL,
T-SQL, etc.). The fact that code blocks written in different languages
may reside in different source modules does not change anything - these
blocks still act as parts of the same application. You can call it
"chimera", but this is the way the entire RDBMS world goes - why XML
world should be much different?

Furthermore, using a scripting language to build applications from the
pre-existing blocks is a very common (I would say, classical) and
fruitful concept. Many leading software technologies use it (just
consider Microsoft which combines scripting and ActiveX components).

The fact is, that there are (almost) no pure transformation tasks in the
real world. In most cases XML transformation proper is combined with
some other form of data processing. XML transformation can, in
particular, involve non-XML data (e.g., stored in RDBMS) or access the
external interfaces (e.g., when XML is used to facilitate some sort of
RPC - as in SOAP). The natural solution is to select an appropriate
programming language to code each module, then to use some (e.g.,
scripting) platform to integrate modules.

Regards,

Alexey