New Ways to Look at XSLT

Over at Ask Metafilter, a questioner asks "When you imagine XSLT transformations happening in your mind's eye, what does it look like?"

This is a very powerful question to ask, because ancient, procedurally oriented developers like me sometimes have trouble following the non-linear, pattern-driven processing that takes place when an XSLT template is applied to a tree of XML elements. In fact I have noticed that non-developers sometimes have an easier time with XSLT than do experienced developers, because they don't try as hard to figure out what is happening beneath the covers.

There are many good replies to the question, including a reference to a Dave Pawson's XSL FAQ  a recommendation to use Leo, the Literate Editor with Outlines, and a pointer to some more XSL Resources.

-- Jeff;

Comments

[John]

Hi Jeff,

I am interested in starting something with aws. I was wondering where I could find fairly good list of amazon associate shops to get more ideas. (Besides your blog here)

Thanks.

[J Wynia]

My first project with XSLT a few years back was to actually generate XSLT *from* XML and XSLT and forced me to break my ideas of how it worked. When I finally got the whole "it happens all at once" approach, it started to make sense. However, every programmer that I've brought on board to an XSLT project since has had trouble getting out of the procedural thinking and that ends up being the biggest source for their mistakes.

Unfortunately, like MagicEye images, some people just aren't able to unfocus their minds in the right way to really grok XSLT beyond the simplest examples.

[Robert Oschler]

The same thing happens to veteran procedural programmers like us when we learn a declarative language like Prolog, or the first time you do event driven programming after learning strictly procedural coding.

The latter happened to me when I started doing my first Windows programming with Visual Basic, coming from MS-DOS. Under MS-DOS, everything derived from the main programming loop and was under the control of the main programming loop. With event driven programming, now code executed not when I specifically told it to, but when some asynchronous event happened that was initiated by the user (mouse click, etc), outside my program's control.

The change in thinking was amazing.