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