Re: advocating XML

[Paul T <paul@pault.com>]

> 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.