Yes, I'd definitely recommend XSLT 2! (although I'm sure there's an XSLT 1 solution available, if you're willing to put up with its verbosity).
I think that Yoann brought up another issue about the XPATH that I overlooked earlier, too (so, I don't think that variable was delivering distinct values with the use of the following axes, etc).
Thanks for summarizing, Michele. Once all is said and done, perhaps this would make for a good write-up in something like the Practical Technical Journal for Archives someday!
Mark
-----Original Message-----
From: Encoded Archival Description List [mailto:[log in to unmask]] On Behalf Of Joyce Chapman
Sent: Thursday, April 26, 2012 4:35 PM
To: [log in to unmask]
Subject: Re: Help parsing a node
Were you not able to do:
<xsl:variable name="uniqueTypes" select="distinct-values(//container/@type)" />
You definitely need the xpath 1.0 workaround?
On Thu, Apr 26, 2012 at 2:49 PM, Michele R Combs <[log in to unmask]> wrote:
> Thanks for all your feedback, everybody. It's becoming clearer what
> the problem is, so let me sum up.
>
>
>
> What (apparently) this <xsl:variable> is supposed to do is grab ONE of
> each container type that exists -- it needs to know how many there are
> up front, so it can allocate a column in the table for each one. So
> if my document has a hundred <container> elements but the only @type
> attributes are Box, Folder and Reel, the variable hunts through them
> all and ends up with three container types.
>
>
>
> Right now, it says this:
>
>
>
> <xsl:variable name="uniqueTypes"
> select="ead/archdesc/dsc/descendant::*/container[not(@type=following::*/container/@type)]/@type"
> />
>
>
>
> Right now, if I have more than one <container> with the same @type in
> the LAST c0#, e.g.:
>
>
>
> <container type="Folder">
>
> <container type="Folder">
>
>
>
> it interprets them as two different types, so the number of possible
> container types is incorrect, leading to surplus columns in the table.
> Now, I tried changing it to use preceding rather than following, like so:
>
>
>
> <xsl:variable name="uniqueTypes"
> select="ead/archdesc/dsc/descendant::*/container[not(@type=preceding::*/container/@type)]/@type"
> />
>
>
>
> And sure enough, in that case if I have more than one <container> with
> the same @type in the FIRST c0#, it show the same behavior: it
> interprets them as two different types, not as the same type.
>
>
>
> So I'm guessing that the <xsl:variable select string does not look at
> sibling <container>s in the same <did>, it only looks at containers
> above/below the current node? That would explain why if I use
> following::*/container/@type , it gets confused over containers in the
> LAST c0# (because there are no following containers to compare it to)
> and why if I use preceding::*/container/@type it gets confused over
> containers in the FIRST c0# (because there are no preceding containers to compare it to.
>
>
>
> So, options: Make it look at siblings as well? Exclude the last c0#
> from consideration? Something else?
>
>
>
> There may just not be an easy fix for this without tearing a lot more
> of the code apart...
>
>
>
> Michele
--
Joyce Chapman
Triangle Research Libraries Network
CB# 3926, Wilson Special Collections Library Chapel Hill, NC 27514-8890
Phone: (919) 962-1345
Email: [log in to unmask]
Website: www.trln.org/ccc
|