A would-be user's first XSL experience (long)

Subject: A would-be user's first XSL experience (long)
From: Todd Fahrner <fahrner@xxxxxxxxx>
Date: Mon, 31 May 1999 18:25:52 -0700
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



Current Thread