Bug #751

adobe xmp namespace

Added by Adrian F over 6 years ago. Updated almost 2 years ago.

Status:ClosedStart date:17 Jan 2011
Priority:NormalDue date:
Assignee:Robin Mills% Done:

100%

Category:xmp
Target version:0.26

Description

http://ns.adobe.com/xap/1.0/ is now registered with the prefix xmp rather than the previous prefix xap. A consequence of this is I have old files with ratings described using xap:Rating i.e.
"http://ns.adobe.com/xap/1.0/" xap:Rating="4"

and new files with ratings described using xmp:Rating i.e.
"http://ns.adobe.com/xap/1.0/" xmp:Rating="4"

At startup I initialise exiv2 to avoid thread-safe issues and so http://ns.adobe.com/xap/1.0/ is registered with the prefix xmp. If I then read several files some of which use the xap:Rating style and some use the xmp:Rating style in more than one thread the conflict between the prefixes causes many non thread-safe re-registration attempts in exiv2 and memory exception throws in the xmp sdk. I think the root cause of this is the fact both exiv2 and the xmp sdk use one to one maps to represent prefix URI pairs and because of the prefix name change in the xmp sdk there is no longer a one to one relationship between http://ns.adobe.com/xap/1.0/ and a prefix.


Related issues

Related to Exiv2 - Feature #742: External XMPSDK and/or XMPSDK 2014.12 Closed 23 Nov 2010
Related to Exiv2 - Patch #786: thread safety of xmp toolkit Closed 10 Aug 2011
Related to Exiv2 - Feature #941: Upgrade xmpsdk source to Adobe's current version Assigned 27 Dec 2013
Related to Exiv2 - Bug #1113: Crash in Exiv2 0.25 Closed 31 Aug 2015

Associated revisions

Revision 3914
Added by Robin Mills about 2 years ago

#640 #751 Fix to test suit to prevent crash in exiv2json -x test/data/BlueSquare.xmp (see #751 for discussion)

History

#1 Updated by Andreas Huggel over 6 years ago

Yes, the issue is the globel registry for namespaces and prefixes.

Fixing this probably requires changes in the XMP-SDK as well as Exiv2 itself. We should upgrade the XMP-SDK (#742) and check if the issue is fixed there (according to comments in the code the Adobe developers are aware of this too) before attempting to fix it ourselves.

#2 Updated by Robin Mills about 2 years ago

  • Category set to xmp
  • Status changed from New to Closed
  • Assignee set to Andreas Huggel
  • Target version set to 0.26

I'm going to close this. I've associated this to #941 which is the project to upgrade the version of Adobe XMPsdk being used by Exiv2.

#3 Updated by Robin Mills about 2 years ago

  • % Done changed from 0 to 100

#4 Updated by Robin Mills about 2 years ago

I discovered that exiv2json was crashing on test/data/BlueSquare.xmp. That file uses xap and xapMM. Changing to xmp and xmpMM fixed the crash (r3914).

XMPsdk maintains two maps prefix->URI and URI->prefix. By maintaining both, Adobe are attempting to guarantee that no URI is used by more than one prefix, every prefix is unique. This assertion isn't always true. XMPMeta::DumpNamespaces tests that the size of both maps are the same. There are two "orphans":

xmp: ---> http://ns.adobe.com/xap/1.0/
xmpMM: ---> http://ns.adobe.com/xap/1.0/mm/ 
The reason for the "orphans" is because src/properties.cpp and xmpsdk/src/XMPMeta.cpp both (correctly) register the namespace prefix xmp and xmpMM. Then the file BlueSquare.xml contains the code:
    xmlns:xap="http://ns.adobe.com/xap/1.0/" 
    xmlns:xapMM="http://ns.adobe.com/xap/1.0/mm/"
XMPsdk then updates its maps. Of course the xap and xapMM are new and unique, however the URI is not. It's a pity the library doesn't throw when when RegisterNs is called and it's only detected by DumpNamespaces.

I was unsuccessful in trying to fix this in xmpsdk in XMPMeta::DumpNamespaces by trying to sync the two maps. Don't know why that didn't work, although I didn't want to touch the Adobe code anyway. I suspect the latest version of Adobes XMPsdk will have some magic to deal with this.

#5 Updated by Robin Mills about 2 years ago

  • Status changed from Closed to Resolved
  • Assignee changed from Andreas Huggel to Robin Mills

I'm going to re-open this and mark it Resolved/100% - just to keep it visible for the moment.

#6 Updated by Robin Mills almost 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux