Re: My favourite XSLT enhancement requests

[Alexey Gokhberg <alexei@xxxxxxxxxx>]

Dear friends,

The problem is that XSLT is *not* a general purpose programming
language. Apparently, it was designed to perform the very specialized
set of tasks. This is why many simplest operations available in most
programming languages are so difficult or even impossible to implement
in XSLT. 

Just consider the XSL-List postings of yesterday (13-Sep):

- How to write the "formfeed" (hex. x0C) character to the output stream?
(By the way, was the satisfactory solution finally found?)

- How to replace all occurences of certain characters (e.g., ':', '.',
etc.) in XML character data by the certain 2-character sequences (e.g.,
'\:', '\.') etc.? To do this in the pure XSLT, you need an awful
stylesheet (and a skillful XSLT programmer, and what about
performance?). This is, however, the simplest task even in the language
like C, to let alone languages that support regular expressions.

Indeed, with XSLT we can observe an interesting phenomenon: the language
was originally designed to avoid the hardcore programming and to speed
up implementation of XML transformation algorithms, but in reality even
the simplest operations require so much efforts when being programmed in
XSLT.

There are many proposals for additional features that would convert XSLT
to the complete (and let's be honest, the *procedural* rather than
*declarative*) programming language. However, inventing a successful
programming language is an extremely difficult task, that requires some
luck, a lot of resources (and recently, muscles of some prominent
CORPORATION behind). It is not very likely that this really could be
done with XSLT.

So, is there any solution? I think, yes.

There exist procedural scripting languages that are already well
designed, are easy to learn and that provide all necessary functionality
lacking in XSLT. The obvious candidate is JavaScript (ECMAScript, if you
like). Why not to combine power of XSLT and some of these languages,
using them together and calling procedural scripts from XSLT (or vice
versa)? XSLT specification provides the adequate mechanism for this -
extensions. Of course, currently there is no standard mechanism for
communication between XSLT stylesheets and scripts, but, since we talk
about future development why not to concentrate efforts on the
specification of such mechanism rather than on the creation of the
particular additional XSLT features?

Following is one possible way to test the idea:

I possess the program which I call "Unicorn XSLT Processor, Professional
Edition". It includes XSLT processor, ECMAScript interpreter and already
implements the concept described above. Furthermore, mechanisms are
available to access ActiveX (COM) components and SDK to write plug-in
DLL in C/C++.

I can make this program publically available. You can try it yourself to
check whether the idea works. I can provide some support and implement
reasonable requests for improvements.


Thank you for your attention,

Alexey


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list