Re: advocating XML

[Paul T <paul@pault.com>]

----- Original Message ----- 
From: Thomas B. Passin <tpassin@home.com>

> 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 

.section_begin
content
.section_end

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

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
> real".
> 
> 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
> generators.  

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

*only*promoted*existing*scripting*tool*to*do*something*with*xml.

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

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

Conclusion : 

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

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.

;-)