[XSL-LIST Mailing List Archive Home]
RE: [xsl] Transform XML to XML
Subject: RE: [xsl] Transform XML to XML|
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Thu, 25 Aug 2005 19:00:31 -0400
At 06:09 PM 8/25/2005, you wrote:
One thing I do really dislike about XSLT, at least from what I
understand, is there doesn't seem to be a way to write robust code in
XSLT; if my input XML is off by a bit (i.e. well-formed but not
validated by a schema), or if I make a boneheaded change to the XSL, the
transform may not output what I expect but there's little way for me to
catch the error without painstaking proofreading after each transform
(scenario: after somethings been printed for a while; opps, looks our
XSL forgot to include that chapter!)
That's an issue, but it's much less of an issue if you let the language
work for you (which involves making friends with the default templates :-)
than if you struggle against it.
>> So if the new bits of information -- about the identity transform,
the built-in default templates and their function (which the identity
template overrides), and the difference and marvelous complimentarity
between matching (xsl:template) and selecting (xsl:apply-templates) --
don't all by themselves flood your brain with understanding -- again,
please feel free to post.
Now that you mention it...why are their default templates and is there
any way to turn them off? They are almost never what I want, and they
almost always seem to give me conceptual trouble when I'm trying to
figure out why my transform isn't working like I expect.
Once you know why they are there, they won't present any more conceptual
trouble and you will see that actually they are very helpful.
They are there so that the entire tree gets processed by default.
As for being almost never what you want -- that may be so, but they are
what you always want for nodes in your input that are not matched by
templates of your own. This is to "continue heading down the tree".
If this is *not* what you want for a given element, that's when you write a
template. For example, let's say you don't want to continue, but actually
want to suppress an entire branch. A branch of the tree is easily
suppressed by matching it with an empty template, as in
which suppresses all <secret> elements, by matching them but writing
nothing to output ... nor applying templates to the child nodes of <secret>
(which is what would happen by default).
But if there are some things inside <secret> that you want, and others that
you don't, you might suppress (or express) *those* by writing templates,
and let <secret> be picked up by default.
Also, matching and selecting do confuse me. I'm best when I do
<xsl:call-template> :) Also, the matching and selecting part seem so
fragile, like one tiny thing is off and they don't work correctly. Is
there anything short you can tell me that might help me grok those?
BTW, I own and have read about five total books on XSLT and on XPath,
and another four on XSL:FO.
Hm: tell us which books you have, an we can tell you which sections of
those books to look at -- how's that?
But XPath in particular is a dangerous tool in the hands of an XSLT author
who doesn't grok the default processing model or how to take advantage of
It's not that the stuff is so difficult to understand: it's not. It's just
non-obvious, a bit tricky to explain in the midst of other complications.
So, more anon....
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