Bug #6153

multiple nested elements under <physdesc> are not assigned to parent definition list label

Added by Dan Gillean over 8 years ago. Updated almost 8 years ago.

Status:VerifiedStart date:12/18/2013
Priority:MediumDue date:
Assignee:Mike Gale% Done:


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


Import a description with multiple <extent>, <genreform>, <dimensions>, or <physfacet> nested inside. Example:

     <extent encodinganalog="1.5B1">63,48 m de documents textuels</extent>
     <extent encodinganalog="1.5B1">7195 photographie(s)</extent>
     <extent encodinganalog="1.5B1">15 dessin(s)</extent>
     <extent encodinganalog="1.5B1">2 gravure(s)</extent>
     <extent encodinganalog="1.5B1">1 plan(s)</extent>
     <extent encodinganalog="1.5B1">1 dessin(s) d&apos;architecture</extent>
     <extent encodinganalog="1.5B1">327 vidéo(s)</extent>
     <extent encodinganalog="1.5B1">150 bande(s) magnétique(s)</extent>
     <extent encodinganalog="1.5B1">12 objet(s)</extent>
Resulting error
  • The first nested element is added to its corresponding definition list (e.g. extent - in the example above, "63,48 m de documents textuels" is added to the extent label)
  • All subsequent fields are imported, but they do not appear as extent

See attached screenshot.

Expected result
Extent label appears ONCE, with all related elements (e.g. other extent information) appearing beneath the same extent label. We should not need to repeat the extent label for every <extent> element.

Note that this should be true for all nested elements - <genreform>, <dimensions>, <extent> and <physfacet> are the primary candidates we are making sure import. Data in other allowed nested elements (e.g. <name> and other name tags, <occupation>, <function>, <subject>, etc.) SHOULD import, but it is not necessary to keep the EAD tags.

extent-import.png (20.6 KB) Dan Gillean, 12/18/2013 02:31 PM

extent-uneditable.png (16.5 KB) Dan Gillean, 12/18/2013 02:44 PM

Related issues

Related to Access to Memory (AtoM) - Bug #5212: EAD <dimensions> element fails to import into AtoM Verified 06/10/2013


#1 Updated by Dan Gillean over 8 years ago


Following import, the data in Physdesc is uneditable - see attached screenshot, extent-uneditable.png

If you add data to the field and save, it overwrites the previously imported data. User should be able to edit the imported data.

#2 Updated by Dan Gillean about 8 years ago

  • Status changed from New to Verified

Mike Gale actually fixed this a while back and forgot to update the ticket. I have just tested it with the following fake data:

   Some content that is directly in the physdesc tag
   <p>some generic content in a paragraph tag</p>
   <extent encodinganalog="3.1.5">1.15 m of textual records</extent>
   <extent encodinganalog="3.1.5">3 m of sound recordings</extent>
   <dimensions encodinganalog="3.1.5">24 inch reels</dimensions>
   <physfacet encodinganalog="3.1.5">some other detail for physfacet</physfacet>
   <genreform encodinganalog="3.1.5">Textual materials</genreform>

...everything successfully imported, and was editable. We are using definition lists inside of the free text field to be able to maintain and roundtrip the nested elements, which doesn't look pretty in the edit template at first glance, but displays properly in the view template. Marking verified.

#3 Updated by Dan Gillean almost 8 years ago

  • Target version changed from Release 2.0.2 to Release 2.1.0

#4 Updated by Dan Gillean almost 7 years ago

  • Related to Bug #5212: EAD <dimensions> element fails to import into AtoM added

Also available in: Atom PDF