>It's good to see that education is serving a purpose, anyway.
>Remediating buggy machine-generated code on a deadline: that has to
>fall into the category of dirty jobs someone has to do. Fun.

Quite so.  It's a heck of a lot better than trying to use BizTalk's
drag-and-drop "mapper", though.  I even blogged about that:

http://peredur.blog.co.uk/2008/09/11/a-matter-of-style-4714835

>FWIW, as I suggested, seeing constructs like
>"normalize-space(element)" vs "string-length(element/text()) > 0"
>is part of what tips off an expert as to whether code has been
>written by a skilled practitioner of XSLT/XPath, or by a Perl or
>Javascript or C programmer who has just jumped in.

Got it in one!  Well, two out of three, actually.  My Javascript isn't
so hot.

>Or maybe by a
>program written by one of these estimable people.

Not guilty

>The best defense
>I've heard of expressions like the latter is that it's more explicit
>-- which may be true, if your audience is like you. The most honest
>is that it's done out of habit.

Agreed.  Languages should be used in the way they were intended to be
used.  I always feel that languages have a grain, like wood.  Going with
the grain is so much easier ...

And I happen to think that well-written XSLT can be really elegant.  So
I'm aspiring :)

>The XPath way is obscure if you don't know XPath. But I've never felt
>it was wrong to give those who don't know XPath, but who are trying
>to program XSLT, a little XPath exercise. :-)

Agreed again.  And I'll get there.  It may just take a little practice
... and a few more posts here.

:-D


Peter