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

RE: [xsl] Help parsing a node


Subject: RE: [xsl] Help parsing a node
From: Michele R Combs <mrrothen@xxxxxxx>
Date: Thu, 26 Apr 2012 17:28:29 +0000

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@xxxxxxxxxxxx]
Sent: Thursday, April 26, 2012 1:19 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxx
> scrc.syr.edu
> library-blog.syr.edu/scrc


Current Thread