[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: advocating XML
> By using these stylesheets, the form, the database table, the results crib > sheet, and the raw results are automatically kept accurately synchronized. > That would be very arduous and error-prone if you did it by hand. You could > use comma-separed files to hold the descriptions of the form, but they would > be fragile and hard to keep correct as you made changes. They also wouldn't > reflect the section-within-section format of the questionnaire. With xml, it > was almost a no-brainer once I had written the machinery. > > And as a bonus, the system can be used for other questionnaires, too. > > Try doing that with plain html and comma-separated files. xml was MUCH > better. No, it was not. It was worse, and I'd try to explain why. Correct me if I'm wrong, but what you did was : 1. Questionary file : A.xml 2. A2SQL.xslt 3. A2GUI.xslt 4. A2TDML.xslt 5. Some SAX-based python script for something I don't understand. 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. For many reasons. Most of the reasons why XSL programming is harmful, have been explained by Mr. Leventhal 2 years ago (and I admit that at that point of time I was blind enough not to understand what he was talking about.) 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. Anyone who votes XSLT for programming language should take into account that xslt *silently* *ignores* almost any mistyping you have in Xpath expression. And there is no possible guard ( because building the guard kills the XSLT itself ;-) With regular expressions and accurate design of the 'line' you *do* have a guard ! Nested sections? Depends on how deep your sections are. Element ## attributes, separated, by, other, separator ## content Will do just * fine* for Python or perl. You'd have less code to process this stuff comparing even to amount of code you need to use the SAX machinery and when somebody says that : 'there are better layers upon SAX' in Python, I'd say : "No. It is too complex. All you need is 3 lines of regexprs - get real". By the way. If somebody will ask me for the XML file, representing A.txt - guess how long it will take to produce a Python script to serialize my *readable*, *scalable*, *better processable* .txt file into XML ? I think something like 10 minutes for such a script is a fair estimation, right? There is no magic here. Regular expressions, scripting and other stuff is a result of natural evolution of processing tools, started a long time ago by *good*engineers*. Markup languages is a natural evolution of documents, started long time ago by good lawyer. As I said once - I have nothing against lawyers. I think lawyers don't like custom-made home-grown formats. And they are right for some cases. For some tasks ( when A.txt has to be shared, for example ) it is much better to have it XML. But, you know ... custom-made home-grown formats ... with the appropriate toolbox and skills ... when you need some thing to get implemented and that's it ... It is something lawyers just don' understand, I think. 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. I should notify that I can do *anything* in XSLT. I've spend 2 years training. Conclusion. 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. I want to tune up the claim Mr. Leventhal has maid long time ago. Let us compare. You do some routine processing task in XML / XSLT - I think I do it 'better' with Perl / Python / regexprs, plain text. Don't get me wrong. Readability of XML is important, but claiming that XML is easier to *process*, because 'there is XSLT' ... Heck, to process the plain text file with 'regexpr based' lines I have good tools that *work* ! To process XML all I really have is XSLT ( which is *not* a GP tool ) and ... That's all... How can it be easier without the tools... just to echo "entry" >> log.txt I need to mess with the entities ... What are we talking about .... Rgds.Paul. 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. I mean that the only vote for XML over UNIX processing could be : "most of people don't know regexprs" ... well ... what can I say .... Xpath is *much* harder, than regexprs.
|
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
|