[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: advocating XML
- From: Paul T <email@example.com>
- To: "Thomas B. Passin" <firstname.lastname@example.org>, email@example.com
- Date: Wed, 14 Mar 2001 01:41:16 -0800
----- Original Message -----
From: Thomas B. Passin <firstname.lastname@example.org>
> Well, I've also done the regex route, both with python and awk. In fact, in
> this job, I got the form data into the database using python, no xslt or xml
> involved. And I've generated enough html programmatically to know that I'd
> rather use templates than functions.
I agree ;-) Somehow ;-)
Yes, it is better to generate html using templates!
Both Python and Perl have dosen of solutions for that.
As to XSLT *processing model* when rendering HTML ...
It is fine for simple cases. In complex cases, XSLT
turns to be a problem.
> If I have a straight line-oriented job
> I'll probably look at awk first, then python. So I do know what you're
> talking about here.
The problem is that for me it is now hard to tell if something
is 'straight line-oriented' or not. I mean that many things
could be turned into 'line-oriented'. Also, processing
sections of lines with
is not that hard in modern scripting languages ( Python and Perl
are much better than awk .. )
> In fact, I'd bet that a lot of the people on this list have used their own
> private text formats which they turn into xml using a script and some RE or
> string processing.
No doubt! My point is that I was also doing that for a while, then I saw
XSLT and decided : "O! XSLT is so cool! I should replace
my RE-based processing with XSLT-based processing".
And then I tried hard. I've spend a lot of time doing that ( Ux
was just an attempt to replace RE-based processing with
XSLT-based processing ).
After a long time of doing that, I realised ... It just sucks.
Really. What helped, was a quick look at Zope's horrible model.
I just realized that this even 'horrible' model helps me *more*
than 'accurate' and 'elegant' model of XSLT.
> > 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 !
> I find regular expressions at least as difficult and error prone as xslt
> expressions. I suppose it's a matter of practice and how your mind works.
Nope. I disagree. With regular expressions you can test if re.match returns
true and complain if it fails. And you do that in one if : else : statement
( it is simple and terse ).
Try doing that in XSLT. No Way. re.match provides a guard, but Xpath
has no guard. It just returns 'something empty'. I've seen a *lot* of
situations when people are producing broken HTML with XSLT. For
example, in a sense that some tags are 'kept', when they should be
'rendered'. Any XSLT transfromation that builds on well-known
"identity transfromation" ( i.e. bypass everything that is not explicitely
rendered ) is likely not to 'render' some tags. Silently. And such things
are hard to capture even visually.
> Either way, I have to do a LOT of testing. I usually find it's easier to
> break a tricky RE than an xslt statement, but your mileage may vary, as
If you don't put else: branch after re.match - then yes. You may spend
a lot of time testing. If your else: branch is complaning about 'broken RE' -
you should be fine... if, of course, your delimiters are 'good'.
I mean that to have efficient RE processing one should think about efficient
delimiters and stuff before writing actual RE.
The same 'look ahead' applies to XSLT. Some transfromations ( like grouping )
suck in XSLT, so the workaround is "change the schema". Really. I've been
reading XSL list for a while and it was FAQ. Don't know if it is still FAQ.
In fact Xpath and RE have many things in common, the only difference
is that select="Xpath" has no reasonable guard.
re.macth can return 'false'.
> > '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
> Depends on the job. In this case, I'd need several scripts that play
> together, and output some format, like HTML. I could easily have done it with
> straight scripts. I tell you what, though. For a quick one-time thing, I'd
> probably use a script and be done with it. But when I expect to do something
> over and over with variations, I find I want templates and program/document
... both Templates and Generators *do*not* imply XSLT ( and XML )
> I look back at some jobs where I created a bunch of html by
> scripting, and wish I had done them with templates instead. If you are using
> xml, then xslt is a natural to use for templates, although you could of course
> use something else.
If you are using XML, XSLT is the
Of course it is 'good'. It is 'the only one'.
However, I now think that something like Matt's XPathScript
may occasionaly replace XSLT ( when xml processing will be
really used by more than 1000 geeks ;-)
Xpath ( or XQL ) + Python or Perl scripting attached = should be best
of both worlds, actually.
> And some things are still done better with scripts. In the job I mentioned, I
> used a mix.
A simple Python/Perl library based on Text:Template + simplified Xpath + *really*
small set of XSLT constructions - and you have the solution that should
win *any* usecase over XSLT, because general-purpose scripting
programming language will drive the show. Not so with Java, of course,
but why should text processing be performed in low-level language?
Even 30 years ago there was awk.
I may write such a library occasionally in 2-3 weeks. But I don't
think I will do that soon. Here is why:
The problem is that nobody will use it like nobody now is using XSLT.
I mean that I'm making money being a contractor in silicon valley.
There is no reasonable contracts for XML / XSLT processing.
Really. I've been looking for a year. When some contract
has a word XSLT in it, it is usually talking about very funny rate.
XSLT and XML are not considered to be a skill at all.
I dont know why, but I think ... maybe ... people don't really use XML
*that* much ( because if really use XML ... one may soon realize
that scalable / efficient XML processing *is* a skill ).
I mean they do use XML and I saw how they do that, but ... you know ...
in one company they XML-ized one of their APIs and after one year
they found it to be a disaster ... And I think they were right ...It
was a disaster... The way they did it ... And the layer they've
abused ... Really ... XML-izing is attractive, but it has too many
Remember Java? Remember these billions wasted into writing
monsters in Java? Not that I have something against Java, but
I started to like diversity ... and after the school of XSLT and SAX,
I now write in RE as if I have XML - *that* really helps ;-)
> So I actually agree with most of what you said, but I still come out with a
> different conclusion. Well, go figure! Thanks for your thoughts.
I think I should write the conclusions, because my lettres
are messy, but so are my thoughts...
1. XML is fine when readability is important.
2. XML-ization of processing APIs and especially using XSLT for something other
than rendering simple HTML pages is hard. And I doubt it makes sense in many
3. The line between 'processing API' and 'XML that I export' is very hard to draw
and I think that (3) is the biggest challenge of XML, because letting XML into
places where there should be no XML is ... Not good ...
I'm sorry for writing such a long letter, but I wish it explains my current
position on XML and XSLT. I think both are good things but both are
not a solution 'as-is'. And both are overhyped, I should say.
When Simon said that "think if you will share the file" - I thought that
what he says is very reasonable advantage for XML over CSV.
When you added : "and you'd love some XML processing tools" -
my reaction was : "Oh, no! It is not that simple with the tools!"
Anyway, for some magical reason, most of developers whom I know
are going over the same path with XSLT : "It is cool and simple -
It is cool and complex - It is complex and it does not look cool for me".
I have a feeling that the inventor of XSLT has reached stage three
a bit earlier than the rest of us.