Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xsl] returning nodes which have a specific child

From: Wendell Piez <wapiez@------------.--->
To: xsl-list@-----.------------.---
Date: 7/2/2009 4:16:00 PM
Hi,

At 04:53 AM 7/2/2009, Michael Ludwig wrote:
>I have an editor macro that produces the stylesheet skeleton plus
>identity template, as this is almost always the right starting point
>for a new stylesheet.

Michael probably knows that this is overstating it. It is true for 
users who are most commonly writing a certain class of stylesheet -- 
one designed to modify the input in some particulars but leave it 
unchanged in others.

In my work, which ranges all over the place, a significant but not 
high proportion of stylesheets fall into this category -- maybe 
10-15%? The best counter-example would probably be a stylesheet 
designed to convert data into a presentational format, such as HTML or XSL-FO.

>Note that XSLT has built-in template rules that basically lose the
>markup and display the text only. Most of the time you'll want to
>supplant these by the identity template. Some people even think that
>the identity template should have been the built-in template rule.

And some don't. Some (like myself), think that might be a useful 
option to allow -- at the cost, perhaps, of making XSLT even more 
mysterious to beginners. :-)

>Bottom line, start with the identity template.

-- when you want your result to replicate your source document (with 
modifications as indicated by the other templates in your stylesheet).

As for why things work the way they do -- the fundamentals are 
simple, but obscure, deep, and profound in their implications:

1. The source data and results are represented in and by XSLT as a 
tree structure, consisting of nodes (element, text, attributes etc.) 
in a hierarchical arrangement. Tags, both in XML source and result 
and in the XSLT stylesheet itself, are merely a lexical 
representation of this tree structure. Learn to parse the tags and 
see the tree, since that's what an XSLT processor does.

2. A stylesheet works by matching templates to nodes. Templates 
contain fragments of the result tree, plus XSLT instructions which 
the processor then acts on. The most important of these instructions, 
xsl:apply-templates, works by selecting more nodes in the tree 
(typically but not necessarily children of the node being matched) 
for further processing by matching templates to them. If no template 
is explicitly provided that matches a particular node to be 
processed, the XSLT processor provides a built-in default, so no node 
is ever without a template to match it.

By default and by design, this allows for a recursive descent of the 
input tree by the processor, as each node in the tree matches a 
template which then selects the node's children to be processed by 
templates. This can be the same template, matching a different 
"current node" (as in the identity template, which copies a node and 
then applies templates to its children, which may then be matched by 
the identity template itself), or it can be a different template 
matching nodes of a different name or type, which contains different 
result fragments and/or instructions. Template matching thus provides 
implicitly for a dynamic dispatching mechanism, which helps XSLT be 
flexible, powerful and concise (despite the XML syntax).

The logic of XSLT can thus be distilled into two general classes:

* Mapping nodes in the input to the results they correspond to, as 
represented by (a) the source node(s) matched by templates and (b) 
the result nodes thereby generated;

* Including instructions that determine how the input tree will be 
traversed and what will happen, besides simply generating nodes for 
the result, during the traversal. These includes conditional 
statements, generating specialized output (numbers, generated text, 
etc.), binding variables, passing parameters between templates, and so forth.

Add XPath, which is how you identify (and to some extent process) 
nodes in the source tree, and you have XSLT.

Cheers,
Wendell



======================================================================
Wendell Piez                            mailto:wapiez@m...
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@l...>
--~--



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent