Bug #788

xmp handling faults (II) - AKA: policing XMP namespaces

Added by Jens Mueller about 10 years ago. Updated about 5 years ago.

Target version:
Start date:
29 Aug 2011
Due date:
% Done:


Estimated time:


This entry is for seperating xmp handling bugs from xmpsdk upgrade for easier tracking.

Steps to reproduce:
  • Open the attached image in some xmp conform application like Adobe Lightroom or Nikon ViewNX2. Verify that Dublin Core Schema property 'creator' is set to 'Daffy Duck'.
  • Open the image in some application using libexiv2 for metadata handling like Digikam and see that Dublin Core Schema property 'creator' is set to 'Daffy Duck, Bugs Bunny'.
  • Set the Dublin Core Schema property 'subject' with the following command ' exiv2 -M "set Xmp.dc.subject bug-verification" '
  • See that Dublin Core Schema property 'creator' is set to 'Bugs Bunny'.

This bug is worse, it trashes valid informations.

Developer note: This file uses non-common prefixes. This is not a fault of the file, it is used to show up the defects of the current implementation of the xmp standard.


exiv2_xmp_dc2.jpg (12.4 KB) exiv2_xmp_dc2.jpg Jens Mueller, 29 Aug 2011 11:57

Related issues

Related to Exiv2 - Feature #941: Upgrade xmpsdk source to Adobe's current versionClosed27 Dec 2013




Updated by Robin Mills over 6 years ago

  • Category set to metadata
  • Status changed from New to Assigned
  • Assignee set to Alan Pater
  • Target version set to 0.26

Updated by Alan Pater about 6 years ago

  • Subject changed from xmp handling faults (II) to xmp handling faults (II) - AKA: policing XMP namespaces
  • Assignee changed from Alan Pater to Andreas Huggel

According to the XMP specification, the correct namespace for dc is

The attached test file overwrites this with and reassigns that URI to the custom namespace of dc_1 thus causing confusion amongst consumers of the data.

I have understood that exiv2 has made this design decision to not police XMP namespaces nor XMP properties. I think a case could be made for revisiting that decision on the grounds that it is a quite unusual user of exiv2 who would have a need or desire to change pre-registered namespaces or XMP properties and data types. Many if not most users would I suspect expect exiv2 to lock down existing namespaces and properties rather then let them mess things up. Of course, that is easy for me to say, as I am not qualified to actually write the code to do that! ;-)

I suggest holding off on any changes to this issue until the XMP SDK is updated. As of this writing the XMP SDK is at version 2014.12.


Updated by Robin Mills about 5 years ago

  • Assignee changed from Andreas Huggel to Robin Mills
  • Target version changed from 0.26 to 0.28

I'll deal with this in v0.27 when I update to the latest XMPsdk.

Also available in: Atom PDF