Re: [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:  on behalf of 
Andrew Morrison 
Reply-To: Archivesspace Users Group 

Date: Monday, April 19, 2021 at 1:26 PM
To: "archivesspace_users_group@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 
mailto:brian.hoff...@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



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@lyralists.lyrasis.org<mailto:Archivesspace_Users_Group@lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group




___

Archivesspace_Users_Group mailing list

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

http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

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

[Brian Hoffman]

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

[cid:image001.png@01D73512.22D7F220]

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@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [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 
mailto:brian.hoff...@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 



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@lyralists.lyrasis.org 

http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group 




___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

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

[Majewski, Steven Dennis (sdm7g)]

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  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
>  
> 
>  
> 
>  
> 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:
>  
> This is a legacy bug; the field should have originally validated values to 
> ensure they were URIs
> 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.
> 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@lyralists.lyrasis.org 
> 
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group