Bug #5763

EAD export - AtoM version information in profiledesc/creation has incorrect date

Added by Tim Hutchinson over 8 years ago. Updated about 8 years ago.

Status:VerifiedStart date:10/08/2013
Priority:LowDue date:
Assignee:Mike Gale% Done:


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


Export any description as EAD 2002, and you will get:
Generated by Access to Memory (AtoM) 2.0.0 (2013-07-05 14:00:00)\n <date normal="2013-10-08">2013-10-08 17:44:UTC</date>

So the 2013-07-05 14:00:00 seems to be hard-coded. I'm assuming that this should be the actual release date if it's needed at all.

Also note the linebreak character just after this date which actually comes through as backslash, n rather than a line break (I'm not sure whether the XML extract will display correctly)


#1 Updated by Dan Gillean over 8 years ago

  • Category set to EAD
  • Assignee set to Jesús García Crespo
  • Priority changed from Medium to Low
  • Target version set to Release 2.1.0

You've got a keen eye for detail, Tim - thanks for this.

#2 Updated by Mike Gale over 8 years ago

  • Assignee changed from Jesús García Crespo to Mike Gale

I'll take this issue since it affects how PDF generation looks too

#3 Updated by Dan Gillean over 8 years ago

Mike check out the following:


Part of the problem (and the related problem of warnings on line 0 during import) stems from us passing namespace information as attributes in the <ead> element - though these attributes are not allowed.

the description of the EAD element notes:
To facilitate use of EAD as XML Schema, an xmlns attribute may be switched on in the default DTD by making the following change:
<!ENTITY % namespace

<!ENTITY % namespace

See also the examples.

#4 Updated by Dan Gillean over 8 years ago

However, as you discovered, there is also this attribute note:

XMLNS -- XML Namespace declaration for the EAD standard, which should be set to "urn:isbn:1-931666-00-8." Available only in <ead> and <eadgrp>, but must be manually activated.

Does the "manually activated" part mean that we need to edit the DTD/schema or something?

#5 Updated by Tim Hutchinson over 8 years ago

I'm probably missing the broader issue here (or did the most recent comments get posted to the wrong ticket?), but the original bug seems to boil down to the version date being hard coded at line 134 of plugins/sfEadPlugin/lib/sfEadPlugin.class.php. Or at least that the date doesn't reflect the actual release date.

And then there's apparently something wrong with how the \n gets passed at line 162 of plugins/sfEadPlugin/modules/sfEadPlugin/templates/indexSuccessBody.xml.php

#6 Updated by Dan Gillean over 8 years ago

Haha, sorry, this probably looks kind of obscure on the outside, Tim. We have a theory that this might be related the import warnings on line 0 that are often received in AtoM at the moment - and so were kind of talking internally about 2 things at once, though obviously the public issue ticket doesn't show this. I was posting some resources as follow-up to our investigation for consideration by Mike. You are correct, however, that the original issue ticket itself is unconnected - we'll be fixing this one soon as it affects a development project we have on the go. Sorry for the confusion.

#7 Updated by Tim Hutchinson over 8 years ago

Thanks Dan, always good to know there's a method to the madness :)

I think you're exactly right about "manually activated" - see the text you quoted from the <ead> element notes about switching on the xmlns attribute.

#8 Updated by Mike Gale about 8 years ago

  • Status changed from New to Verified

I've confirmed that date portion has been removed in latest AtoM 2.x. I removed the newlines as they aren't needed.

Also available in: Atom PDF