[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

keys: repeated nodes from same key value

Subject: keys: repeated nodes from same key value
From: Jeni Tennison <jeni.tennison@xxxxxxxxxxxxxxxx>
Date: Thu, 10 Aug 2000 11:24:20 +0100
xsl repeated nodes
Hi,

The question:  Should key() return repeated nodes from the same (string)
key value?

A bit of context:  I'm working on an application that takes interview
protocols and marks them up based on the definition of concepts/attributes
etc. in a 'knowledge model'.  The application takes partially marked-up
protocols and turns them into HTML containing a number of snippets like
(content changed to protect the innocent):

<p id="p-134" class="keng">
  Tell me about your <a href="chicken.html">chicken</a>
  <a href="farm.html">farm</a>.
</p>
<p id="p-135" class="expert">
  I run a <a href="chicken.html">chicken</a> <a href="farm.html">farm</a>.
  It had lots of <a href="chicken.html">chickens</a> on it until they
  escaped.
</p>

I then go over these protocols when generating pages for the concepts
themselves to give a table showing where in the protocols the concepts have
been mentioned.  To identify the snippets of interest, I use a key:

<xsl:key name="paras" match="html:*[@id][html:a]" use="html:a/@href" />

I then use key() to get these snippets:

<xsl:variable name="concept-id" select="@id" />
<xsl:for-each select="key('paras', concat($concept-id, '.html'))">
  ...
</xsl:for-each>

The problem:  When I get the node set using key() [in SAXON 5.4.1], I get
repeats of the snippets that contain more than one reference to the same
concept.  For example, if I use:

key('paras', 'chicken.html')

I get:

p-134
p-135
p-135

I kind of expected key() to produce a 'set' in the classical way: no
repeated nodes.  I expected the keys to be:

node		key name		key value
p-134		paras			chicken.html
p-134		paras			farm.html
p-135		paras			chicken.html
p-135		paras			farm.html

But it seems there's another key as well, a repeat of:

p-135		paras			chicken.html

Looking at the XSLT Recommendation, I can't see anything that explicitly
addresses this situation.  It does say (my emphasis):

<blockquote uri="http://www.w3.org/TR/xslt#key">
Thus, a node x has a key with name y and value z if **and only if** there
is an xsl:key element such that:
 * x matches the pattern specified in the match attribute of the xsl:key
element;
 * the value of the name attribute of the xsl:key element is equal to y; and
 * when the expression specified in the use attribute of the xsl:key
element is evaluated with x as the current node and with a node list
containing just x as the current node list resulting in an object u, then
either z is equal to the result of converting u to a string as if by a call
to the string function, or u is a node-set and z is equal to the
string-value of one **or more** of the nodes in u.
</blockquote>

The 'if and only if' and 'one or more' make me think there shouldn't be
repeated keys, but I'm loath to say that SAXON has a bug in it in case Mike
thinks I want a fight ;)  Does anyone else have an opinion?

Cheers,

Jeni

Dr Jeni Tennison
Epistemics Ltd, Strelley Hall, Nottingham, NG8 6PE
Telephone 0115 9061301 ? Fax 0115 9061304 ? Email
jeni.tennison@xxxxxxxxxxxxxxxx



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.