[Archivesspace_Users_Group] RC candidates and v1.5.0 not creating tags in EAD export

Mon Jul 25 12:10:45 EDT 2016

Hi Mark,

Thanks for looking into it. So, if I may paraphrase you, if an organization upgrades to 1.5, and they have 500 resource records that they migrated a year ago from AT (into, say, 1.4.2), all of their records with ampersands that previously exported just fine will now have trouble exporting as valid EAD. But if they create a NEW resource record in 1.5 from scratch, or import (not migrate) a new EAD in, loaded with ampersands, it will export correctly with tags. Is this correct?

On Friday, I created a bug report for this issue: https://archivesspace.atlassian.net/browse/AS-98

The language might need to be refined to address the full scope/details of the problem. Thanks for your input!

Laurel

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark
Sent: Monday, July 25, 2016 8:57 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] RC candidates and v1.5.0 not creating <p> tags in EAD export

Laurel, all:

Following up on this issue, I tried to replicate it in the newest version of ArchivesSpace, but I haven't had any luck (well, I uncovered a few other minor bugs, but nothing as problematic as the ones you reported).  Anyhow, here's the file that I uploaded for testing, which is in the GoneRepo repository: http://test.archivesspace.org/resources/151.

So, it appears that the problem is being caused by how previous importers (or migrators) handled the ampersands versus what the exporter expects now.  For example, this is text from one of our scope and content notes that was imported from AT, I think:  "individual cards measuring 300 by 360mm & captioned." (and that ampersand is not encoded as "&", which is how it is imported in versions 1.5, and possibly earlier).  That ampersand no longer exports okay in version 1.5, but it exports fine in version 1.4.2  Ideally, the importers and exporters would have one way to handle XML data but it seems like there have been different ways to do that in the past.  I've no clue how best to handle that with the ASpace architecture, aside to say that it should be consistent in all aspects of the application.

Mark

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark
Sent: Thursday, 21 July, 2016 5:12 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] RC candidates and v1.5.0 not creating <p> tags in EAD export

Hi, Laurel:

What timing!  I remember Brad mentioning this issue before, but I had completely forgotten about it until seeing your message about the exact same time that I was testing a new automatic EAD export service for ArchivesSpace.  Right before I read your message, I was wondering why so many of our files failed to produce valid EAD files.  The main problem, it turns out, is the bug that's not putting paragraph elements around text that has ampersands.   But this only happens in the 1.5 versions.  I can confirm that in version 1.4.2 this problem doesn't exist (that's our production version), but that it does exist in 1.5 (that's our test version).  I haven't tested anything with the altformavail/extref issues, though.

I haven't looked into the exporter code too much yet, but the history of updates to the EAD exporter file should provide clues (to the developers, at least):  https://github.com/archivesspace/archivesspace/commits/master/backend/app/exporters/serializers/ead.rb<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_archivesspace_archivesspace_commits_master_backend_app_exporters_serializers_ead.rb&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=dURyN9dLHMTStr2wd50oCQjXJwVfE97zD-TWh4fTqus&s=bBnV5XYygTQhUg2JF6pLIPSbdbdXi-bu1T_qRF2ycdo&e=>

Mark

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of McPhee, Laurel
Sent: Thursday, 21 July, 2016 3:45 PM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] RC candidates and v1.5.0 not creating <p> tags in EAD export

Hello,

UC San Diego discovered an issue in R2 that we informally reported to B. Westbrook in early June. The bug is this: note fields containing either an & entity ref and/or an <extref> tag do not get properly wrapped in a tag upon EAD export. For example, all of our <prefercite> notes contain the term "Special Collections & Archives", and because of the presence of the ampersand in the note, do not get wrapped. Similarly, if a bioghist note has an & somewhere in it, none of the paragraphs get wrapped in a tag, leaving us with giant block of text. And last, in altformavail, where we record the existence of digital versions of our collections with a link, the existence of an <extref> causes the whole note to not get wrapped in a tag when we export the EAD.

This issue breaks our local scripts and also prevents validation on the Online Archive of California. At the time, I didn't create a JIRA ticket, because we were told the problem was being worked on...but now I'm going through the steps to create the ticket. Is there any feedback/observations on this in the member community before I do so? It's happening in v1.5.0, which we tested this morning. Thanks!

Laurel McPhee

Supervisory Archivist, Special Collections & Archives Program

UC San Diego Library | * 858-534-5619 | * lmcphee at ucsd.edu<mailto:lmcphee at ucsd.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160725/4a82a297/attachment.html>