Print

Print
Christian,
One thing I had in the back of my mind for using container/@parent was the intended usage in the dsc.
My understanding is that the container/@parent is going to appear only once, while the "children" containers could appear many time.
The container/@parent could appear in one did, and then need to be called from a completely other did element.
So, my thought was it would be good to have a global node set rather than doing the grouping a lower level template.
Seems like alot of code to maintain, why not just do box/folder and take the rest of the day off?
We don't use container/@parent because it makes it difficult to code, and when dsc is big, it is hard to know where the info is when working in a did without the parent.
See ya,
-mike

From: Christian Dupont <[log in to unmask]>
To: [log in to unmask]
Sent: Sunday, February 3, 2013 8:08 AM
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]>
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">
<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:
 
 
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
 
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.