Bug #789
xmp handling faults (III) - AKA: policing XMP namespaces
0%
Description
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
Related issues
History
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.25
Updated by Alan Pater about 6 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/
http://www.exiv2.org/tags-xmp-xmp.html
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.
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.