[
https://jira.duraspace.org/browse/DS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue updated DS-931:
---------------------------
Status: Open (was: Received)
> METS Disseminator never resets its counter for METS @ID attributes
> ------------------------------------------------------------------
>
> Key: DS-931
> URL: https://jira.duraspace.org/browse/DS-931
> Project: DSpace
> Issue Type: Bug
> Components: DSpace API
> Affects Versions: 1.7.0, 1.7.1, 1.7.2
> Reporter: Tim Donohue
> Assignee: Tim Donohue
> Fix For: 1.8.0
>
>
> The org.dspace.content.packager.AbstractMETSDisseminator class never resets
> the internal counter that it uses to assign METS @ID attribute values.
> Although this is not an issue when disseminating METS files (as all @ID
> values still end up unique), it can be of issue for AIP dissemination (which
> uses the METS Disseminator).
> During AIP dissemination, we want the generated METS file to always be
> identical (same checksum) when the DSpace object itself is unchanged.
> However, because the @ID attribute counter never resets itself, it's possible
> (though rare) to have a slightly different METS file generated (for an
> unchanged object) which only has different @ID values.
> For example:
> (1) Disseminate a METS file for an object -- initially the @ID values count
> up from 1
> (2) If you generate another METS file for that same unchanged object from
> that same instance of AbstractMETSDisseminator, then the @ID values will
> *NOT* begin at 1...instead they will continue incrementing from the last @ID
> value of the last METS dissemination. Even though the Object itself is
> unchanged in DSpace, the METS file will be slightly different, since the @ID
> attributes will no longer be identical. Again, for AIP generation we want
> the METS file to remain identical (no matter how many times you generate it),
> so that the AIP itself is identical when and object is unchanged.
> Hopefully that example makes sense...admittedly this is a slightly confusing
> issue, but is easy to resolve. The resolution is to ensure that the counter
> which is used for @ID attributes is always reset (back to 1) each time the
> disseminate() method is called. This ensures, that for each new METS file
> dissemination the counter always begins from 1.
> I'll apply a quick fix to Trunk shortly, so that this issue is resolved for
> DSpace 1.8.0.
> (This bug was encountered as part of the DS-876 Replication Task Suite work)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
