Re: [Archivesspace_Users_Group] Print to PDF job failing
I just wanted to thank y'all for the help. I was able to fix it by running this query: UPDATE note SET notes = REPLACE(notes,'ns2:','') WHERE notes like '%ns2:%'; Regards, Zach -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org On Behalf Of Custer, Mark Sent: Monday, November 26, 2018 5:51 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Zach, In case it helps, I dug up an old ASpace SQL query to look for those namespace prefixes (turns out that we still have 3 of those lurking around that I need to fix later this week!). Anyhow, here it is: select resource.id as resourceid, resource.ead_id, archival_object.id as aoid, archival_object.root_record_id, convert(notes using utf8) as jsonnote from note left join resource on resource.id = note.resource_id left join archival_object on archival_object.id = note.archival_object_id where notes like '%ns2:%'; Maybe you'll see some patterns there with the files that do work vs. those that don't work. If so, let us know, since that might provide some clues on if there's more work that can be done on the XML cleaning process during the ASpace export process. All my best, Mark -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of Zachary L Pelli Sent: Monday, 26 November, 2018 4:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Mark, Thanks for all the help. The archivist who raised the issue said she was able to run the "Print to PDF" job on multiple other collections successfully. I am unsure whether or not other collections are affected by this, but my guess is there are others. I'll try running some queries tomorrow and see what I find. Regards, Zach -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org On Behalf Of Custer, Mark Sent: Monday, November 26, 2018 3:42 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Zach, No, sorry. That bit of SQL was run against the Archivists' Toolkit database, not ASpace. In ASpace, the SQL update would look quite a bit different, and given how the notes are stored in ASpace, it might be a bit tricky. I'm not sure what the best way would be to address that in ArchivesSpace. Has anyone else handled it there? Two of my colleagues, Alicia and Christy, have run a few different API updates on notes in ASpace, so they'd have more experience about that than I do at this point. In general, though, our usual approach would be to write an SQL query in ASpace to figure out where all of the issues are, and then turning to the API to try and fix those issues as safely as possible (but even that requires a lot of testing, since it's easy to mess things up when working in bulk, so we always test any new updates a few times before running it in our production system). If I recall correctly, someone added a nice fix for this at some point directly in ArchivesSpace that helps clean things up during the export process. I don't recall what/where that file is at the moment, though. I think it would probably be best to try to figure out why that process is not cleaning things up as expected in this particular case and then adding a fix for it there. Zach, is this happening in a lot of your files, or just this one (or some subset)? Mark -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of Zachary L Pelli Sent: Monday, 26 November, 2018 3:26 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Mark, Regarding my instance in particular, would you recommend running that SQL block? I do not see a way to edit the XML from within AS itself, so I'm thinking that leaves the mysql DB or through the API. Regards, Zach -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org On Behalf Of Custer, Mark Sent: Monday, November 26, 2018 2:59 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Lydia, all: I don't know if it's a bug with the AT migrator, but I have raised this issue in 2014 when providing (a lot!) of feedback about the AT migration process. There are a couple of complicated issues, namely: All of those xlink namespace prefixes are treated and stored as text, not as XML (in both the AT and ASpace). So, it can be a bit dangerous and inefficient to change them in bulk. I had hoped that the migration tool would address that issue, but the decision at the time was not to have the migration tool do this. Because of that, we decided to address this prior to our migration with the
Re: [Archivesspace_Users_Group] Print to PDF job failing
Zach, In case it helps, I dug up an old ASpace SQL query to look for those namespace prefixes (turns out that we still have 3 of those lurking around that I need to fix later this week!). Anyhow, here it is: select resource.id as resourceid, resource.ead_id, archival_object.id as aoid, archival_object.root_record_id, convert(notes using utf8) as jsonnote from note left join resource on resource.id = note.resource_id left join archival_object on archival_object.id = note.archival_object_id where notes like '%ns2:%'; Maybe you'll see some patterns there with the files that do work vs. those that don't work. If so, let us know, since that might provide some clues on if there's more work that can be done on the XML cleaning process during the ASpace export process. All my best, Mark -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of Zachary L Pelli Sent: Monday, 26 November, 2018 4:08 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Mark, Thanks for all the help. The archivist who raised the issue said she was able to run the "Print to PDF" job on multiple other collections successfully. I am unsure whether or not other collections are affected by this, but my guess is there are others. I'll try running some queries tomorrow and see what I find. Regards, Zach -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org On Behalf Of Custer, Mark Sent: Monday, November 26, 2018 3:42 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Zach, No, sorry. That bit of SQL was run against the Archivists' Toolkit database, not ASpace. In ASpace, the SQL update would look quite a bit different, and given how the notes are stored in ASpace, it might be a bit tricky. I'm not sure what the best way would be to address that in ArchivesSpace. Has anyone else handled it there? Two of my colleagues, Alicia and Christy, have run a few different API updates on notes in ASpace, so they'd have more experience about that than I do at this point. In general, though, our usual approach would be to write an SQL query in ASpace to figure out where all of the issues are, and then turning to the API to try and fix those issues as safely as possible (but even that requires a lot of testing, since it's easy to mess things up when working in bulk, so we always test any new updates a few times before running it in our production system). If I recall correctly, someone added a nice fix for this at some point directly in ArchivesSpace that helps clean things up during the export process. I don't recall what/where that file is at the moment, though. I think it would probably be best to try to figure out why that process is not cleaning things up as expected in this particular case and then adding a fix for it there. Zach, is this happening in a lot of your files, or just this one (or some subset)? Mark -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of Zachary L Pelli Sent: Monday, 26 November, 2018 3:26 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Mark, Regarding my instance in particular, would you recommend running that SQL block? I do not see a way to edit the XML from within AS itself, so I'm thinking that leaves the mysql DB or through the API. Regards, Zach -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org On Behalf Of Custer, Mark Sent: Monday, November 26, 2018 2:59 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Lydia, all: I don't know if it's a bug with the AT migrator, but I have raised this issue in 2014 when providing (a lot!) of feedback about the AT migration process. There are a couple of complicated issues, namely: All of those xlink namespace prefixes are treated and stored as text, not as XML (in both the AT and ASpace). So, it can be a bit dangerous and inefficient to change them in bulk. I had hoped that the migration tool would address that issue, but the decision at the time was not to have the migration tool do this. Because of that, we decided to address this prior to our migration with the following (albeit inelegant) SQL update: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FYaleArchivesSpace%2FmigrationSQL%2Fblob%2Fmaster%2FAllDatabasesPreMigration.sql%23L1-L26data=02%7C01%7Cmark.custer%40yale.edu%7Cd6c8ba8235814427e9a708d653e33f5a%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C636788632868575733sdata=NSLLhJrJzC5gj2ImscUr0H5dz6Tq92DbXd%2BNt2pIvIM%3Dreserved=0 (that largely did the t
Re: [Archivesspace_Users_Group] Print to PDF job failing
Mark, Thanks for all the help. The archivist who raised the issue said she was able to run the "Print to PDF" job on multiple other collections successfully. I am unsure whether or not other collections are affected by this, but my guess is there are others. I'll try running some queries tomorrow and see what I find. Regards, Zach -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org On Behalf Of Custer, Mark Sent: Monday, November 26, 2018 3:42 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Zach, No, sorry. That bit of SQL was run against the Archivists' Toolkit database, not ASpace. In ASpace, the SQL update would look quite a bit different, and given how the notes are stored in ASpace, it might be a bit tricky. I'm not sure what the best way would be to address that in ArchivesSpace. Has anyone else handled it there? Two of my colleagues, Alicia and Christy, have run a few different API updates on notes in ASpace, so they'd have more experience about that than I do at this point. In general, though, our usual approach would be to write an SQL query in ASpace to figure out where all of the issues are, and then turning to the API to try and fix those issues as safely as possible (but even that requires a lot of testing, since it's easy to mess things up when working in bulk, so we always test any new updates a few times before running it in our production system). If I recall correctly, someone added a nice fix for this at some point directly in ArchivesSpace that helps clean things up during the export process. I don't recall what/where that file is at the moment, though. I think it would probably be best to try to figure out why that process is not cleaning things up as expected in this particular case and then adding a fix for it there. Zach, is this happening in a lot of your files, or just this one (or some subset)? Mark -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of Zachary L Pelli Sent: Monday, 26 November, 2018 3:26 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Mark, Regarding my instance in particular, would you recommend running that SQL block? I do not see a way to edit the XML from within AS itself, so I'm thinking that leaves the mysql DB or through the API. Regards, Zach -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org On Behalf Of Custer, Mark Sent: Monday, November 26, 2018 2:59 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Lydia, all: I don't know if it's a bug with the AT migrator, but I have raised this issue in 2014 when providing (a lot!) of feedback about the AT migration process. There are a couple of complicated issues, namely: All of those xlink namespace prefixes are treated and stored as text, not as XML (in both the AT and ASpace). So, it can be a bit dangerous and inefficient to change them in bulk. I had hoped that the migration tool would address that issue, but the decision at the time was not to have the migration tool do this. Because of that, we decided to address this prior to our migration with the following (albeit inelegant) SQL update: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FYaleArchivesSpace%2FmigrationSQL%2Fblob%2Fmaster%2FAllDatabasesPreMigration.sql%23L1-L26data=01%7C01%7CZachary.pelli%40shu.edu%7C0a2c51afba654c142a9d08d653df9ae7%7C51f07c2253b744dfb97ca13261d71075%7C1sdata=PMiw7s15WKAgZBtzeOdtuKzOoj%2Biw0nMKZenqCYARmw%3Dreserved=0 (that largely did the trick, if I recall correctly). All of those @target attributes are also stored as text. That was a lot messier, so the AT migration tool eventually added the ability to keep the ID values as is (e.g. "ref33" ==> "ref33") during the migration process, but you had to pass that argument (with the "-refid_original" flag) to the migration tool to keep those values as is. Anyhow, given the complexities of the migrations, it's hard to say what's a bug and what's behaving as expected (at least it's hard for me to remember everything involved). That said, Maureen did an AMAZING job of writing up our steps: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcampuspress.yale.edu%2Fyalearchivesspace%2F2015%2F06%2F14%2Fmigration-step-by-step%2Fdata=01%7C01%7CZachary.pelli%40shu.edu%7C0a2c51afba654c142a9d08d653df9ae7%7C51f07c2253b744dfb97ca13261d71075%7C1sdata=TgiyMCs8LhLJvyoh%2FI0Caz9%2BtNh%2FsPotWw1DvPwBf3U%3Dreserved=0 . If anything in there is something that can be fixed with the AT migration tool, I'd be happy to provide more feedback on those tickets. That said, I'm honestly not sure ho
Re: [Archivesspace_Users_Group] Print to PDF job failing
Zach, No, sorry. That bit of SQL was run against the Archivists' Toolkit database, not ASpace. In ASpace, the SQL update would look quite a bit different, and given how the notes are stored in ASpace, it might be a bit tricky. I'm not sure what the best way would be to address that in ArchivesSpace. Has anyone else handled it there? Two of my colleagues, Alicia and Christy, have run a few different API updates on notes in ASpace, so they'd have more experience about that than I do at this point. In general, though, our usual approach would be to write an SQL query in ASpace to figure out where all of the issues are, and then turning to the API to try and fix those issues as safely as possible (but even that requires a lot of testing, since it's easy to mess things up when working in bulk, so we always test any new updates a few times before running it in our production system). If I recall correctly, someone added a nice fix for this at some point directly in ArchivesSpace that helps clean things up during the export process. I don't recall what/where that file is at the moment, though. I think it would probably be best to try to figure out why that process is not cleaning things up as expected in this particular case and then adding a fix for it there. Zach, is this happening in a lot of your files, or just this one (or some subset)? Mark -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of Zachary L Pelli Sent: Monday, 26 November, 2018 3:26 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Mark, Regarding my instance in particular, would you recommend running that SQL block? I do not see a way to edit the XML from within AS itself, so I'm thinking that leaves the mysql DB or through the API. Regards, Zach -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org On Behalf Of Custer, Mark Sent: Monday, November 26, 2018 2:59 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Lydia, all: I don't know if it's a bug with the AT migrator, but I have raised this issue in 2014 when providing (a lot!) of feedback about the AT migration process. There are a couple of complicated issues, namely: All of those xlink namespace prefixes are treated and stored as text, not as XML (in both the AT and ASpace). So, it can be a bit dangerous and inefficient to change them in bulk. I had hoped that the migration tool would address that issue, but the decision at the time was not to have the migration tool do this. Because of that, we decided to address this prior to our migration with the following (albeit inelegant) SQL update: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FYaleArchivesSpace%2FmigrationSQL%2Fblob%2Fmaster%2FAllDatabasesPreMigration.sql%23L1-L26data=02%7C01%7Cmark.custer%40yale.edu%7Cb18d86b62ff4402c74c708d653dd6ef7%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C636788607928715851sdata=zitl0BNm4TsJbInSEH2Lpsq4B2b7o9BS%2F8ZqGi8YNLU%3Dreserved=0 (that largely did the trick, if I recall correctly). All of those @target attributes are also stored as text. That was a lot messier, so the AT migration tool eventually added the ability to keep the ID values as is (e.g. "ref33" ==> "ref33") during the migration process, but you had to pass that argument (with the "-refid_original" flag) to the migration tool to keep those values as is. Anyhow, given the complexities of the migrations, it's hard to say what's a bug and what's behaving as expected (at least it's hard for me to remember everything involved). That said, Maureen did an AMAZING job of writing up our steps: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcampuspress.yale.edu%2Fyalearchivesspace%2F2015%2F06%2F14%2Fmigration-step-by-step%2Fdata=02%7C01%7Cmark.custer%40yale.edu%7Cb18d86b62ff4402c74c708d653dd6ef7%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C636788607928715851sdata=wrC%2BCtod5QST%2F4dVjM6g6g9PGt3iBS932frIgp45hik%3Dreserved=0 . If anything in there is something that can be fixed with the AT migration tool, I'd be happy to provide more feedback on those tickets. That said, I'm honestly not sure how best to capture those there at this point (and I think / assumed that all of those issues were recorded in a previous bug/feature tracking system used by ASpace). Mark -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of Tang, Lydia Sent: Monday, 26 November, 2018 1:23 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Hi Zach, Ed, and Mark, It sounds like this is a bug with the A
Re: [Archivesspace_Users_Group] Print to PDF job failing
Mark, Regarding my instance in particular, would you recommend running that SQL block? I do not see a way to edit the XML from within AS itself, so I'm thinking that leaves the mysql DB or through the API. Regards, Zach -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org On Behalf Of Custer, Mark Sent: Monday, November 26, 2018 2:59 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Lydia, all: I don't know if it's a bug with the AT migrator, but I have raised this issue in 2014 when providing (a lot!) of feedback about the AT migration process. There are a couple of complicated issues, namely: All of those xlink namespace prefixes are treated and stored as text, not as XML (in both the AT and ASpace). So, it can be a bit dangerous and inefficient to change them in bulk. I had hoped that the migration tool would address that issue, but the decision at the time was not to have the migration tool do this. Because of that, we decided to address this prior to our migration with the following (albeit inelegant) SQL update: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FYaleArchivesSpace%2FmigrationSQL%2Fblob%2Fmaster%2FAllDatabasesPreMigration.sql%23L1-L26data=01%7C01%7CZachary.pelli%40shu.edu%7C51655a3db3c24d40642a08d653d9af16%7C51f07c2253b744dfb97ca13261d71075%7C1sdata=6E9RbWLc%2BM%2FTxJGJ9X%2FgviFCRFlCzYhBlxAPhPVcIRs%3Dreserved=0 (that largely did the trick, if I recall correctly). All of those @target attributes are also stored as text. That was a lot messier, so the AT migration tool eventually added the ability to keep the ID values as is (e.g. "ref33" ==> "ref33") during the migration process, but you had to pass that argument (with the "-refid_original" flag) to the migration tool to keep those values as is. Anyhow, given the complexities of the migrations, it's hard to say what's a bug and what's behaving as expected (at least it's hard for me to remember everything involved). That said, Maureen did an AMAZING job of writing up our steps: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcampuspress.yale.edu%2Fyalearchivesspace%2F2015%2F06%2F14%2Fmigration-step-by-step%2Fdata=01%7C01%7CZachary.pelli%40shu.edu%7C51655a3db3c24d40642a08d653d9af16%7C51f07c2253b744dfb97ca13261d71075%7C1sdata=VHF7%2BFRIYh0VQQh%2Bui2YndcnqwGVn%2FJQBgC3g7D4Npc%3Dreserved=0 . If anything in there is something that can be fixed with the AT migration tool, I'd be happy to provide more feedback on those tickets. That said, I'm honestly not sure how best to capture those there at this point (and I think / assumed that all of those issues were recorded in a previous bug/feature tracking system used by ASpace). Mark -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of Tang, Lydia Sent: Monday, 26 November, 2018 1:23 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Hi Zach, Ed, and Mark, It sounds like this is a bug with the AT Migrator. Would you be willing to create a bug report for this in JIRA? On a quick search, it didn’t seem like this issue has been logged yet. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchivesspace.atlassian.net%2Fsecure%2FDashboard.jspadata=01%7C01%7CZachary.pelli%40shu.edu%7C51655a3db3c24d40642a08d653d9af16%7C51f07c2253b744dfb97ca13261d71075%7C1sdata=CtyHiDP11seG18JK%2FhkmdsW8P%2Fgz7bJeJZ6FRGbYs5Y%3Dreserved=0 It would be great if you could include in the tags “ATMigrator.” Thanks! Lydia -on behalf of Dev. Pri. From: on behalf of "Custer, Mark" Reply-To: Archivesspace Users Group Date: Monday, November 26, 2018 at 12:36 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Removing the ns2: prefix altogether should work, as should updating those ns2: prefixes to be xlink: prefixes (but it’s not good to have that in the text in the first place, so I wouldn’t advise that). I’m not sure why ASpace’s normal EAD cleaning process isn’t changing those prefixes to xlink prefixes during the export, though. Another issue (seeing that this came from the AT) is that the @target attributes in the EAD file don’t match any @id attributes (e.g. “ref16” does not equal “aspace_ref16_p33”). This won’t cause the file from converting to a PDF, but it’s still a broken link. All that said, if there’s no need to have a valid EAD file, then probably the easiest way to fix the PDF conversion issue (and something that ASpace could handle easily) would be to add a second namespace prefix for the xlink attributes. So, just changing this: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2Fxlinkdata=01%7C01%7CZachary.pelli%4
Re: [Archivesspace_Users_Group] Print to PDF job failing
Lydia, all: I don't know if it's a bug with the AT migrator, but I have raised this issue in 2014 when providing (a lot!) of feedback about the AT migration process. There are a couple of complicated issues, namely: All of those xlink namespace prefixes are treated and stored as text, not as XML (in both the AT and ASpace). So, it can be a bit dangerous and inefficient to change them in bulk. I had hoped that the migration tool would address that issue, but the decision at the time was not to have the migration tool do this. Because of that, we decided to address this prior to our migration with the following (albeit inelegant) SQL update: https://github.com/YaleArchivesSpace/migrationSQL/blob/master/AllDatabasesPreMigration.sql#L1-L26 (that largely did the trick, if I recall correctly). All of those @target attributes are also stored as text. That was a lot messier, so the AT migration tool eventually added the ability to keep the ID values as is (e.g. "ref33" ==> "ref33") during the migration process, but you had to pass that argument (with the "-refid_original" flag) to the migration tool to keep those values as is. Anyhow, given the complexities of the migrations, it's hard to say what's a bug and what's behaving as expected (at least it's hard for me to remember everything involved). That said, Maureen did an AMAZING job of writing up our steps: https://campuspress.yale.edu/yalearchivesspace/2015/06/14/migration-step-by-step/ . If anything in there is something that can be fixed with the AT migration tool, I'd be happy to provide more feedback on those tickets. That said, I'm honestly not sure how best to capture those there at this point (and I think / assumed that all of those issues were recorded in a previous bug/feature tracking system used by ASpace). Mark -Original Message- From: archivesspace_users_group-boun...@lyralists.lyrasis.org [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of Tang, Lydia Sent: Monday, 26 November, 2018 1:23 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Hi Zach, Ed, and Mark, It sounds like this is a bug with the AT Migrator. Would you be willing to create a bug report for this in JIRA? On a quick search, it didn’t seem like this issue has been logged yet. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchivesspace.atlassian.net%2Fsecure%2FDashboard.jspadata=02%7C01%7Cmark.custer%40yale.edu%7C773babf6349f4b3622dc08d653cc2c5a%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C636788533731893576sdata=mbYCBrPIttccGrW%2FfPF6mUx5uFHy8TEQDHXMsIicCSA%3Dreserved=0 It would be great if you could include in the tags “ATMigrator.” Thanks! Lydia -on behalf of Dev. Pri. From: on behalf of "Custer, Mark" Reply-To: Archivesspace Users Group Date: Monday, November 26, 2018 at 12:36 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Removing the ns2: prefix altogether should work, as should updating those ns2: prefixes to be xlink: prefixes (but it’s not good to have that in the text in the first place, so I wouldn’t advise that). I’m not sure why ASpace’s normal EAD cleaning process isn’t changing those prefixes to xlink prefixes during the export, though. Another issue (seeing that this came from the AT) is that the @target attributes in the EAD file don’t match any @id attributes (e.g. “ref16” does not equal “aspace_ref16_p33”). This won’t cause the file from converting to a PDF, but it’s still a broken link. All that said, if there’s no need to have a valid EAD file, then probably the easiest way to fix the PDF conversion issue (and something that ASpace could handle easily) would be to add a second namespace prefix for the xlink attributes. So, just changing this: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2Fxlinkdata=02%7C01%7Cmark.custer%40yale.edu%7C773babf6349f4b3622dc08d653cc2c5a%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C636788533731893576sdata=P6ciXyZGd6qJxLv89WrFrDmpr7qPiGsSbje4o6vfwYs%3Dreserved=0; xmlns:xsi="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instancedata=02%7C01%7Cmark.custer%40yale.edu%7C773babf6349f4b3622dc08d653cc2c5a%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C636788533731893576sdata=6YXrzjGHRtKM66eBDaJjzv9cKKVAyqwuL%2FdRdyCIak4%3Dreserved=0; xsi:schemaLocation="urn:isbn:1-931666-22-9 https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.loc.gov%2Fead%2Fead.xsddata=02%7C01%7Cmark.custer%40yale.edu%7C773babf6349f4b3622dc08d653cc2c5a%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C636788533731903580sdata=oBv2gmHytov%2F4YLdcBIz%2FKaqDcDADJ0D9%2FJiV4kbtXE%3Dreserved=0;> To this: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3
Re: [Archivesspace_Users_Group] Print to PDF job failing
Hi Zach, Ed, and Mark, It sounds like this is a bug with the AT Migrator. Would you be willing to create a bug report for this in JIRA? On a quick search, it didn’t seem like this issue has been logged yet. https://archivesspace.atlassian.net/secure/Dashboard.jspa It would be great if you could include in the tags “ATMigrator.” Thanks! Lydia -on behalf of Dev. Pri. From: on behalf of "Custer, Mark" Reply-To: Archivesspace Users Group Date: Monday, November 26, 2018 at 12:36 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Removing the ns2: prefix altogether should work, as should updating those ns2: prefixes to be xlink: prefixes (but it’s not good to have that in the text in the first place, so I wouldn’t advise that). I’m not sure why ASpace’s normal EAD cleaning process isn’t changing those prefixes to xlink prefixes during the export, though. Another issue (seeing that this came from the AT) is that the @target attributes in the EAD file don’t match any @id attributes (e.g. “ref16” does not equal “aspace_ref16_p33”). This won’t cause the file from converting to a PDF, but it’s still a broken link. All that said, if there’s no need to have a valid EAD file, then probably the easiest way to fix the PDF conversion issue (and something that ASpace could handle easily) would be to add a second namespace prefix for the xlink attributes. So, just changing this: 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;> To this: http://www.w3.org/1999/xlink; xmlns:ns2="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;> Given the broken links, though, which were also caused by the AT to ASpace migration (and the fact that ASpace prepends “aspace_” during its EAD export process), I’d say that some data updates would have to happen at some point, though. But the above trick should allow you to create the PDF for this file with the least amount of editing. From: archivesspace_users_group-boun...@lyralists.lyrasis.org [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of Busch, Ed Sent: Monday, 26 November, 2018 11:58 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing I just remove ns2: from ns2:actuate. Ed From: archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org> mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>> On Behalf Of Zachary L Pelli Sent: Monday, November 26, 2018 11:51 AM To: Archivesspace Users Group mailto:archivesspace_users_group@lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Thanks for the reply, guys. I have attached the EAD file. This is indeed likely a carry-over from AT. I do not see a namespace declaration in the file, but I do see the ns2 prefixes. So would the solution be to eliminate the ns2 prefixes? Regards, Zach From: archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org> mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>> On Behalf Of Custer, Mark Sent: Tuesday, November 20, 2018 3:43 PM To: Archivesspace Users Group mailto:archivesspace_users_group@lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Zach, I’d suggest exporting the EAD file and taking a look at the file that way (and I’d be happy to take a look if you can send it to me). Those “ns2” namespace prefixes are likely from Archivist’s Toolkit, which at some point started appending that prefix for the xlink namespace (which is fine, but everything that looks like XML in the AT and ASpace is treated as text, and things can get messy when namespace prefixed are hardcoded in that text!). ArchivesSpace has a process to clean the XML upon export, which generally fixes a lot of those hard-coded namespace prefixes, but I’m honestly not sure why you’d be getting that error without seeing the entire EAD file since you shouldn’t even need a valid EAD file for the PDF process to potentially still work. There are other reasons why the PDF file not be created, but I can’t think of why that type of invalidity would cause it to fail on its own. Anyhow, the issue that’s being reported is that the EAD file that ASpace will produce for this record will have the following at the top of the file: xmlns:xlink=”http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dh
Re: [Archivesspace_Users_Group] Print to PDF job failing
I just remove ns2: from ns2:actuate. Ed From: archivesspace_users_group-boun...@lyralists.lyrasis.org On Behalf Of Zachary L Pelli Sent: Monday, November 26, 2018 11:51 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Thanks for the reply, guys. I have attached the EAD file. This is indeed likely a carry-over from AT. I do not see a namespace declaration in the file, but I do see the ns2 prefixes. So would the solution be to eliminate the ns2 prefixes? Regards, Zach From: archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org> mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>> On Behalf Of Custer, Mark Sent: Tuesday, November 20, 2018 3:43 PM To: Archivesspace Users Group mailto:archivesspace_users_group@lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing Zach, I'd suggest exporting the EAD file and taking a look at the file that way (and I'd be happy to take a look if you can send it to me). Those "ns2" namespace prefixes are likely from Archivist's Toolkit, which at some point started appending that prefix for the xlink namespace (which is fine, but everything that looks like XML in the AT and ASpace is treated as text, and things can get messy when namespace prefixed are hardcoded in that text!). ArchivesSpace has a process to clean the XML upon export, which generally fixes a lot of those hard-coded namespace prefixes, but I'm honestly not sure why you'd be getting that error without seeing the entire EAD file since you shouldn't even need a valid EAD file for the PDF process to potentially still work. There are other reasons why the PDF file not be created, but I can't think of why that type of invalidity would cause it to fail on its own. Anyhow, the issue that's being reported is that the EAD file that ASpace will produce for this record will have the following at the top of the file: xmlns:xlink="http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink=DwMFAg=nE__W8dFE-shTxStwXtp0A=nzQRpzss_AwHOHAKVWRsNQ=J7u-pzUAtEowL9CMv6zcGzDAF9jip-FovsDGWzizIFE=RsTVozfa9pRzr4KkH6jg9bmLJjgVDvEd-osjunk3Ccc=>" Whereas what you have further down in your file on that ref tag is "ns2:", and if you export that same file from the AT (or whatever else caused the ns2 prefix to get in there), you'd see this at the top of the file: xmlns:ns2:"http://www.w3.org/1999/xlink<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xlink=DwMFAg=nE__W8dFE-shTxStwXtp0A=nzQRpzss_AwHOHAKVWRsNQ=J7u-pzUAtEowL9CMv6zcGzDAF9jip-FovsDGWzizIFE=RsTVozfa9pRzr4KkH6jg9bmLJjgVDvEd-osjunk3Ccc=>" And "xlink" does not equal "ns2", even though they're both trying to stand in for the same namespace. All that said, the only way that I can think to troubleshoot the issue is investigating the EAD file itself, since the process for creating a PDF from the staff interface is 1) export the EAD, then 2) convert that EAD into a PDF file. Mark From: archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org> [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of Busch, Ed Sent: Tuesday, 20 November, 2018 2:59 PM To: Archivesspace Users Group mailto:archivesspace_users_group@lyralists.lyrasis.org>> Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing The collection probably has a component title of the form The Alert--. These will generate an error when creating a finding aid in PDF format. The ns2 text around the title should be removed. For example, The Alert from the example above. So, you get to figure out which one it is. If you have access to the backend DB, you can probably come up with a query to find it. Or you can go through your Resource component lines looking for it. Good luck! Ed Busch, MLIS Electronic Records Archivist Michigan State University Archives Conrad Hall 943 Conrad Road, Room 101 East Lansing, MI 48824 517-884-6438 busch...@msu.edu<mailto:busch...@msu.edu> From: archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org> mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>> On Behalf Of Zachary L Pelli Sent: Tuesday, November 20, 2018 2:52 PM To: archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Print to PDF job failing Hey all, One of our archivists is having an issue with a Print to PDF job with a particular collection (other large collections work fine). In the log within AS Background Jobs section, it gives this: Generating PDF for John M. Oesterreicher pa
Re: [Archivesspace_Users_Group] Print to PDF job failing
Zach, I'd suggest exporting the EAD file and taking a look at the file that way (and I'd be happy to take a look if you can send it to me). Those "ns2" namespace prefixes are likely from Archivist's Toolkit, which at some point started appending that prefix for the xlink namespace (which is fine, but everything that looks like XML in the AT and ASpace is treated as text, and things can get messy when namespace prefixed are hardcoded in that text!). ArchivesSpace has a process to clean the XML upon export, which generally fixes a lot of those hard-coded namespace prefixes, but I'm honestly not sure why you'd be getting that error without seeing the entire EAD file since you shouldn't even need a valid EAD file for the PDF process to potentially still work. There are other reasons why the PDF file not be created, but I can't think of why that type of invalidity would cause it to fail on its own. Anyhow, the issue that's being reported is that the EAD file that ASpace will produce for this record will have the following at the top of the file: xmlns:xlink="http://www.w3.org/1999/xlink; Whereas what you have further down in your file on that ref tag is "ns2:", and if you export that same file from the AT (or whatever else caused the ns2 prefix to get in there), you'd see this at the top of the file: xmlns:ns2:"http://www.w3.org/1999/xlink; And "xlink" does not equal "ns2", even though they're both trying to stand in for the same namespace. All that said, the only way that I can think to troubleshoot the issue is investigating the EAD file itself, since the process for creating a PDF from the staff interface is 1) export the EAD, then 2) convert that EAD into a PDF file. Mark From: archivesspace_users_group-boun...@lyralists.lyrasis.org [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of Busch, Ed Sent: Tuesday, 20 November, 2018 2:59 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Print to PDF job failing The collection probably has a component title of the form The Alert--. These will generate an error when creating a finding aid in PDF format. The ns2 text around the title should be removed. For example, The Alert from the example above. So, you get to figure out which one it is. If you have access to the backend DB, you can probably come up with a query to find it. Or you can go through your Resource component lines looking for it. Good luck! Ed Busch, MLIS Electronic Records Archivist Michigan State University Archives Conrad Hall 943 Conrad Road, Room 101 East Lansing, MI 48824 517-884-6438 busch...@msu.edu<mailto:busch...@msu.edu> From: archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org> mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>> On Behalf Of Zachary L Pelli Sent: Tuesday, November 20, 2018 2:52 PM To: archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org> Subject: [Archivesspace_Users_Group] Print to PDF job failing Hey all, One of our archivists is having an issue with a Print to PDF job with a particular collection (other large collections work fine). In the log within AS Background Jobs section, it gives this: Generating PDF for John M. Oesterreicher papers org.xml.sax.SAXParseException; lineNumber: 28; columnNumber: 76; The prefix "ns2" for attribute "ns2:actuate" associated with an element type "ref" is not bound. net.sf.saxon.s9api.DocumentBuilder.build(net/sf/saxon/s9api/DocumentBuilder.java:379) java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:606) org.jruby.javasupport.JavaMethod.invokeDirectWithExceptionHandling(org/jruby/javasupport/JavaMethod.java:453) org.jruby.javasupport.JavaMethod.invokeDirect(org/jruby/javasupport/JavaMethod.java:314) RUBY.parse(/var/local/archivesspace/archivesspace250/gems/gems/saxon-xslt-0.8.2.1-java/lib/saxon/xml.rb:28) RUBY.XML(/var/local/archivesspace/archivesspace250/gems/gems/saxon-xslt-0.8.2.1-java/lib/saxon/processor.rb:58) RUBY.XML(/var/local/archivesspace/archivesspace250/gems/gems/saxon-xslt-0.8.2.1-java/lib/saxon/xml.rb:10) RUBY.to_fo(/var/local/archivesspace/archivesspace250/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/AS_fop.rb:32) RUBY.to_pdf(/var/local/archivesspace/archivesspace250/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/AS_fop.rb:38) RUBY.block in run(/var/local/archivesspace/archivesspace250/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/job_runners/print_to_pdf_runner.rb:39) var.local.archivesspace.archivesspace250.data.tmp.jetty_minus_0_dot_0_dot_0_dot_0_minus_8089_minus_backend_dot_war_minus___minus_any_minus_.webapp.WEB_minus_INF.app.lib.request_context.open(/var/local/archivesspace/archivesspace250/da
