Re: [xsl] Avoiding boneheaded mistakes in XSLT?

[Graydon <graydon@xxxxxxxxx>]

On Thu, Dec 30, 2010 at 09:05:02AM +0000, Dave Pawson scripsit:
> But consider the typo that we all make from time to time .... to time.
> If it can help find that, it helps debugging.

Well, yes, but I think you're tangling stuff up, here.

There's syntax, which is already pretty well reported, though the error
messages would benefit from a "verbose" switch, so you got something
that doesn't assume you understand the data model.  You can machine
check syntax.

And there's semantics, which you can't machine check without a schema
and not necessarily even then.

For example, the content I'm working on at the moment has XML elements
named "text".  (The schema designer, almost certainly correctly, decided
that the preferences/customs of the folks writing and editing the
content came ahead of the sanity of the XSLT developer.)  And there are
places where one has to wander into a text node to do things like add
literal quote marks.  There's no earthly way you could machine check
that code for "did you mean text() here?" issues.

In general, cleverness leads to complexity and complexity leads to
failure. Error messages that try to infer semantics pretty much
_must_ descend into cleverness, and so I don't want them.

I'm much rather have the XSLT processor as nearly free of cleverness as
human ingenuity can arrange; I want to be sure it's working, rather than
having to wonder if it's failing to help me in some interesting edge
case way.

"Let's scan the transform and see what might be wrong with it" to my
mind belongs in a distinct application, much like lint for C back in the
day, if it's needed at all.  I think nearly all of the kinds of errors
you're talking about can be addressed better by programming style.
(default templates that give warnings; start with the copy constructor;
change one damn thing at a time; compare the input string value and the
output string value for differences)  Since, after all, the semantics
are the programmer's job, not the processor's.

-- Graydon