xmp handling faults (II) - AKA: policing XMP namespaces
|Status:||Assigned||Start date:||29 Aug 2011|
|Assignee:||Robin Mills||% Done:|
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.
#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.