P: Store the xmp metadata outside DNG, jpeg etc file to be backup efficient

I know the price of backward compatibility in software devloppement.

But some time we need a breakthrough to stay connected with current technology.
Now a days cloud save is very widespread and accecible.

XMP is a xml style file and a simple new tag "" could make the job and correct the colision of MyFile.RAW and MyFile.JPG and MyFile.TIF that now could have xmp file that doesn't named MyFile.XMP.

With this kind of tag older engine can ignore this function and continue to use the file.

For some exportation, the xmp external would be embedded back inside like synchronize meta data function in lightroom.

This feature will be very appreciated for backup efficienty (low drive writeback, low delta data, original file untouched since the external declaration)

Benoit

I agree 100%.

I also acknowledge that the problem is more complicated than it seems at first.

As currently defined:

MyFile.RAW and MyFile.JPG and MyFile.TIF.. would have the same xmp filename.

I realize the problem is solvable, but due to it's impact on other apps etc, would be a can of worms.

Bottom-line: Adobe screwed up (yeah: that's my opinion) by not including the original extension in the xmp filename, but it's a screw up which would be hard to rectify at this point. Easy I mean, in a closed/self-contained environment, but legacy compatibility must also be maintained, so other apps aren't broken.

Don't get me wrong, I still vote for a remedy, and in another decade (probably two) we'd all laugh about the problems it caused at first..

That said, I think the fact that Adobe chose NOT to include the original extension in the filename represents a firm commitment to go with embedded xmp in all cases where it's supported, and think of sidecars as an unfortunate exception. If I'm right, then the fight for sidecars is a losing battle - hope I'm wrong.

FWIW: there *are* some apps which use sidecars for all file-types, and *do* include the extension in the filename. It works rather well, but these non-standard sidecars do not interoperate with apps which only support standard sidecars (like Adobe's). Note: these apps do NOT support embedded xmp.

When both embedded and non-embedded must be supported, the problem is exacerbated - for example: there would not only be the potential issue of metadata conflict between xmp and Lr catalog, but embedded xmp and non-embedded xmp too...

I can see why Adobe would not want to touch this problem with a 10-foot pole.

Rob