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

RE: Help parsing a node

Subject: RE: Help parsing a node
From: Michele R Combs <mrrothen@xxxxxxx>
Date: Thu, 26 Apr 2012 17:28:29 +0000
RE:  Help parsing a node
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:  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

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.