Bug #6877
MODS import doesn't work if namespace attributes included
| Status: | Verified | Start date: | 06/21/2014 | |
|---|---|---|---|---|
| Priority: | Medium | Due date: | ||
| Assignee: | Dan Gillean | % Done: | 0% | |
| Category: | Import/Export | |||
| Target version: | Release 2.2.0 | |||
| Google Code Legacy ID: | Tested version: | |||
| Sponsored: | No | Requires documentation: |
Description
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
*xmlns="http://www.loc.gov/mods/v3"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.loc.gov/standards/mods/v3/mods-3-3.xsd"
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.
Related issues
History
#1 Updated by Dan Gillean almost 8 years ago
- Category set to Import/Export
- Assignee set to Jesús García Crespo
- Target version set to Release 2.2.0
Assigning to Jesus for triage. Tentatively assigning to 2.2.
#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:
https://github.com/artefactual/atom/blob/qa/2.1.x/lib/QubitXmlImport.class.php#L131
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
Hi Tim,
It looks like you need to use a different validation function in PHP to validate against an XSD:
http://php.net/manual/en/domdocument.schemavalidate.php
So something like this would be a start:
https://gist.github.com/djjuhasz/2768a2eb929a7fe1ae5d#file-qubitxmlimport-class-php-L146
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.
#4 Updated by David Juhasz over 7 years ago
Regarding local XML validation against an XSD, See also: issue #2787. It would be nice to use a catalogue solution for EAD and MODS at the same time.
#5 Updated by Dan Gillean about 7 years ago
Hey Tim,
Just doing some issue ticket cleanup and I'm wondering if maybe you can save me some testing/investigation time. Did we end up resolving this as part of the USask MODS work? Ir is this issue still relevant? Thanks!
#6 Updated by Tim Hutchinson about 7 years ago
Hi Dan - Yes, this was definitely addressed for MODS. See #7292
#7 Updated by Dan Gillean about 7 years ago
- Status changed from New to QA/Review
- Assignee changed from Jesús García Crespo to Dan Gillean
Woot woot! Thanks :)
#8 Updated by Dan Gillean about 7 years ago
- Status changed from QA/Review to Verified
#9 Updated by Dan Gillean about 7 years ago
- Related to Bug #4303: MODS XML export/import roundtripping issue - 500 error produced when attempting to import MODS XML added