If you’re coming from a different programming background, one feature of XSLT (all versions) may seem especially difficult to grasp. I’m not referring to the XML-based syntax; once you get a feel for it, it is surprisingly transparent (even if bulky). For many novices, much more puzzling is XSLT’s lack of an assignment operator. Read the article at DevChannel.
XSLT: Taming a functional language
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
If novices are confused by the differences between a functional language and sequential programming language then perhaps they should revisit Programming 101.
I hate XSLT with a passion. XML makes some degree of sense as a data storage format, but XSLT should really have been designed as a proper programming language. And yes, I understand that one of the benefits of XSLT is that you can use XSLT to transform XSLT programs, but you don’t need to have such a baroque language to get that advantage. The deep irony of all this is that people ignored Lisp, which has been doing precisely this sort of thing for decades, because of the supposedly awkward syntax, but are enamoured with XSLT, which is so much more awkward!
Also, the article gets one of the dates wrong. Functional programming dates back to Church’s work on lambda calculus in the 1930’s, and the first functional language was invented in the 1950’s. ML, perhaps the archetypal ‘modern’ functional language (strictly typed, etc), came out in the 70’s.
Rayiner, did people realy ignore Lisp? It’s still taught and used in every university in the USA isn’t it? The “other” xsl, DSSSL, is heavily Lisp orientated. There are even real applications in functional languages – the popular mldonkey file share daemon is written in Ocaml.
XSLT has a lumbering syntax – as does XML but if you apply it for what it was inteneded – simple XML transforms it’s quite usable.
But is it such a success story? How many web sites use XSLT rather than CSS? Who is about to give up FrameMaker for XSLT:FO? Who is using it seriously as a programming lanuage? Almost nobody. I bet you it still has a fraction of the user base of even DSSSL.
http://martinfowler.com/bliki/MovingAwayFromXslt.html
functional programming is wonderful, xslt is not
A novice have not necessary done the “Programming 101″…
Its a figure of speech.
A real programmer will have no problem understanding the declarative syntax of XSLT but will find the fact that array indexes start at 1 deeply confusing.
I’m not kidding.
This is a poor result of our c-ish dependence, programming wise.
Since array indices represent things, you are saying you begin lists with zero?
It is the most unnatural thing in programming, and I hate it.
People have blown apart what XML is. Say it with me, it is intended to be a data description language!
Why are people transforming one XML document into another XML document? If you have a well described XML document, that is all you should need because it should describe the data contained within that document.
Sorry, but that is my 2 cents.
Real programmers count from zero. That’s just the way it is. Sometimes i count things from zero in real life, but i never count from one in code by mistake.
It’s not more “natural” to count from one, it’s just what you’ve learned.
It’s like how in some countries the ground floor is called “the ground floor” and the level above is “floor 1”, while in others they are called “floor 1” and “floor 2”, and everybody claims that their way is more “natural”.
No matter what, computers always start from zero (or subtract 1 from the index to get an offset).
A real programmer will have no problem understanding the declarative syntax of XSLT but will find the fact that array indexes start at 1 deeply confusing.
Hmm, what I’ve always found confusing is languages that insist that arrays start at 0, or at 1. Pascal, Modula-2, and Eiffel have a much more sensible view of it: an array starts wherever the programmer wants it to start.
Maybe I’m not a real programmer, though; I learned to program with languages that were supposed to teach you how to program properly. These days, it seems that “real” programmers use languages whose very design seems to impede proper programming. 😉
XSLT is a very misunderstood language. Yes, it is bulky to write and it doesn’t have a lot of the functionality you would hope for (yet) like regular expressions, arrays, additional built-in functions, etc. But, if you use it correctly, it is a powerful tool to have in your toolbox. Take for example financial applications like GNUCash or jGnash which store their files as XML. In order to convert those files to the de facto QIF format, one simple XSLT is all you need.
On my project, we use a mapping tool designed in house which produces an XML document that defines the movement and transformation of data from one place to another. We then use XSLTs (because DOM programming is just as messy and not as flexible for on-the-fly changes) to convert the one XML mapping output file into everything from an HTML report of the mappings, to a PERL script or a T-SQL script that actually performs the movement/transformations. The concept of using XML coupled with XSLT for code generation is way ahead of its time.
It is true that XSLT is not the best tool for many jobs, but it was created for one purpose only – to transform XML into anything else. Where it fails is when XML is not a natural medium for data storage and is crammed into a project just because it’s a buzzword or a new technology that someone wants on their resume. It’s much like PERL in that it is sometimes judged harshly on its weaknesses because of how often it is misused on tasks it wasn’t designed to do.
If you’re looking for XSLT help, this site is invaluable! http://www.dpawson.co.uk/xsl/sect2/sect21.html
Real programmers count from zero.
Um, no.
Real programmers count however the application requires them to count. Sometimes, it is more natural to count from a number other than 0, because that corresponds better to the use of the application.
The limitations of a programming language may constrain the programmer to count from 0, then “translate” in their minds to the actual needs of the application, and certainly real programmers ought to be able to do that.
However, that is a limitation of the language involved. A properly-designed language should minimize the amount of mechanical work that the compiler could do as well (or better) than the programmer.
Starting an array from 0 is something the compiler should do, not the programmer. This is a serious deficiency in C-style languages, which IMVVVVHO could be easily fixed.
XSLT succeeds in making simple tasks difficult and difficult tasks impossible.
Do yourself a favor and stick to CSS/Javascript coupled with a decent server side language (take your pick, PHP, Perl, Java etc).
who said: drop css for xslt?
xslt is great for xml to xhtml work. It basically adds a lot of nice posibilities.
you can split code and design completely and still let the design be heighly flexible.
what is wrong with having [xml -(xslt)-> xhtml] + css?
there is nothing wrong with that.
Now: if bowser would support raw xml there would be no need for xslt, but css would have to be extended, or your xml would loose flexibility and get scattered with hyper text markup tags.
just my 2¢
-mo
With the exception of Tim Barber and those who don’t work with XML, no one doubts the utility of XSLT. What many object to is its syntax, and I wholeheartedly agree. I *want* a language that can do what XSLT does, I just want it to have a different syntax.
So there are really two questions here:
1. Is XSLT useful at all? (My answer: Yes).
2. Is XSLT’s syntax abysmal? (My answer: Yes).
I completely agree with mo!
> who said: drop css for xslt?
> xslt is great for xml to xhtml work. It basically adds a lot of nice
> posibilities.
Yeah … css is to xslt as paint is to canvas! The two are used for completely different purposes. CSS is a visual presentation language; XSLT is an XML transformation language.
XSLT, for example, lets you take one piece of data in an XML format and convert it to, say, a web page (HTML), a graph (SVG), a spreadsheet (CSV) or pretty much anything else you can think of. CSS on the other hand lets you present your web page to PC users (@screen), PDA users (@compact – ?), a printer (@paged) plus any of the other current @media types available.
> what is wrong with having [xml -(xslt)-> xhtml] + css?
> there is nothing wrong with that.
This is precisely the strength of XML/XSLT. Separation of data from presentation. A similar concept to OOP MVC. And it works *really* well when it’s used properly.
> Now: if bowser would support raw xml there would be no need for xslt, but > css would have to be extended, or your xml would loose flexibility and get > scattered with hyper text markup tags.
Not true! Most browsers support XML to some degree, in the sense that you can use IE or Mozilla to navigate a XML doc. But what should they do with it? XML doesn’t have style information (by definition). XML is the base data definition – it’s XHTML, XForms, SVG, SOAP etc. that browsers should support. When that happens, XSLT will really come into its own as it’s an XML native, platform independent transformation language designed specifically to convert one XML document into another.
I’m not denying that XSLT is very powerful and useful. I’m saying that it isn’t nearly as good as it could be. The underlying principle is very powerful — data being transformed by programs which are themselves data that can be fed to other programs. It results in lots of very cool possibilities. However, the XSL language itself is a very poor way of achieving what it is trying to achieve.
XSLT is unnecessarily cumbersome and constraining. It also forces the programmer to learn a whole new way of programming, instead of using the programming paradigms he is already used to. For example, why force functional programming? Why not make imperative constructs an option for when they are more appropriate?
I agree. XSLT is clunky. But I’d argue that so is DOM manipulation. Maybe it’s that I had some ColdFusion experience once upon a time, but I think that tagged languages can be more natural in some contexts.
I think one of the more confusing aspects of XSLT is not that it’s a functional language, but that it uses terrible and misleading names for its constructs. <xsl:variable> is a perfect example, because it is anything BUT variable. The XSL equivalent of a CASE statement is <xsl:choose><xsl:when/><xsl:otherwise/></xsl:choo se>. What was wrong with picking keywords that are used in other mainstream languages to make the verbage a little less obtuse?
However, my previous post was to point our that, despite its shortcomings, it really is a powerful language not to be discarded.
I used to dislike XSLT because all I ever saw it used for was display. You’d have some huge XML document that contained all the different values a web sites menu could hold. An admin logs in to the site XSLT transforms that document into HTML to display an administrator menu; the same for customer, merchandiser, etc; they each get a menu tailored to their needs. Seemed like overkill, it was easy when it was just Admin, customer, merchandiser, reseller. Once it got to be reseller of this kind of product show this menu, reseller of this kind of product show this menu. Got to be a mess and made me dread any sort of menu changes.
My latest contract I had to use it differently. I receive an XML file from a company in PA. I use XSLT to transform it into a flat file for use in an automation system. The good thing about this is the company I’m working for chose a new vendor to send us data, yet we can still use it with old systems. I also use XSL-FO to transform that same XML document into a human readable PDF format. All-in-all once I got the grasp of it all (especially XSL-FO) I found new respect for XSLT. It’s still painful to work with (Although XMLSPY helps make it a little more bearable); but I have finally seen it’s power.
Ha, some folk here don’t even seem to know what XSLT is.
It’s not a replacement for CSS. It’s about XML. CSS isn’t XML. I suppose you could produce XML with style=”” attributes, but they’re seperate ideas.
XSL-FO not a replacement for Framemaker. XSL-FO is typically used as an intermediate format for the dynamic generation of PDFs. Most processors are a tad slow, doing about 5-10 pages a second, but most people forgive this because XSL-FO is such much easier than the other PDF toolkits (though the other toolkits are very fast, 30-50 pages a second).
It’s for XML manipulation, and easiest to write when stringing together a pipeline of XSLT (the output from one is used as the input for the next). XSLT is a simple programming language provided you get the fundamentals about functional programming.
It’s often used as an internal flow, from an XML source via XSLT to (X)HTML.
The array indexes argument isn’t a technical one — compilers can deal with either equally fast and remove the unused index. In XSLT you can specify the index of a node by position() if you want, but generally for-each is easier.
The procedural alternatives are DOM or SAX based, and may be more suited sometimes. I end up using these methods when I want to do something like date formatting, or to use the XML data as input for some library.
The funtional alternatives have poor software support. DSSSL is not much fun
XSLT is supported in every language under the sun. PHP, .NET, Java, C, C++, Python, Perl, and the list goes on miles.
There are problems with it. It would be great to be able to call external functions when processing a node. It would be great to have more string manipulation functions (a string replace, for example, requires a recursive function at the moment — while you just cut and paste the function into the XSLT and treat it like an internal function I shouldn’t have to).
I’ve been writing XSLT for 3 years now (Work projects for a Word2Xml converter, Apache Cocoon for large sites, my open source forum software, Phpilfer) and although it’s not a general purpose programming language (strictly for XML manipulation) it’s a god-send for tying together the feeds of data that come from any website or application.
> Why not make imperative constructs an option for when they are more appropriate?
If you really _need_ to use imperative constructs in XSLT, then you’re using the wrong tool.
But BTW, is there anything for which imperativisms are/would be useful in XSLT?
If you really _need_ to use imperative constructs in XSLT, then you’re using the wrong tool.
You have to think outside of the very closed confines that XSLT allows you to think. You shouldn’t ask yourself: “when would I need imperative constructs in XSLT,” but rather, “would imperative constructs be useful in XSLT’s problem domain.”
The problem that XSLT tries to solve is how to perform arbitrary transformations of structured data. XSLT is a poor solution to this problem. A proper programming language, in which programs are themselves represented as data, is a much better solution to this problem.
So the question becomes, in the problem domain of transforming structured data, would imperative constructs be useful? I would say yes. Trying to shoe-horn everything into certain constructs, just because that’s all your language offers, is ridiculous.
A proper programming language, in which programs are themselves represented as data, is a much better solution to this problem.
Well, XSLT satisfies this part.
I think to agree with the idea I’d need to know of some scenario where imperitive constructs are useful. I haven’t seen a good example yet
XML is a text based machine readable format. It is not very appropriate for human processing.
In language design, semantics are much more meaningful that the syntax and, for XSTL, maybe the single most essential tool would be an editor/translator designed to hide the undelying syntax.
( Isn’t there any Python or Lisp to XSTL translator under development somewhere ? )
“Real” Lisp programmers love its syntax because it’s actually abstract syntax trees, there is no useless punctuation noise whereas XML is really noisy. ( Historically, the Lisp S-expressions where perceived as a temporary format, until a proper infix format is discovered. The migration has been delayed indefinitely ! )
Today, computers are powerful enough to adapt themselves to human manageable formats. The fact that the underlying data is stored as an SGML file, a binary random format or ancient chinese idioma doesn’t matter.
XSTL is hiding semantics behind a dumb syntax.
Good grief, it’s called XSLT, not XSTL (not a typo on your part — you did it three times).
Saying that XML is a machine readable format – not appropriate for human processing is obviously untrue. If it were about machine readable and not humans then they may as well have used binary. It’s about having a format that people can browse and begin programming against, and a format that is structured for computers.
I don’t even know why I bother. You obviously don’t know the basics.