RE: Problems with XSL, XML code

["Evan Lenz" <elenz at xyzfind dot com>]

>(What are you, an editor or something?:)

I'm more of a random editor, lurking around.  I could pounce at any time ;)


>I was trying mainly to nudge the original poster in the right direction; he
was
>too far away from solving the nuances.

Yes, I can see that he has a little ways to go.  I believe that with XSLT,
you unfortunately almost have to plunge beginners into the "nuances" if
they'll have any chance of getting expected results.  This was one of my
issues when first learning it.  ("Why did that show up there?!  I didn't
tell it to copy that text!")  I believe that, while some people might give
up on reading a lengthy or complex explanation, most will stick with it as
best as they can.  And if what you've said is true, you've done them a
service.  They may not get it all the first time, but they do need that
first time.  I try to write in such a way that unanswered questions at the
end of the first reading can be answered upon a second or third closer
reading.  Either way, later on when they come back to the same issue, it
won't be for the first time.  I don't like spoon-fed teaching.  Throw the
meat and potatoes at them now and see how they can cope.  They're likely not
going to get injured.

I've stopped believing that XSLT can reliably be used in a simple way
without really knowing how it works.  As someone else mentioned on this
list, Kay's book title seems more appropriate to me than when I first picked
the book up.  XSLT is a programming language.  Yes, it's declarative and
domain-specific, but it is a programming language.  I was quite skeptical of
it originally, but I've come to love it.  And I've been thrilled with how it
has been taking off, despite all the naysayers.  Go XSLT!

Evan Lenz
elenz@xyzfind.com
http://www.xyzfind.com
XYZFind, the search engine *designed* for XML
Download our free beta software: http://www.xyzfind.com/beta


-----Original Message-----
From: owner-xsl-list@mulberrytech.com
[mailto:owner-xsl-list@mulberrytech.com]On Behalf Of John E. Simpson
Sent: Tuesday, October 03, 2000 12:25 PM
To: xsl-list@mulberrytech.com
Subject: RE: Problems with XSL, XML code


At 10:36 AM 10/03/2000 -0700, Evan Lenz wrote:
>Good explanation, John.  Maybe I could make just two corrections:

Thanks for those, Evan. (What are you, an editor or something?:) I was
trying mainly to nudge the original poster in the right direction; he was
too far away from solving the nuances.

>1. Why the default namespace?  That's not necessary; literal result
elements
>don't have to be in a namespace.

Right. I think I said "you must" or "you need" [i.e., to include the
default namespace declaration], which is putting it too strongly. For my
own taste, I always prefer to include it. No loose ends. :)

>2. If you remove HORA from the template rule's match pattern, the <HORA>
>child will still be processed by <xsl:apply-templates/>, which processes
>each child (elements, text, processing instructions, and comments) of the
>current node.  In this case, the children consist only of elements (and
>whitespace text nodes which don't cause any important difference as will
>become clear).  If a template rule is not found that matches a given child,
>then the built-in template rule for that node type is used.  In the case of
>an element, the built-in rule is to simply apply templates to its children.
><HORA>'s child consists of a text node.  Since there are no explicit
>template rules matching text nodes, the built-in rule for text nodes will
be
>applied, which is to copy the text to the result tree.  Thus, you would end
>up copying "10:08", etc. to the result tree.

Right again. Thanks!

==========================================================
John E. Simpson               | "Curiosity killed the cat,
http://www.flixml.org         | but for a while I was a
XML Q&A: http://www.xml.com   | suspect." (Steven Wright)


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list