Bug #788
xmp handling faults (II) - AKA: policing XMP namespaces
0%
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.
Files
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.26
Updated by Alan Pater about 6 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.
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.