This is the case for most of the "more engaged " iptc users (xmp files by a older dam like bridge) and more professional dam software users would be mift if it “writes” self made iptcmetadata in export files as jpeg/tiff destilated from the xmp files of say imatch (even when "synchronize metadata is off.)
i have a simple and small database so a few day’s/weeks work to repair a corrupted dam system will be getting my mood in a dark place but it’s not work related so it doesn’t cost me money.
any other professional user would be not be pissed off but furious if it’s database is mashed to pieces.
Once bitten you tend to stay away to avoid a second time.
So that can cost you fanbase and users in the long run.
edit:
First modification step must be a “hierarchy of application set up in PL’s syncronizing xmp.”
Very important!!!
So you can set which fields it is allowed to alter/modify and which are “read only” a selectivity box like:
me i would say write at:
and i can change every time i like to change in preference.
(this is at this moment database only when sync is off.)
this way i can control the influence the dam from dxopl has and protect my xmp files wile i can still use some of it in my developers stage so i don’t have to switch all the time between external dam and dxopl.
this gives dxo pl the time to perfectionize the dam wile every one can decide for them selfs how much it diggs in there xmp’s.
Second modification is IF xmp sync is set active the DB MUST be Slave: no visual differences even on the NOT selected preferences i described above.