RE: [xsl] Wishes for XSL revisions ...

Subject: RE: [xsl] Wishes for XSL revisions ...
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Thu, 27 Dec 2001 12:03:48 -0500
Speaking as a "non-programmer", but one who writes quite a bit of XSLT:

At 07:41 AM 12/27/01, Andrew wrote:
1.  Is there ever a good time to use a for-each? From reading this list for
a while these seem to be the root of most problems and are very rarely
included in any solutions... are they really necessary? (Ive read in places
they were intended to make the language easier to learn for beginners!)

Yes, there is. Even the most die-hard of us who disparage it will admit this, I'll warrant. When used properly, it can make stylesheets simpler to read, write and maintain. It also provides useful workarounds in edge cases (to momentarily change the context node inside a template, for example). When used improperly, it soon has the opposite effect. When it is improperly used it is almost always because the stylesheet designer is unaware of or still uncomfortable with the available alternatives.

Whether they are "necessary" depends on what you mean by "necessary".

I have never seen it argued that it was "intended" to make the language easier for beginners, and personally would doubt this. (If you or any reader can quote this argument directly, with any evidence for it, it might give somebody something to rain on. :-) I have seen it argued that it does this -- but personally I think this argument is specious, not too unlike saying that a cake mix is a good way to start learning to bake. It is not that you can't learn XSLT that way -- indeed, some proponents of this point of view certainly know the language and are good teachers, tuned in to how people learn. But I would argue that experience shows that xsl:for-each is most dangerous in the hands of a beginner who does not have the advantage of direct guidance by an experienced practitioner. It might provide an easy way in if you are so guided -- for about an hour or so. Beyond that, they better take you to templates or you'll get in trouble. (My $0.02!)

But all this is just generalization: specific cases are strongly affected by the experience, background, expectations, temperament and style of the learner as well as the nature of the data, the requirements for the transformation, and other unknowables such as whether you're ever going to write a second stylesheet, and what *that* one will have to do.

2.  If a variable cannot be changed after it has been assigned, why call it
a variable?  Ive read the reasoning behind this, and yes strictly it is a
variable, but a more appropriate name would make sense.

It makes sense if (a) you know the term "variable" from algebra, not Perl (the extremely naive case), or (b) you are aware that technical terminologies are by nature somewhat slippery when you try to carry them across domains (the very sophisticated case) and don't set too much store by *any* name.

I remember in ninth grade feeling that the BASIC statement "x=x+1" made no sense, but I was willing to bend my brain to live with it. :-) (I later learned to make the distinction between assigning a value, and claiming an equivalence. This distinction is actually quite useful in the study of human rhetorics -- and maybe in understanding XSLT.)

The above makes XSLT non-intuitive, and therefore harder to learn.  Is there
another language where you cannot change the value of a variable?

I'd submit that there are cases where "harder to learn" also means "better to learn". Paradigm shifts and all that. I'm not arguing that this is one of those cases. As to your question, that depends on what you mean by "variable" -- a predefined thing (let's see the definition), or whatever the language in question calls a "variable"? I believe there are languages that have something named a "variable" with properties similar to the thing XSLT calls a variable.

Thanks for your comments, Andrew.


====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================

XSL-List info and archive:

Current Thread