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' ]"/>
key('element-by-id',@rid)
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.
Probably,
Richard.
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
richard(_dot_)kerry(_at_)atos(_dot_)net
uk.atos.net
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(_at_)mulberrytech(_dot_)com]
Sent: 22 August 2012 17:15
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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:
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(_at_)mulberrytech(_dot_)com
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(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
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(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--