[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: advocating XML
- From: Paul T <firstname.lastname@example.org>
- To: "Thomas B. Passin" <email@example.com>, firstname.lastname@example.org
- Date: Tue, 13 Mar 2001 20:30:29 -0800
> 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
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
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
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*
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 !
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
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 ....
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.