|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: advocating XML
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








