Christian,
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).
Mark Custer
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)
</xsl:for-each-group>
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:template match="ead:did">
<xsl:for-each select="ead:container[generate-id() = generate-id(key('container-groups', @id)[1])]">
<xsl:apply-templates/>
<xsl:for-each select="key('container-groups', @id)">
<xsl:apply-templates select="@parent/.." />
<xsl:if test="position() != last()">
<xsl:text>, </xsl:text>
</xsl:if>
</xsl:for-each>
<xsl:if test="position() != last()">
<br />
</xsl:if>
</xsl:for-each>
</xsl:template>
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.
________________________________
From: Encoded Archival Description List [[log in to unmask]] on behalf of Christian Dupont [[log in to unmask]]
Sent: Sunday, February 03, 2013 8:08 AM
To: [log in to unmask]
Subject: Re: Multiple container elements in a single component?
Mike,
Thanks very, very much for attacking the actual XSLT logic. This is more than I had hoped for from my posting, but I’m delighted to be able to pass this along to our developers, whom I’m sure will be grateful for your guidance.
Since you dug right into the coding, shall I assume that you consider the practice of grouping multiple container elements under a single component to be an acceptable one from an EAD encoding standpoint?
Do others on the list have comments about the practice? And for those of you involved with the development of EAD 3.0, do you envision this sort of practice being allowed or discouraged going forward?
Thanks again,
Christian
From: Mike Ferrando [mailto:[log in to unmask]]
Sent: Saturday, February 02, 2013 1:41 PM
To: Encoded Archival Description List
Cc: Christian Dupont
Subject: Re: Multiple container elements in a single component?
Christian,
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,
-mike
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:exslt="http://exslt.org/common"
xmlns:javaLangString="java:java.lang.String"
extension-element-prefixes="exslt"
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"/>
</xsl:element>
</xsl:variable>
<!-- ===== Global Copy ===== -->
<xsl:template match="* | @* | text() | comment() | processing-instruction()" mode="global_copy">
<xsl:copy>
<xsl:apply-templates select="@* | * | text() | comment() | processing-instruction()"
mode="global_copy"/>
</xsl:copy>
</xsl:template>
<!-- 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>
<xsl:template match="*" mode="containerParentBuild">
<xsl:value-of select="concat(@type, ' ', normalize-space(.), ',')"/>
</xsl:template>
________________________________
From: Christian Dupont <[log in to unmask]<mailto:[log in to unmask]>>
To: [log in to unmask]<mailto:[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">
<did>
<unittitle>TITLE</unittitle>
<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>
</did>
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:
TITLE
[ ] 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:
http://listserv.loc.gov/cgi-bin/wa?A2=ind0606&L=EAD&P=R5146&I=-3
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">
<did>
<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>
<unitid>2/1917</unitid>
<container id="cid125006" type="Reel" label="Microform">MSS Microfilm
0159</container>
<container id="cid125005" type="Reel" label="Microform">AU Microfilm
78-326</container>
<container id="cid125004" type="Box" label="Text (C3026724)"
>C3026724</container>
<unitdate normal="1917/1917">1917</unitdate>
</did>
</c01>
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
_________________________________________________________
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
[log in to unmask]<mailto:[log in to unmask]>
http://www.atlas-sys.com/
http://independent.academia.edu/ChristianDupont
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.
