Bug #788

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

Added by Jens Mueller about 6 years ago. Updated about 1 year ago.

Status:AssignedStart date:29 Aug 2011
Priority:NormalDue date:
Assignee:Robin Mills% Done:

0%

Category:metadata
Target version:0.27

Description

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) Jens Mueller, 29 Aug 2011 11:57


Related issues

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

History

#1 Updated by Robin Mills over 2 years ago

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

#2 Updated by Alan Pater about 2 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 http://purl.org/dc/elements/1.1/

The attached test file overwrites this with http://xurl.org/dc/elements/1.1/ 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.

#3 Updated by Robin Mills about 1 year ago

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

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

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux