MODS import doesn't work if namespace attributes included
|Assignee:||Dan Gillean||% Done:|
|Target version:||Release 2.2.0|
|Google Code Legacy ID:||Tested version:|
I've filed this separately, since the behaviour is a bit different than for EAD import, and I'm hoping this isn't a dealbreaker for adding support for MODS import.
Basic MODS import is addressed in #4303. But there is a similar problem to that discussed in #6064:
- if the namespace attributes* are included in the mods element, the import is reported as successful, but there's no link to the description, and nothing is actually imported
- if the namespace elements are deleted from the XML, it works as expected
The behaviour is different from #6064 - for EAD import, it appears there are errors/warnings but then the import actually works. But both issues relate to the extra namespace attributes (the same workaround).
Running in debug mode, I didn't get any warnings/errors, and there doesn't seem to be anything in the apache error log.
#2 Updated by Tim Hutchinson almost 8 years ago
I was hoping Mike's fix in #6064 would also take care of the MODS case, but no luck. It turns out I already had allow_url_fopen enabled. Makes sense, since warnings weren't actually being displayed.
A bit of stab in the dark, but I'm wondering if specific handling is needed for MODS in this section:
I tried just adding MODS to the EAD case, but then it's looking for a MODS DTD.
#3 Updated by David Juhasz over 7 years ago
It looks like you need to use a different validation function in PHP to validate against an XSD:
So something like this would be a start:
Unfortunately this introduces a new wrinkle, as you need to pass a filename to schemaValidate(). The best way to handle this is probably to add a local copy the MODS 3.5 XSD to AtoM, and use a catalog for validation . You could also try and load the authoritative MODS 3.5 XSD from the LOC site via fopen() or something similar, but this approach has security, latency and availability issues.