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