[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

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: "Kerry, Richard" <richard.kerry@xxxxxxxx>
Date: Thu, 23 Aug 2012 09:56:18 +0000

So it seems that the use of the key statement and function gives functionality
the same as can be got by using a predicate in a certain way.
It is presumably advised in some cases as an opportunity for the processor to
optimize the search.
In my case the data is probably not large enough for this optimization to make
much difference to the processing time.

><xsl:apply-templates select="key('p-by-id','p2')"/>
>applies a template to the p2 'p' element,

So the same as <xsl:apply-templates select="p[ @id = 'p2' ]"/>

><xsl:apply-templates select="key('p-by-id','np1')"/>
>applies a template to the np1 'p' element.

So the same as <xsl:apply-templates select="p[ @id = 'np1' ]"/>

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

something like "element[ @id = ./@rid ]"
   (assuming <xsl:key name="element-by-id" match="element" use="@id"/> and
that "element" is not a reserved word. )

It does sound like keys implicitly work using "=", though.  So there's no key
based equivalent to "element[ @id > ./@rid ]" ?

Having said all that, as you say, my requirement for RE matching does seem to
rule out use of keys.

I was going to ask (for academic interest really) what would happen if a key
had duplicate matches ?
(error at indexing time ?  return all the matching elements ?  return the
first ?)
You do say:
>* Keys can (and frequently do) retrieve more than one node at a time;
So I presume a sequence of all the matches would be returned in that case.
Likewise if the requested key was a sequence a sequence would be returned
assuming all distinct keys produced a separate match.


Richard Kerry
BNCS Engineer
T: +44 (0)20 82259063
M: +44 (0)7812 325518
Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ

This e-mail and the documents attached are confidential and intended solely
for the addressee; it may also be privileged. If you receive this e-mail in
error, please notify the sender immediately and destroy it. As its integrity
cannot be secured on the Internet, the Atos group liability cannot be
triggered for the message content. Although the sender endeavours to maintain
a computer virus-free network, the sender does not warrant that this
transmission is virus-free and will not be liable for any damages resulting
from any virus transmitted.

From: Wendell Piez [wapiez@xxxxxxxxxxxxxxxx]
Sent: 22 August 2012 17:15
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] Pattern Matching in XSl - find groups defined in one  Xml
in another Xml.

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:


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


<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


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

* 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