I meant to answer your question below about the AT in the summary reply and thanks I just posted.
Yes, you divined correctly that the first example was taken from code generated by the AT (though I edited the actual content, the id elements probably gave it away). That point acknowledged, your caution about the problems with exporting and re-importing EADs with such structures is well taken. I don’t think our client will need to re-import their exported AT EADs, but I’ll pass along your advice to be sure.
Also, I am grateful for your demonstrating the simplicity and elegance of XSLT 2.0 vs. 1.0. Even if we can take advantage of the former, at least at this juncture, it is still instructive. We will, however, have to take account of namespaces, so your calling attention to that along with Mike is immediately helpful.
Thanks once again,
From: Encoded Archival Description List [mailto:[log in to unmask]]
On Behalf Of Custer, Mark
Sent: Sunday, February 03, 2013 11:49 AM
To: [log in to unmask]
Subject: Re: Multiple container elements in a single component?
Is your first example also from Archivists' Toolkit? I've only worked with container elements like that when the EAD has been derived from the AT, but there is a similar example in the EAD Tag Library. Regardless, though, you're right that addressing it won't be much of a technical problem. It's just a matter of grouping the container elements based on the values in their id and parent attributes (see the bottom of this email for 2 more examples).
That said, if this example is from the AT, and if your client re-imports that same EAD into the AT, I don't think that they will wind up with the exact same three instances. I seem to remember trying to export and re-import a component in the AT that had 14 instances (that's right!), but only the first 3 went back in, and those three were combined into a single instance. I'd have to test that out again, though, to be certain. Nevertheless, I don't know how ArchivesSpace plans to handle this since I don't think that you can export EAD from its current version just yet. Still, I would guess that the EAD might look similar to what the AT produces.
As for your three question, here's my take:
"are there any reasons for avoiding this type of usage?" Not from my perspective.
"Is there any sense whether EAD 3.0 will allow or disallow it?" My sense is that it will continue to allow it. And, regarding your second example, I think that EAD 3.0 will make such cases even more clear, since the "container" and "dao" elements will be children of a new element, named something like "formsAvailable."
"Does anyone have any other recommendations on how to use EAD to address these types of situations?" I don't, but I guess one could encode separate levels of description in this case. However, I think that the current solution is perfectly fine (unless there were different descriptive notes, or anything else, that needed to be associated with any of these instances in a direct fashion).
P.S. The XSLT 2.0 solution, which is easiest to understand and maintain, can be accomplished like so:
<xsl:for-each-group select="ead:container" group-by="@id|@parent">
.... whatever you want here ... (http://www.w3.org/TR/xslt20/#xsl-for-each-group for more information)
Mike already illustrated one example of how to group these using XSLT 1.0. Here's another, which uses keys (since Mike mentioned those) and the famous Meunchian method (http://www.jenitennison.com/xslt/grouping/muenchian.html). Since this one is more difficult to follow, though, I wrote an example to test, which I include below:
<xsl:key name="container-groups" match="ead:container" use="@id |@parent" />
<xsl:for-each select="ead:container[generate-id() = generate-id(key('container-groups', @id))]">
<xsl:for-each select="key('container-groups', @id)">
<xsl:apply-templates select="@parent/.." />
<xsl:if test="position() != last()">
<xsl:if test="position() != last()">
Of course, both of these examples assume that the source is in the EAD namespace, and that the style sheet declares the "ead" namespace prefix.