<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri" size="2"><span style="font-size:11pt;">
<div>Lydia,</div>
<div> </div>
<div>In the EAD files that you attached, both have invalid XML characters in them (Unicode: 0x14). Those are easy to remove before re-importing in an XML editor like oXygen, but I'm curious how they got into ASpace in the first place? In any event, it's
possible that that's what's blocking your imports this time around, and if that's the issue, if you just fix on those issues, then the ASpace importer won't tell you about the next issue until it runs again. </div>
<div> </div>
<div>In any event, I'd also suggest making the following changes to your XML file before re-importing, so perhaps the snag is a good thing for now <font face="Segoe UI Emoji">😊</font> :</div>
<div> </div>
<ul style="margin:0;padding-left:36pt;">
<li>ASpace adds "aspace_" to all of the @id values in the EAD file upon export. If you don't remove those before reimporting, then on the next export you'll get "aspace_aspace_". Removing them will invalidate the EAD file, but ASpace doesn't care whether
the file is valid or not upon re-importing it.</li><li>ASpace expects to have the database values for the controlled value terms in the exports, not the translation values. So, if you don't change things like "Linear Feet" to linear_feet and "Mixed Materials" to mixed_materials, then you'll wind up with new
database values in ASpace after the import. Those of course can be merged after the fact, but that's another step, and it would be unfortunate to have to do that on every occasion.</li></ul>
<div> </div>
<div>There's a lot more to say on the practice of re-importing EAD into ASpace, but I haven't still come up with a great strategy for that, so basically we try to avoid it <font face="Segoe UI Emoji">😊</font></div>
<div> </div>
<div>Mark</div>
<div> </div>
<div> </div>
<div>-----Original Message-----</div>
<div>From: archivesspace_users_group-bounces@lyralists.lyrasis.org [<a href="mailto:archivesspace_users_group-bounces@lyralists.lyrasis.org">mailto:archivesspace_users_group-bounces@lyralists.lyrasis.org</a>] On Behalf Of Tang, Lydia</div>
<div>Sent: Friday, 10 November, 2017 10:47 AM</div>
<div>To: Archivesspace Users Group <archivesspace_users_group@lyralists.lyrasis.org></div>
<div>Subject: Re: [Archivesspace_Users_Group] batch delete dates saga continues</div>
<div> </div>
<div>Wizardry! Thank you, Olivia! I would have NEVER figured that out. It seemed to take out the <unitdate> tags perfectly but I ended up getting snagged on importing because of, um, a seemingly benign line which was marked as not well-formed. Oof, so close,
but snagged up!</div>
<div>Lydia</div>
<div> </div>
<div>From: <archivesspace_users_group-bounces@lyralists.lyrasis.org> on behalf of Olivia S Solis <livsolis@utexas.edu></div>
<div>Reply-To: Archivesspace Users Group <archivesspace_users_group@lyralists.lyrasis.org></div>
<div>Date: Friday, November 10, 2017 at 10:36 AM</div>
<div>To: Archivesspace Users Group <archivesspace_users_group@lyralists.lyrasis.org></div>
<div>Subject: Re: [Archivesspace_Users_Group] batch delete dates saga continues</div>
<div> </div>
<div><unitda[^>]+>[^<]+<\/unitdate></div>
<div> </div>
</span></font>
</body>
</html>