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

[Andrew Morrison]

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 
>> <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 
>> <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> 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/20210419/c768eb4f/attachment.html>