Computing seems to have a propensity to generate an
awesome acronym soup; two examples being XSL and XSLT.
The difference between these is rather nuanced.
Frankly, for most purposes, I would consider them
interchangeable. But if you really want to know the
difference, this book does a neat job explaining.
Both have to do with manipulating XML documents. XSLT
transforms an XML document into another document. The
output can be XML, or any other format, with XHTML
being a popular choice. XSLT does not necessarily have
anything to do with presentation, per se. It is a
declarative language, like SQL, and unlike C or java,
which are procedural languages. If the latter is your
background, this may be your biggest impedence
mismatch. Takes some getting used to. But the text is
clearly written to help you along.
Pure XSL, on the other hand, is an XML based
formatting language. It is explicitly for displaying
documents. In fact, it draws many of its property
names and actions from CSS (Cascading Style Sheets).
This was done to let those familiar with the latter
pick up XSL quickly. There is a long chapter on XSL
that goes exhaustively through its many properties.
TeX and troff gurus will see numerous layout concepts
redone here in new flesh.
Overall, a very useful and up to date book. The
examples and accompanying text do succinctly convey
the meanings intended. This book has clarity. You are
not deluged in unnecessarily complicated explanations.
I do have some caveats. Firstly, tree diagrams are
drawn from left to right?! Those from a computer
science background are used to trees always being
drawn from top to bottom. A minor thing, but still a
little offputting. Like reading a book where all the
pages are in landscape mode, instead of portrait mode.
Secondly, XML is case sensitive, unlike HTML, as the
author points out. So, for example, <body> and <BODY>
mean the same thing in HTML. But <atag> and <ATAG> are
not the same in XML. The problem is that in many
places, the author writes a tag in a body of code, in
lower case, like <root>. But he then refers to it in
the text as Root, capitalised for emphasis. This can
be very confusing to an XML newcomer.
Lastly, many chapters could have done with problem
sets and possibly answers. I understand that this
would add to the book length. But it would greatly aid
the reader, by giving her something to attack, instead
of merely reading. Subject retention and all that.
Especially apropos because the subject lends itself to
explicit problem composition. Answers are objective;
not just some vague essay writing. Plus, unlike some
other software topics, the questions and answers can
be concisely stated. There is no need for a mass of
source code.
