When people hear about stylesheets, they usually think of Cascading Stylesheets (CSS) used to style HTML Web pages. There are some other kinds, though, and one of them XSL (the eXtensible Stylesheet Language) - and particularly XSLT (Extensible Stylesheet Transformations) - has been giving me grief this week. Well, that's not altogether true. It's really something else that's causing the trouble.

Bosses always like to think that complicated things can be made easy, don't they? I well recall how the decision to use a particular development system, called Uniface, years ago, was taken on the grounds that programmers wouldn't have to write any program code. It could all be done by painting "Entities" onto a canvas. It didn't take us long to learn - those of us at the code face - that we were spending more time coding around the system's default behaviour than we were spending actually writing productive programming code.

When we started doing Web development, the powers that be went for a Microsoft system (ASP.NET): and I have to say that it's not half bad. I owe it some thanks for providing me with the means to get an MSc, anyway. But it does not fulfill the promise (swallowed whole by our bosses) that Web development would just become a matter of dragging and dropping Web page elements onto a canvas. We soon found out that the only reliable way to produce HTML of a professional standard was to hand code the HTML ourselves.

The latest addition to the gallery of, "You only have to drag-and-drop" tools is BizTalk, Microsoft's message broker software. I think I've mentioned it before. It sits between two disparate systems co-ordinating their behaviours by passing XML messages (almost exclusively) between them. Part of BizTalk's armoury is the BizTalk Mapper. With this tool, it is claimed, programmers can convert an XML message in one format to another XML message in another format. The first message is appropriate for the sender: the second is appropriate for the receiver.

I've spent all this week trying to get the BizTalk Mapper to convert a document obtained from our student database, in the format suitable for data retrieved from a relational database, to another document, in the format required by the recipient (the Higher Education Statistical Agency - HESA). This is for the annual HESA return, which is in XML format for the first time this year. It's pretty much late already and HE insitutions can be fined for late submission of the data. So no pressure there, then.

Well, it turns out that the BizTalk Mapper simply cannot, in practical terms, do the conversion that I want it to do. I've finished up writing custom XSLT to do the transformation. Now, if Microsoft had not written a mapper, and if they'd said up-front that conversion would have to be done via XSLT, they could have saved me several days of frustration. In the end the XSLT was not that hard to write. So all this draggy/droppy stuff has actually cost us time - when we really can't afford it.

But supposing Microsoft had said that. Supposing they'd said, "OK. Mapping is complicated. It needs a human being to sort it out", would our bosses still have bought the tool?

We've reached the silly situation where companies have to claim more automation than can actually be delivered in their products in order to sell them to people whose expectations of technology are way too high.

I read an article several years ago whose main thesis was that managers needed to accept that creating complex systems was and is a complex, difficult process. They should not expect to find magic wand solutions.

But they do ...