Subject: RE: [xsl] Transform XML to XML From: "Mike Schinkel" <mikes@xxxxxxxxx> Date: Thu, 25 Aug 2005 19:36:51 -0400 |
Wendell, Thanks so much for your response; much appreciated. >> They are there so that the entire tree gets processed by default. I guess, like security best practices, my mindset is "don't allow it unless I explicitly ask for it." But I guess it doesn't work that way so I shouldn't fight it. >> Hm: tell us which books you have, an we can tell you which sections of those books to look at -- how's that? -- XSLT : Programmer's Reference by Michael Kay -- XSLT and XPath On The Edge by Jeni Tennison -- XSLT Cookbook by Sal Mangano -- XPath and XPointer by John E. Simpson -- XSL-FO by Dave Pawson -- Definitive XSL-FO by G. Ken Holman -- XSL Formatting Objects Developer's Handbook by Doug Lovell The others are at home. >> 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.... :-> So *that* my problem! :) >> 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. Well, as this comic I heard once said: "I told my buddy: 'You know, your sister's a really fat slob! Well, I don't mean that in a *baaad* way, ya know..." :) -Mike -----Original Message----- From: Wendell Piez [mailto:wapiez@xxxxxxxxxxxxxxxx] Sent: Thursday, August 25, 2005 7:01 PM To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx Subject: RE: [xsl] Transform XML to XML Mike, 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 <xsl:template match="secret"/> 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.... :-> 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.... 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Transform XML to XML, Michael Kay | Thread | Re: [xsl] Transform XML to XML, David Carlisle |
RE: [xsl] Transform XML to XML, Wendell Piez | Date | [xsl] Converting from datetime in m, Vishwajit Pantvaidya |
Month |