xmp handling faults (I) - 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 not set.
- Open the image in some application using libexiv2 for metadata handling like Digikam and see that Dublin Core Schema property 'creator' is set to 'Bugs Bunny'. Same for 'exiv2 -pa'.
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 almost 3 years ago
- Subject changed from xmp handling faults (I) to xmp handling faults (I) - 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://myapp.org/dc/elements/1.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. I suspect that many, if not most, users would 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.