Ok, well this looks like a good example for keys.
But when I got a keys example to work, I could not call my key inside a node set.
So, I gave up keys.
More than welcome to be schooled in my ignorance.

So, here is how I would do it. XSLT 1.0

1. At the top of the stylesheet you need to create a node set of all container/@parent elements.
2. surppress the container/@parent elements in the normal transform.
3. call the node-set every time you have a container[not(@parent)] element to see if there is a parent node that has a matching id value.
4. use apply templates to to render this value from the node set which will default to giving you the complete with punctuation if there is a match.

Note: I have used *[local-name()=''] because I don't know what namespaces may be present.
Note: I am using XSLT 1.0
Note: you may need to use the exslt extension in your xsl:stylesheet node.
Note: you can add the br after the container build, but I didn't put that into the template.

Hope this helps,

    exclude-result-prefixes="exslt javaLangString"

<xsl:variable name="containerParents">
<xsl:element name="subset">
<xsl:apply-templates select="//*[not(parent::*]/descendant::*[local-name()='dsc']/descendant::*[local-name()='container' and string-length(@parent)!=0]" mode="global_copy"/>

    <!-- ===== Global Copy ===== -->
    <xsl:template match="* | @* | text() | comment() | processing-instruction()" mode="global_copy">
            <xsl:apply-templates select="@* | * | text() | comment() | processing-instruction()"

<!-- don't transform container elements that are parents in the normal dsc transform -->
<xsl:template match="container[@parent]"/>

<xsl:template match="container[not(@parent)]">
<xsl:variable name="ccId" select="@id"/>
<xsl:apply-templates select="node-set($containerParents)//*[not(parent::*)]/*[@parent=$ccId]" mode="containerParentBuild"/>
<xsl:value-of select="concat(@type, ' ', normalize-space(.))"/>

<xsl:template match="*" mode="containerParentBuild">
<xsl:value-of select="concat(@type, ' ', normalize-space(.), ',')"/>

From: Christian Dupont <[log in to unmask]>
To: [log in to unmask]
Sent: Friday, February 1, 2013 8:56 PM
Subject: Multiple container elements in a single component?

Greetings, everyone –
I’d like to tap your collective and expert advice on a question that has arisen in a conjunction with an XSLT project we’ve been working on for one of our clients.
Basically, we’re looking at modifying the XSLT stylesheet we use to control the display of an EAD-encoded finding aid in our Aeon software so that it that it can accommodate situations in which multiple container elements are contained within a single component element.
For example, here is the type of structure that we are being asked to accommodate:
<c02 id="123" level="file">
<container id="cid997" type="Text" label="Box">1</container>
<container parent=" cid997" type="Folder">A-B</container>
<container id=" cid998" type="Text" label="Box">1</container>
<container parent=" cid998" type="Folder">C-D</container>
<container id=" cid999" type="Maps" label="Box">2</container>
<container parent=" cid999" type="Folder">A-B</container>
Our current stylesheet displays a functional HTML checkbox to the left of the display of the first container element to facilitate an automated paging request, thus:
[ ] Box 1, Folder A-B; Box 1, Folder C-D; Box 2, Folder A-B
What our client would prefer, however, is a display like the following:
[ ] Box 1, Folder A-B
[ ] Box 1, Folder C-D
[ ] Box 2, Folder A-B
While we do not anticipate any particular technical challenges in making this accommodation, we’re wondering whether other institutions employ this type of encoding structure and whether the EAD community has any particular guidance on whether it desirable or not. In other words, were wondering whether we should plan to make whatever accommodation we devise a feature of our standard stylesheet.
The discussions of container and component elements in the EAD Tag Library do not appear to address this situation, although from what we can tell the EAD 2002 DTD and Schema allow it. We also have not found any relevant threads in the EAD list archives since EAD 2002 was introduced, except the following from Jodi Allison-Bunnell, which recognizes the need to have multiple containers in a series or sub-series, but seems to suggest that the containers numbers should be included as a range or series in a single container element:
In our client’s case, however, listing the containers in a single element won’t be practical since the ultimate purpose of the structure is to enable each container to be requested individually.
In the AT world, there has been some discussion of the efficacy of creating “multiple instances” to manage situations in which a microfilm or other physical surrogate version of a file might be kept by the repository, such as in this example, which was included in a message posted on May 30, 2012:
   <c01 id="ref2" level="file">
                    <unittitle>Clerk in charge of Accounts, Solomon Is. Submits H. Cr's A/c. for the
                        Solomon Islands for the month of October, 1916, 1917</unittitle>
                    <container id="cid125006" type="Reel" label="Microform">MSS Microfilm
                    <container id="cid125005" type="Reel" label="Microform">AU Microfilm
                    <container id="cid125004" type="Box" label="Text (C3026724)"
                    <unitdate normal="1917/1917">1917</unitdate>
Discussion on the AT list does not seem to have any reached any conclusions regarding the desirability or propriety of such structures.
And so I bring the question to this forum:  are there any reasons for avoiding this type of usage? Is there any sense whether EAD 3.0 will allow or disallow it? Does anyone have any other recommendations on how to use EAD to address these types of situations?
Thanks for your advice!
Christian Dupont, PhD, MLIS
Aeon Program Director
Atlas Systems - Library excellence through efficiency
office: 757-467-7872 x215     fax: 757-467-7875     mobile: 434-242-6096
Notice:  This e-mail message, including any attachments, is intended only for the named recipient(s) above and may contain confidential information.  If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message from your computer without making any copies or distributing it to any other person.  Thank you.