2025 August 12: OAC's site performance has been stabilized; we are continuing to closely monitor the site. Please see our status page for more information.
Aeon display issue impacting newly submitted or resubmitted EAD finding aids in OAC
In some Aeon implementations, new EAD XML submissions to OAC (including both new and updated finding aid submissions) are not fully rendering as expected. This page summarizes the issue currently observed, as well as background information on the OAC-to-Aeon integration.
Summary of the Aeon display issue
The Aeon display issue is limited to newly submitted EAD finding aids (including any updated EAD file submissions) since the OAC launch in late July. We have not observed any impact on EAD finding aids that were migrated from the legacy OAC system to the new platform.
For impacted Aeon implementations, the display issue includes the absence of checkboxes beside the container list information and/or box/folder headings in the Aeon display.
Example from Hoover Institution
How the Aeon integration works
With the OAC-to-Aeon integration, we are passing through the source EAD XML file (submitted by contributors for OAC publication) to your library’s Aeon server, which is hosted by Atlas Systems.
Each Aeon instance then applies a stylesheet that has been customized by Atlas Systems, to render and display that EAD XML file in Aeon.
What changed with the OAC launch in July 2025
The old OAC system modified the submitted EAD XML files in order to index and display them in the legacy platform; these modified versions were passed through to the Aeon request interface. In order to do so, the older OAC system added CDL-specific URLs to the <eadid> tag, and also added CDL-specific identifiers to <c0#> Component tags. It also removed XML namespace declarations from the opening <ead> tag (and occurrences of the namespace headings in tags such as <extref>). This procedure resulted in technically invalid EAD files.
As new EAD XML files are submitted, the new OAC system does not modify the submission files, and retains the XML namespace declarations. OAC is now relaying the submitted files through to the Aeon request system, without modifications. This ensures that the submitted EAD files remain valid, and reflects the as-is “version of record.”
Some Aeon instances have customized stylesheets which render these finding aids correctly, whereas others fail to render the finding aids if there are XML namespaces declarations in the files.
Identification of the issue and current investigations
The Hoover Institution initially reported this issue following the launch of the new OAC system, and subsequently opened a ticket with Atlas Systems to investigate why the newly-submitted EADs were not rendering correctly in Aeon. We have also independently conducted tests with a sample of ArchivesSpace-generated EAD files, to view the results in Aeon – and have identified the XML namespace declarations in the submission files are the likely source of the display issue.
We are in contact with Atlas Systems to explore options to update the stylesheets so that they are more durable. In parallel, we are also investigating changes we can make to our submission process to address the problem.
In light of this situation, we request your assistance with the following:
For any newly-submitted or resubmitted EAD file (published since the launch of the new OAC system), review the finding aid display within your Aeon instance, to identify whether the data is rendering correctly. Please contact us to let us know whether (or not) there is an issue with the rendering of new findings aids in Aeon.
For any new EAD submissions that do not render correctly in Aeon, we have identified a temporary workaround that involves making two modifications to the EAD file:
1) Removing namespace declarations from the <ead> tag. Below is an example of EAD encoding generated from ArchivesSpace:
2) Removing any occurrence of the namespace headings, which may be pre-pended to data within tags. This can be done through a search-and-replace – particularly removing instances of xlink: and xsi:, in the case of ArchivesSpace EAD encoding:
If you would like us to make these two modifications for you, please contact us – we can modify sample EAD files and share the results for testing. If the results are satisfactory, we can make these changes to all EAD finding aids submitted since the new OAC system launched as well as for any future submissions, until we’ve implemented a solution in coordination with Atlas Systems.
Please contact us if you have any questions in the meantime. We will be in touch as soon as possible with updates on a resolution to this issue, based on our investigation with Atlas Systems.
In some Aeon implementations, new EAD XML submissions to OAC (including both new and updated finding aid submissions) are not fully rendering as expected. This page summarizes the issue currently observed, as well as background information on the OAC-to-Aeon integration.
Summary of the Aeon display issue
The Aeon display issue is limited to newly submitted EAD finding aids (including any updated EAD file submissions) since the OAC launch in late July. We have not observed any impact on EAD finding aids that were migrated from the legacy OAC system to the new platform.
For impacted Aeon implementations, the display issue includes the absence of checkboxes beside the container list information and/or box/folder headings in the Aeon display.
Example from Hoover Institution
How the Aeon integration works
With the OAC-to-Aeon integration, we are passing through the source EAD XML file (submitted by contributors for OAC publication) to your library’s Aeon server, which is hosted by Atlas Systems.
The “Request Items” link that appears in OAC finding aids relays a URL that appends a link to the source EAD XML file (e.g., https://hoover.aeon.atlas-sys.com/aeon.dll?Action=10&Form=31&Value=https%3A%2F%2Fcinco-prd.s3.amazonaws.com%2Fmedia%2Fead%2FXX723.xml).
Each Aeon instance then applies a stylesheet that has been customized by Atlas Systems, to render and display that EAD XML file in Aeon.
What changed with the OAC launch in July 2025
The old OAC system modified the submitted EAD XML files in order to index and display them in the legacy platform; these modified versions were passed through to the Aeon request interface. In order to do so, the older OAC system added CDL-specific URLs to the <eadid> tag, and also added CDL-specific identifiers to <c0#> Component tags. It also removed XML namespace declarations from the opening <ead> tag (and occurrences of the namespace headings in tags such as <extref>). This procedure resulted in technically invalid EAD files.
As new EAD XML files are submitted, the new OAC system does not modify the submission files, and retains the XML namespace declarations. OAC is now relaying the submitted files through to the Aeon request system, without modifications. This ensures that the submitted EAD files remain valid, and reflects the as-is “version of record.”
Some Aeon instances have customized stylesheets which render these finding aids correctly, whereas others fail to render the finding aids if there are XML namespaces declarations in the files.
Identification of the issue and current investigations
The Hoover Institution initially reported this issue following the launch of the new OAC system, and subsequently opened a ticket with Atlas Systems to investigate why the newly-submitted EADs were not rendering correctly in Aeon. We have also independently conducted tests with a sample of ArchivesSpace-generated EAD files, to view the results in Aeon – and have identified the XML namespace declarations in the submission files are the likely source of the display issue.
We are in contact with Atlas Systems to explore options to update the stylesheets so that they are more durable. In parallel, we are also investigating changes we can make to our submission process to address the problem.
In light of this situation, we request your assistance with the following:
1) Removing namespace declarations from the <ead> tag. Below is an example of EAD encoding generated from ArchivesSpace:
Example encoding before editing:
<ead xmlns="urn:isbn:1-931666-22-9" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:isbn:1-931666-22-9 http://www.loc.gov/ead/ead.xsd">
Example encoding after editing:
<ead>
2) Removing any occurrence of the namespace headings, which may be pre-pended to data within tags. This can be done through a search-and-replace – particularly removing instances of xlink: and xsi:, in the case of ArchivesSpace EAD encoding:
Example encoding before editing:
<extptr xlink:title="http://www.hoover.org/library-and-archives" xlink:type="simple" xlink:show="new" xlink:href="http://www.hoover.org/library-and-archives"/>
Example encoding after editing:
<extptr title="http://www.hoover.org/library-and-archives" type="simple" show="new" href="http://www.hoover.org/library-and-archives"/>
If you would like us to make these two modifications for you, please contact us – we can modify sample EAD files and share the results for testing. If the results are satisfactory, we can make these changes to all EAD finding aids submitted since the new OAC system launched as well as for any future submissions, until we’ve implemented a solution in coordination with Atlas Systems.
Please contact us if you have any questions in the meantime. We will be in touch as soon as possible with updates on a resolution to this issue, based on our investigation with Atlas Systems.
0 Votes
0 Comments
Login or Sign up to post a comment