[Archivesspace_Users_Group] Should digital object file_uri field allow non URI data?

[Brian Hoffman]

Thanks for the feedback. I am inclined to think “A” as well, though implementing a validation at this point seems counterproductive since it make existing databases with markup / mixed content in there more problematic.

From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Andrew Morrison <andrew.morrison at bodleian.ox.ac.uk>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Date: Monday, April 19, 2021 at 1:26 PM
To: "archivesspace_users_group at lyralists.lyrasis.org" <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Should digital object file_uri field allow non URI data?


Option A, because anything but a URI would create invalid EAD if exported or requested via OAI-PMH.

Andrew.


On 19/04/2021 17:41, Majewski, Steven Dennis (sdm7g) wrote:

I would think ‘A’, but that’s based on that the field is labeled “File URI” so I expect something that looks like a URI, and the fact that some notes in ArchivesSpace are explicitly labeled as allowing mixed content, and that has made me assume that allowing mixed content is not the default. But I guess that would not rule out ‘C’ as the original intention.

(Sometimes, if I assume something long enough, it turns into a rule in my head!)

I would also note that where mixed content is allowed, it doesn’t appear to be validated, and I’m seeing a lot of examples in the wild of invalid EAD exported with missing end tags, undeclared namespaces and other issues that prevent parsing EAD exported from ArchivesSpace. We probably should add a validation step where mixed content is allowed to attempt to parse the note as an XML fragment, and not accept the edit if it fails. ( I’ve been meaning to get around to testing this to see if there are any side effects or spurious rejections from doing this. )

— Steve.


On Apr 19, 2021, at 11:50 AM, Brian Hoffman <brian.hoffman at lyrasis.org<mailto:brian.hoffman at lyrasis.org>> wrote:

Hi,

We have been trying to understand what to do about cases like the following:

http://sandbox.archivesspace.org/digital_objects/2/edit#tree::digital_object_2

<image001.png>

As things are now, ArchivesSpace will allow a value like this, but various renderings and transformations will not work as expected. I am wondering if:


  1.  This is a legacy bug; the field should have originally validated values to ensure they were URIs
  2.  This is a presentation layer bug: non URIs should be allowed in the file_uri field, but HTML and PDF presentations need to accommodate that.
  3.  Everything is fine. Users should be able to put whatever they want in file_uri, but if they want it to present right they need to write a plugin.

This isn’t an academic question, as this is currently happening with records created automatically by Preservica software.

Brian
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group




_______________________________________________

Archivesspace_Users_Group mailing list

Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>

http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210420/5476c0e2/attachment.html>