Terry,



The links Ken posted are a big help, but as you can see this is an 
issue of interest to the experts as well as important to the 
newcomer. So much of what he's pointed to you may find to be a bit 
over your head while you're first getting into it. (Then as you have 
an "aha" or two, things will become much easier.)



To supplement those commentaries, let me provide a short version of 
what the processor does:



1. Match the context node with the template that has the best match.

2. Execute the template by appending the template's content to the 
result tree. While doing so, follow xsl instructions found in the 
template, appending their results to the tree where where the 
template has the instruction.

3. Instructions may include xsl:apply-templates, which identifies new 
nodes to which templates should be applied. Return to step 1. with 
each of those new nodes (which is now the "context node"), continuing 
until no nodes are selected.



To fill this picture out, understand that:

* Processing starts at the top, so the first thing that happens is 
that the root node is matched and its matching template is applied

* By default, when a template says xsl:apply-templates, the child 
nodes of the context node are selected. This can be overridden with 
an explicit "select" on the xsl:apply-templates instruction. But many 
simple stylesheets may never have to do this, since ordinarily we are 
happy to select the children, since cumulatively this results in all 
nodes in the tree being matched, in a depth-first traversal (which 
happens to correspond to the "document order" of the nodes)

* When a template is not given explicitly to match a node, the 
processor will provide a built-in (default) template. Since the 
built-in template for element nodes says to apply templates to its 
children, *by themselves* (that is, with no extra effort from the 
programmer) all elements in the tree will be matched and their 
templates applied. (But by default, attributes are *not* selected and 
thus their templates are not matched.)

* The built-in template for text nodes says to copy its value to the 
result, so *by themselves* (again, no programmer intervention) the 
values of the text nodes in your source document will be copied to your result.

* There are rules to establish which template has the "best match" in 
any given situation. Usually, elements are matched by name.



As background, then, you need also to master the terminology relating 
to the data model, including "node"; "element", "attribute" and "text 
node" (those are kinds of nodes), "child", "sibling" etc.



From there you can proceed to learn XPath, the expression language 
that allows you to address nodes in the tree, given any node as your 
starting context. XPath is the language used in "select" attributes 
and in much else.



In practice, most programmers start by taking a stylesheet that works 
and hacking its XPaths and so forth, observing the changes, and 
hammering on it until it works, even if they don't understand why. 
Consequently, in some circles XSLT has won a reputation for being 
difficult and mysterious. Yet if you understand the sequence of steps 
1-3 above, and see how the "recursive descent" they provide for allow 
you to control how your result is built, "steering" it rather than 
generating its motive power, XSLT turns out to be an elegant and 
easily manageable language, at least for most of the document 
transformation tasks for which it was designed.



We will continue our efforts to make this simple and useful approach 
to document transformation both intelligible to the newcomer, and 
easy to discover on the net ... accordingly, please don't hesitate to 
speak up with any further questions, either to clarify what's here or 
to fill in missing pieces.



Finally, let me commend you on your can-do attitude. No one ever 
became more knowledgeable by hiding what they had to learn. XSLT is 
definitely one of those things where a little extra to get things 
right up front will pay off big time down the line.



Cheers,
Wendell

At 12:36 PM 3/1/2006, you wrote:
Thanks for the advice, lessons, and links. You folks have been most 
helpful. I don't mind showing my ignorance as it is one of the only 
ways to correct faulty thinking. From your responses I can see that 
I have some reading and thinking to do.




======================================================================
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
======================================================================