Re: [xsl] Diagramming XSLT

Subject: Re: [xsl] Diagramming XSLT
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Thu, 17 Apr 2008 10:44:38 -0400
Hi,

At 06:57 AM 4/16/2008, Torsten wrote:
1. XML/XSL is organized like a "matrushka" (everything nests; showing an
image of a matrushka might be visualization enough!). You can organize
both content and processing this way. Processing the xslt means to
(virtually) nest the templates (called ex- or implicitely). Thus you
only need to show two levels, the rest is up to imagination.

I like this idea a lot.


2. Look at the XML/XSLT file like a SAX parser would do: reading a start
tag means to open another (matrushkanian) level (XML) or to apply
another template (XSL). Reading a closing tag means to get back to the
last level.

3. Look at the XML/XSLT file like a DOM parser would do: Traverse the
tree applying two rules: a) go left as far as you can; b) if a) is not
possible go back until you find a sibling, go right and apply rule a)
again. That sometimes things are stored in variables or params and taken
with them on the way shouldn't increase the difficulties to understand
the paradigm to much.

Well probably both the SAX and DOM parser connections will be too obscure for many (most) audiences, but it's true that the nub of it is in seeing how the recursive containment structure of an XML document maps directly to the notion of a branching tree that can be traversed by selecting nodes.


But while I'm convinced that an understanding of this is central to "getting" XSLT, I'm not entirely convinced that this particular point is going to be critical for any audience. I've certainly presented XSLT to audiences for whom it is ... and also to audiences for whom it is not. For example, managers, whether executive decision-makers or even project managers, may be better served by some grasp of what sorts of problems XSLT is designed for and is well-suited for than by the details of how XSLT accomplishes solutions. "Shaggy" (semi-regular) data, up- vs. down-conversion, what a "transformation" is in general: as we know this can be a very different thing from what many are used to from their data-crunching or "document" processing experience. This does involve some appreciation of how XML markup provides for labeled structures in arbitrarily deep hierarchies, but may stop short of the particular methods and algorithms that make such data structures tractable. Rather, they need to know that many problems are now easy that used to be hard -- and which sorts of problems those are -- if only you have the right tools and the right skills.

So again, it really depends on your audience and their goals. An audience that needs a clear appreciation of the processing model might actually be better served by a tutorial (ideally with hands-on exercises) than by a chalk-and-talk. (Not that the line between those isn't blurry.)

Cheers,
Wendell


====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================

Current Thread