Re: [xsl] Pattern Matching in XSl - find groups defined in one Xml in another Xml.

Subject: Re: [xsl] Pattern Matching in XSl - find groups defined in one Xml in another Xml.
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Wed, 22 Aug 2012 12:15:19 -0400
Dear Richard,

On 8/22/2012 9:30 AM, Kerry, Richard wrote:
Thanks for your comments. You've (inadvertently ?) answered one of
the questions I had in my mind, which was : Has Ken just missed a
detail of the requirements which can easily be altered to suit, or is
there something major that needs changing ? You've clearly suggested
that the former is the case - I shall have to spend some more time
understanding these implementations.  And yours.

Indeed. Having scanned the thread and being familiar with Ken's work over the years, I was pretty confident that he wasn't missing anything major. :-)


In particular I don't yet understand keys.  I've seen the term used
over the years and failed to understand what it really meant.  Until
now I 've never really needed to.

Keys are not necessary for your problem, but they are convenient for some variants of it -- and convenient in general.


They are also good exercise for the XSLT programmer's brain, and mastering them will open much more than just their common applications.

The mechanism is really quite simple:

Data:

  <p id="p1">Paragraph ...
    <note><p id="np1">Paragraph inside a note ...</p></note>
  ... </p>
  <p id="p2">Another paragraph ...</p>

XSLT:

<xsl:key name="p-by-id" match="p" use="@id"/>

then in a template

<xsl:apply-templates select="key('p-by-id','p2')"/>

applies a template to the p2 'p' element, while

<xsl:apply-templates select="key('p-by-id','np1')"/>

applies a template to the np1 'p' element.

Important to note:

* The nodes returned by the key are established by the match pattern on the key declaration. (In this case, the 'note' element will never be returned by the key since it doesn't match it.) But these nodes can be anywhere in the document.

* The second argument to the key() function gives the value(s) submitted to the function for retrieval using the key. What makes its use confusing to beginners, I think, is that this argument is almost never given as a literal (like 'p1' and 'np1' here) but rather as XPath to be evaluated. So

key('element-by-id',@rid)

retrieves nodes using the 'element-by-id' key by the value of the @rid attribute of the context node.

This means that in the usual case your brain has to perform two operations, one on top of the other: first, evaluate the XPath, and secondly, interpret what the value(s) returned by the XPath will get when submitted to the key.

With practice, this gets easier, especially since our brains seem to be quite good at "lazy evaluation" (which I'm convinced is a habit of good XSLTers).

* What, exactly, that key will return, we can't actually know without looking at its declaration -- although the name given to it might (if we are lucky) give a hint.

* Keys can (and frequently do) retrieve more than one node at a time; more than one value can also be submitted to a key at a time (as a node set in XSLT 1.0 and a sequence in XSLT 2.0). So they are capable of many-to-many matches.

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