xmp handling faults (III) - AKA: policing XMP namespaces
This entry is for seperating xmp handling bugs from xmpsdk upgrade for easier tracking.
Steps to reproduce:
- Take some image, clear all metadata with 'exiv2 -d a'
- Set XMP Basic Schema property 'Label' to 'Orange' with 'exiv2 -M "set Xmp.xmp.Label Orange"'
- Set XMP Basic Schema property 'Rating' to '3' with 'exiv2 -M "set Xmp.xmp.Rating 3"'
- Open the file in some xmp conform application like Adobe Lightroom or Nikon ViewNX2. Verify that Rating and Label are set
- According to http://dev.exiv2.org/boards/3/topics/687 it is approved to register your own namespace and set some property in there 'exiv2 -M "reg xmp http://ns.imagapp.pro/imageapp/v1/" -M "set Xmp.xmp.uuid ab75b096-83d3-11df-91a5-000c2953179a"'
- Open the file in some xmp conform application like Adobe Lightroom or Nikon ViewNX2. See that Rating and Label are gone
Updated by Alan Pater over 3 years ago
- Subject changed from xmp handling faults (III) to xmp handling faults (III) - AKA: policing XMP namespaces
- Assignee changed from Alan Pater to Andreas Huggel
According to the XMP specification, the correct namespace for xmp is http://ns.adobe.com/xap/1.0/
Step 5 overwrites the pre-registered XMP namespace with a different URI thus causing the apparent loss of the Label and Rating.
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.