xsl-list
[Top] [All Lists]

RE: Transform XML to XML

2005-08-25 16:36:51
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(_at_)mulberrytech(_dot_)com] 
Sent: Thursday, August 25, 2005 7:01 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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(_at_)mulberrytech(_dot_)com
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
======================================================================


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



<Prev in Thread] Current Thread [Next in Thread>