Trouble with Transformations
By Michael Floyd
Have you had the argument yet? You know: It's the
discussion in which the entire development team sits around the conference table
and argues, heatedly at times, over who should develop the XSL transformations.
The programmers don't want anything to do with them and neither do the Web
designers. Managers are caught in the middle, and sometimes don't understand the
intricate technical issues associated with XSLT. At the heart of the issue are
major misconceptions held by all parties about the role XSLT plays, how you can
use it, and even the methods for creating XSLT documents.
This month I'll describe some of the myths surrounding XSLT, its role in XML
applications, the problems that style sheets introduce, and approaches you can
use to solve a thorny problem I call the propagation of style sheets.
Debunking the Myths
Myth One: Style sheets are for presentation. A typical misconception held by
management is that XSLT is used to render XML documents, add styles to
characters, and create views to data. Thus, the team leader or project manager
leans toward handing it off to the Web designer or HTML author. However,
although the application of your transformations may be intricately woven around
the data presentation and HTML, they could equally involve mapping database
fields from one format to another.
Myth Two: The Web designer/author can't do it. Did I mention that most Web
designers have no intention of learning something as verbose as the XSL
transformation language? Like most generalizations, this one may be a bit
unfair, because I'm lumping designers and HTML coders into one group.
