Bug #6877

MODS import doesn't work if namespace attributes included

Added by Tim Hutchinson almost 8 years ago. Updated about 7 years ago.

Status:VerifiedStart date:06/21/2014
Priority:MediumDue date:
Assignee:Dan Gillean% Done:


Target version:Release 2.2.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:


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.

Related issues

Related to Access to Memory (AtoM) - Bug #6064: EAD DTD causing errors and warnings on Import into AtoM 2.x Verified 12/02/2013
Related to Access to Memory (AtoM) - Feature #2787: validate XML files using XSD files located in data/xsd Verified
Related to Access to Memory (AtoM) - Bug #4303: MODS XML export/import roundtripping issue - 500 error pr... Verified


#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:
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:

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.

#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

Also available in: Atom PDF