adobe xmp namespace
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.
and new files with ratings described using xmp:Rating i.e.
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.
Updated by Andreas Huggel almost 9 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.
Updated by Robin Mills about 4 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.