Re: advocating XML

[Alexey Gokhberg <alexei@bluewin.ch>]

Paul T wrote:
> 
> ... You have used XSLT as a general purpose language. There are some
> people who do that. They do that for fun, I think, because those who
> have real-life  experience in maintaining XSLT systems should know
> that it eventually turns into nightmare. ...
> 
> Now if you map the A.xml into *regex*line*oriented* file, I bet
> you be surprised how *trivial* the overall task becomes if doing
> it in python or perl or any other scripting language that inherits
> from UNIX.
> 
> Not only you'd write this set of converters faster ( because you
> be using a general-purpose language *which xslt is not* ), but
> what you produce will be *correct* , easy to *debug* and *really*
> error-prone.
> 
> .......
> 
> Try to re-do your questionnaire in Python with reasonable design of
> 'line-oriented' .txt file and you may realize that it is *much* faster
> to do the job *this* 'old' way.
> 
> I'm saying this because I've  tried it once. I mean I've solved the same
> task with XML-XSLT based thing and in plain regexpr-scripting way.
> 
> ........
> 
> XML as a 'universal solution' is overhyped. It  *is* good
> ( maybe incredibly good ) as a 'universal import/export (exchange) format',
> but building the 'local' processing flow on XML is a mistake. There is
> no XML tools that provide better help for developer than good old
> UNIX toolbox provides.
> 
> ........
> 
> Let us compare. You do some  routine processing task in
> XML / XSLT - I think I do it 'better'  with
> Perl / Python / regexprs, plain text.
> 

Quite recently, I faced a problem: I had to create Python bindings for a
reasonably big library written in C. This is usually done by writing the
"stub" code in C, which maps Python modules/objects/functions to the
entry points of the C library. The "stub" code has the regular structure
(and therefore can be generated with some sort of templates), but manual
typing of this code is a nigtmare for any reasonably sized C library.

The standard Python distribution provides a simple script written in
Python (2 pages of the source code) plus collection of easy-to-read
templates designed to automate this task. However, to gain some
experience, I decided to do the same using XML/XSLT, representing the
library interface definition in XML, and writing 100% pure XSLT
stylesheet that generates C code from the XML source.

I am quite fluent in XSLT, but even the partial implementation of that
stylesheet took a reasonable time. I stopped it, when I calculated, how
much time will it take to complete the job. The part of stylesheet that
I managed to complete looks terrible in comparison with the templates
used by the original Python script.

Furthermore, the source interface representation in Python (using Python
lists) is more compact and more readable than the equivalent
representation in XML.

Another example. Once I visited one of my customers, talking to him
about advantages of XML/XSLT/XSLFO. He looked impressed, then he asked:
"Well, we have our old banking system, which generates letters to our
customers in the form of plain text. This system will be replaced in the
next two years, but we like to use benefits of the modern technologies
right now. Can we use XML to give the attractive look and feel to our
letters?" 

How to apply XML-enabling technologies to the raw text source data? Yes,
with regular expressions it is possible to analyse the raw text,
converting it to XML. Then XSLT processing, then FO formatting, than
obtaining the PostScript output (PostScript is must for the production
printing). But why do we need XML at all? Why not to generate TeX
directly using just regular expressions?

> 
> PS. I'm not talking about the high-quality printing here. I don't
> know TeX. However, something tells me that Mr. Rantz + TeX
> will always outperform XSLT + XSL FO renderer. ...
>

In the past, I had discussed XSL FO with few TeX specialists. As I
understood, they beleive:

* that by design, XSL FO is lacking some features important for the
real-life high-quality printing

* that the new generation of typesetting systems can be created as the
further development of TeX

* that emulating XSL FO could be just one possible application for the
systems of these new generation

Based on my own experience, I agree with them. (Acquiring funds for such
project is another issue, of course).


Regards

Alexey