Hi Michael --
"It could even select duplicates." Yes!! That's exactly what it's doing. At
the end of my document, if the last set of container elements contains any with
the same type, it reads them as unique types. So this is the last set of
containers:
<did>
<unittitle>Files</unittitle>
<container id="cid172002" type="Box"
label="Text">8</container>
<container id="cid172001" type="Box" label="Mixed
materials">19</container>
</did>
And it's evaluating both of those type="Box" as unique even though they're not.
If I understand correctly, this is because it's not looking at sibling
containers but rather only at later non-sibling containers, yes? And since
it's the end of the document there are no non-sibling containers below it in
the tree, hence nothing to compare to, hence they all appear to be unique?
What's the best way to fix this?
Michele
-----Original Message-----
From: Michael Kay [mailto:mike(_at_)saxonica(_dot_)com]
Sent: Thursday, April 26, 2012 1:19 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] Help parsing a node
On 26/04/2012 16:51, Michele R Combs wrote:
Hi all --
Can someone translate this into plain English for me?
<xsl:variable name="uniqueTypes"
select="ead/archdesc/dsc/descendant::*/container[not(@type=following::
*/container/@type)]/@type" />
Roughly, it selects all the @type attributes provided there is no @type
attribute later in the document with the same value.
And it does this very inefficiently (n*2 performance where n is the document
size) - it can be done much more efficiently using keys.
It also doesn't do quite what I said. Assuming it's used with "/" as the
context item, It's actually looking for all @type attributes whose path is
/ead/archdesc/dsc//container, provided they aren't the same as a following
@type attribute whose path is //container. If there are @type attributes that
match the first path and not the second, that could lead to some strange
effects.
It could even select duplicates. If there happens to be a structure like
this:
<container type="x">
<container type="x"/>
</container>
then both type attributes will be selected, because the second is not
"following" the first.
Michael Kay
Saxonica
What exactly will this select? And (since it starts with the root node) will
it select the exact same thing no matter where it's used?
I thought I knew but it isn't behaving at all the way I expected.
Thanks --
Michele
+++++++++++++++
Michele Combs
Lead Archivist
Special Collections Research Center
Syracuse University
315-443-2081
mrrothen(_at_)syr(_dot_)edu
scrc.syr.edu
library-blog.syr.edu/scrc
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--