In version 2.5.1, digital objects export with invalid audience attributes. Attribute 'xlink:audience' is not allowed to appear in element 'dao'. Also, should not have multiple audience attributes.
Possible solution: don't insert another @audience when file_versions_to_display.length == 1
Given that a parent AO's publish status currently cascades down to child AO, I think the same logic should apply to DO and the file versions. If the Digital Object publish is False, then the audience should be internal — even if there’s an attached file version with publish=true. The top level DO record’s publish status should cascade.
This would be logically consistent with other ‘publish’ functionality elsewhere within the aspace. This seems very similar to the way that a child AO does not publish if the ancestor Series level AO is unpublished, for example.
(Perhaps including some of the same logic from the resource tree, where a AO displays a warning about the ancestor’s publish status. Something like ‘be aware this digital object record is unpublished’. Extra / not absolutely necessary, but would help make things a bit more transparent to users about what is going to happen.)
The metadata standards group discussed this ticket, and agrees with above - “If the Digital Object publish is False, then the audience should be internal — even if there’s an attached file version with publish=true.”
This issue is of interest to us at the Bodleian, because we plan to add digital objects soon. Because valid EAD is important to us for updating other systems with changes to the metadata, I had previously developed a fix for this in our local plug-in. I have now replicated those changes in a pull request on GitHub, for consideration as a potential fix for this issue in a future ArchivesSpace release:
In particular, and might like to review the logic I’ve set up for when an audience=”internal” should be output in the EAD export. I think it is consistent with your comments, but it is easy to misread such things, and the way the EAD output differs depending on the number of file versions adds further complication.
While working on this I noticed the EAD3 export was putting the dao for digital objects linked to resources (i.e. collection-level) in a place which was valid in EAD2002 but is no longer so in EAD3. So I have changed that too.
Just confirming - the logic in your pull request aligns with what we were hoping for at the Smithsonian. Thanks for sharing your fix. (And for catching the EAD3 dao placement issue too).
Appears to be fixed in the 2.8.0 RC