Stimulated by the recent debates here and on XML.com, I decided to
strap on the crash helmet and see if I could get work done with
XSL(T) this weekend. I wanted to answer the
"difficult/ugly/superfluous" charges for myself. I failed: no
ignition.
I think I am similar enough to many, many Web designer/developer
types that those who are concerned about XSL's ease of learning/use
for "Web generalists" might be interested in my experience - maybe
also my take on the current XSLT vs. XSL vs. CSS/DOM conflagration.
It's meandering and personal - maybe indulgent. I conclude with a
simple suggestion: skip to it if you get tired.
A qualifying dump about my skills and prejudices:
While I spend much of most days in an editor, I am no programmer. I
am a reluctant, intermittently capable scripter, but beyond the basic
control structures the knowledge rarely sticks for more than a week
(though I really like working with regular expressions, and do most
markup transformations that way now). I do understand markup - do it
all the time, and validate against a library of DTDs I've customized.
I know CSS pretty well, and I like it. Most of my CSS stylesheets are
larger and more subtle than the documents linked to them (in fact,
I'm such a CSS freak that I was invited to the XSL WG - somewhat
embarrassing considering my mean comprehension level of that body's
work). While I would never think of using a WYSIWYG tool for anything
but graphics or print per se, I am profoundly uncomfortable with a
command line. A GUI is essential: one hand on the mouse at all times.
I have had a "tester/surfer" Wintel box under my desk(s) at work for
5 years, but usually end up in a fetal position when attempting to
learn any skills or do any work on a Wintel system, and I have no
plans to be rehabilitated anytime soon - not even by XJesus. I'm at
home: no PC, no IE5.
I learn things by using a specification as a guide to a purported
implementation of said specification (it's a wonder I learned CSS!).
You can probably guess the corner I've painted myself into: no Mac
XSL tools. Well, there's Java. I downloaded XP and XT and realized
that my outdated copy of CodeWarrior is outdated for a reason: I
don't know how to use it. I kept looking and found precisely one
ready-to-run-on-a-Mac XSL implementation in Java: the InDelv XML
browser: http://www.indelv.com/browser.htm
I set out to do something as simple as possible. James Tauber's "XSL
Templates by Example" seemed to present simple enough examples:
http://www.xmlsoftware.com/articles/xsl-by-example.html . I
cut-and-pasted bits into InDelv's "Shakespeare" demo XSL files, but
after a few hours of fiddling with various settings, reading specs,
and editing madly away, I gave up.
If I could describe exactly what went wrong, I probably could have
solved the problem. I was trying to transform the play's STAGEDIR
elements into P elements (any resemblance to HTML is accidental), and
ignore the rest (i.e., I wanted output consisting of nothing but
stage directions marked up as P within a root element.) Inside
several candidates for appropriate start tags and root rules,
pilfered from examples, this:
<xsl:template match="STAGEDIR">
<P><xsl:apply-templates/></P>
</xsl:template>
Suffice to say that in this deliberately bone-simple example, nothing
worked as expected when opening the play in the "browser", in browse,
source, or tree modes. Either no rendering at all, or no apparent
transformation: just a dump of the whole play.
InDelv's browser implements FOs to some extent, and the original
Shakespeare stylesheet did indeed go to FOs. I *was* able to edit the
FOs trivially - no big lights came on. I can't quite believe that I
can't get a simple transform out of this product. Can anybody steer
me in the right direction?
Personal opinions about XSLT and XSL:
I see the value of XSLT. I'd rather not do *all* transformation using
scripting/DOM (see skills/prejudices, above). Pattern matching and
markup is easy. So hooray for XSLT.
I am torn on the value of XSL (FOs), at least to the extent that I am
averse to using world-networked, display-equipped computers to
emulate printing presses.
<rant>
I love old books as objects, but few new ones unless largely
hand-made. On the net, I care about displays first of all: paged,
layout-driven, constraint-based, device- and user-profile
parameterized, font-independent yet font-metrics-aware, interactive,
*screen* composition. Not Adobe Acrobat: not "DHTML" (please), not
TV. It is harder to do good screen display than good print (good
printing has already been invented): solve the hard problems first
and the lesser ones solve themselves. Raise the standard for screen
rendering - and screens - to a print-superior level of
adaptability and
sophistication, and then treat paper as a special sort of screen:
high-res but static.
</rant>
On the one hand, the notion of an "HTML/CSS formatting object" as
opposed to a DSSSL-style FO is perverse. Being more than a little
familiar with the now-canonical GIF-and-table HTML kludges of 1995, I
think that HTML as a visual formatting language must be cudgeled to
death at once, and I see CSS as the nearest club. So I revolt at the
thought of HTML being a crutch for any formatting system - especially
CSS - just because MS can't/won't implement CSS completely enough to
cut the cord, and Mozilla is reforming itself a bit slowly in Web
years. I'll take REAL formatting objects over lobotomized HTML with
heavy, not-quite-correct CSS frosting any day.
On the other hand, syntactical matters aside, XSL appears to be
redundant with CSS to the extent that it applies to the screen.
Quality FO implementations for the screen appear even more remote
than quality CSS implementations. Given that CSS and XSL are
ostensibly evolving toward a common formatting model anyway, that
leaves syntax and processing models as salient differences: mostly
trivial for a non-implementer like me.
I suspect I'll end up using XSLT on the server for all kinds of
things, and X(HT)ML+CSS+DOM on the client for the foreseeable future,
starting in less than a year if we're all very good and very lucky.
A concluding suggestion:
Somebody slap an HTML form UI on XP/XT and whatever else is necessary
to make XSL work. At a minimum, let users provide the URLs of XML
documents linked to XSL stylesheets (or provide the PI manually), and
return the result, whether XHTML, FOs, or some other flavor of XML.
In fact, I'll do the front end work if somebody here works with me on
the back. This division of labor parallels the most common one in the
Web industry: programmers on the back end; writers and designers on
the front. And that's the point: if a principal virtue of a
declarative language is to open the field to writers, designers, and
other non-programmers, don't make them face a command line (or use a
platform not especially well-loved in the professional design and
publishing field) to get started with it.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list