I agree and that is exactly why PL5 uses an xmp sidecar file in all circumstances where the metada is written back to a RAW image. JPG, TIFF and DNG get the embedded metadata updated directly.
And where does the metadata for the Virtual Copies go!?
Sorry but I see no special reason for changing the way that it currently works, except to provide an emergency option to use the DOP metadata from the [M]aster image in emergencies! I do not have an aversion to data being in more than one place but do have an aversion to SPOF (single point of failure).
The dangers of replicake (sorry replicate) data (if I use that one more time in a post I should be fined) I fully understand but the dangers are more about strict coding standards than anything else!
That is exactly what happens. The fiasco I referred to above is that PL5 “abandoned” the use of the metadata for the [M]aster from the DOP (which it continues to maintain, correctly in my opinion) and now takes that data from the image metadata but failed to make that obvious to all users at the release of PL5 and many users fell into a “trap” by assuming that things worked the same way as PL4!
PL5 will read the metadata from the xmp sidecar file and from the xmp embedded in the RAW (I believe that the existence of the sidecar file automatically ends the search for metadata, whereas I would prefer a mechanism controlled by timestamps, i.e. the data with the latest timestamp “wins”), just as you stated.
But what do you mean by “rewrite the xmp file”, I understand you are referring to the ‘xmp’ sidecar file but what scenario are you referring to in this case.
Currently if the xmp sidecar file is lost and the PL5 database is intact it is in a position to be able to recreate the sidecar file but all of this then depends on the options you have selected for metadata handling in PL5, i.e. AS(ON) or AS(OFF) and the use of ‘Read from image’ and ‘Write to Image’!?
I haven’t actually tested this exact scenario (I will add that to my list after some DIY) to know exactly where PL5 will choose to take the data from, i.e. will the database always win out, or will the embedded metadata win out (if any exists) or will timestamps play a part (extremely unlikely!).
You get to choose the options AS(ON) (‘Always Synchonize’ = ON) or AS(OFF) in the ‘Preferences’ and regardless of the option setting you can always use ‘Files’/‘Metadata’/‘Read from Image’ or ‘Files’/‘Metadata’/‘Write to Image’ but these operations replace the database data or the image data completely.
Please see my post at PL5.2.0.4730 Conflict Resolution only detects externally generated conflicts for the options I would like to see added to PL5 to further improve its metadata handling.