MODs component should not rely on contains(@ID,'_mods_')
Description
The MODS component assumes that MODS metadata is only stored in MyCoRe Objects with {{objectType='mods' }}( look for example: mods-solr.xml). Since MODS can occur in other objectTypes too, we suggest that the check should use the XPath:{{ /metdata/def.modsContainer/modsContainer/mods:mods}} instead
It should be discussed, if the suggested XPath is practicable.
The ticket shall be used to look for similiar occurrences in XSL and Java code to allow a broader use of the MODS component.
The most and important code parts containing this type of check are identified and fixed. For the one remaining issue within MCRMODSWrapper a new bug is opened, which will be looked at in the next release.
Robert Stephan
May 24, 2016 at 4:31 PM
please rewrite the following XPath in MCRMODSWrapper: {{private static final String LINKED_RELATED_ITEMS = "mods:relatedItem[@type='host' and ancestor::mycoreobject/structure/parents/parent or" + " contains(@xlink:href,'mods') and" + " number(substring-after(@xlink:href,'mods')) > 0 and" + " contains('" + MCRMODSRelationshipType.xPathList() + "', @type)]";}}
Robert Stephan
March 21, 2016 at 2:47 PM
check also for IndexOutOfBoundsException in MODSWrapper
Robert Stephan
March 18, 2016 at 4:14 PM
MCRMODSEventhandler should not only check for objectType='mods'
Robert Stephan
March 7, 2016 at 11:25 AM
change xpath in mods-solr.xml to check for MODS content
The MODS component assumes that MODS metadata is only stored in MyCoRe Objects with {{objectType='mods' }}( look for example: mods-solr.xml).
Since MODS can occur in other objectTypes too, we suggest that the check should use the XPath:{{ /metdata/def.modsContainer/modsContainer/mods:mods}} instead
It should be discussed, if the suggested XPath is practicable.
The ticket shall be used to look for similiar occurrences in XSL and Java code to allow a broader use of the MODS component.