This is extremely basic file management stuff. The important thing is that the raw file is the parent and exported files children of said raw file. The file name including path implies relationships, if your file management breaks semantic relationships you’re simply doing it wrong.
The two most common conventions is to append to the file name or create a sub folder. Both these conventions express the relationship between the files. If you need side car file for the exported files a subfolder the choice. If you export child files that embed xmp data you can append info to the file name. I suspect that the correct way is the subfolder as that mimics the xml PATH. In the below samples the child files can have additional meta data to the parent.
It’s linked to and discussed in other threads. dt devs have been arguing that you could interpret the standard in a way that differs from the actual standard as implemented by the rest of the world and as consistent with xml path names.
The reason is that they find the use case enabling individual edits of files with identical base names more important than meta data compatibility.
A standard is not a legal text to wrangle and interpret to enable incompatible behaviour. The text and actual implementations makes for the actual standard.* A few foss applications are the only ones using the ext.xmp file naming.
*I know Microsoft and others has a long habit of misinterpreting standards to enable lock in. There’s no reason for darktable to do this however.
It’s been discussed and my point is independent of, but supported by, the written standard. You’re asking the wrong question and it’s already been answered. Yet you’re asking me to feed you readily available irrelevant info?
Playing word games with the standards text is meaningless when there are huge amounts of existing software using the de facto standard. This isn’t new stuff it’s old. The software we’re talking about isn’t user focused raw editors such as Lightroom either.
The question about the standard is overrated anyway. If a standard is nonsense, it will not be adopted in real applications anyway. And sometimes, even non nonsense standards are not adapted. Check how many Ethernet standards have been released, and how many of them have been widely adopted …
If the xmp is not needed to store processing information, darktable may anyway not be the right tool. I personally think the decision of the dt devs regarding xmp naming was correct for technical reasons. The original idea of multiple source files and maybe edits in a single xmp makes no sense unless these files are never touched by people. But many of the users rely on their own scripts to handle files outside of darktable, therefore it’s imo the best compromise how it is implemented.
In this case it’s very much adopted. Massively adopted. There shouldn’t be any doubt about this by anyone working with media files.
To scratch the surface just look at all available raw editors. Then proceed to advanced image viewers and most importantly dam tools. The discussion is absurd as it’s so easy to verify. The back end dam systems are naturally more opaque but there’s no need to go there.
As has been said before, this discussion has been done. Many times. Let’s not have another locked thread please, because the lines have been drawn and nobody is changing their minds.
@luap Welcome to the forum. Hope you enjoy your stay.
Personally, I am old school. I organize by file name and directory tree. I dislike sidecars and delete them when they appear. If I were to rate and tag files, I would either include them in the file name or keep them in a human readable text document. Could be XMP, JSON, simple TXT, even extension-less: what matters is that the rating and tagging is done to my specs not some application’s. That way, I have full control of what gets written and could convert the data to whatever format I want in the future because the file would not be encumbered by special or confusing structures[1].
[1] E.g., XMP is a standard but there is too much wiggle room that rating/tagging often isn’t transferable or readable across applications.
Perhaps, and I agree to sticking with XMPs, but I have encountered situations where transfer was not possible; hence the OP’s questions. Just giving a third option, which is to take a detour off of the beaten path.
For applications that need to find external XMP files, look in the same directory for a file with the same name as
the main document but with an .xmp extension. (This is called a sidecar XMP file.)
I have two remarks
first: The whole part 3 concerns metadata i.e. a set of data that describes and gives information about other data. BUT, the DT XMP sidecar cannot in any way be considered as a description of the raw photo. It contains neither the circumstances of the photo, neither the scene description, the author, the camera parameters or whatever is needed. So the part 3 cannot be applied to the DT sidecar.
second: it is clear that the very concise and general external storage paragraph is just not a concern for the writers. It refers here to a “main document name” and NOT to a “main file name”. It is ambiguous. Would it be “main file name” as I suppose, it would not be ambiguous as a file name is composed in usual OS of the base name and the type. See Filename - Wikipedia
So following strictly the standard, the sidecar of photo.raf has to be named photo.raf.xmp.
I have absolutely no professional experience. But if you can avoid collision in the base name of main files, you can use this naming scheme without risk. that’s not the case for my modest photo and video asset.
Furthermore, strictly speaking, the DT XMP is a metadata of the output file that is produced by DT and thus could be embedded in it.
YES! But the discussion can stay friendly, at least I hope that
The sidecar from dt certainly has metadata in it. It isn’t clear how you’re defining the term “metadata” but dt’s sidecar certainly contains metadata and it is definitely XMP style metadata.
It is not. It contains color labels, rating, author, creator and many other tags not concerned with processing nor output.
OMG this discussion seems like this “I know better” - “no, I (!) know better” endless one.
I think there are simply two valid use-cases since the standard provides some room for interpretation
use “filename with extension” as the basename to expand by “.xmp”
use “filename without extension” as the basename to expand by “.xmp”
Darktable currently supports 1., digiKam supports both and many commercial tools seem to support 2. only.
There are pros and cons for both. I also struggled with this incompatibility since I use excire (just 2.), digiKam (1. and 2.) and darktable (just 1.) together. No fun.
I did not have the time and programming capabilities to “simply” step through the code and propose a PR that enables the user to select if he wants to use 1. or 2. (like digiKam does). Perhaps in a first step without that very nice version support that might be added in a second iteration. But perhaps there is someone with better programming capabilities than me who would like to provide something as I sketched - just for fun
But the discussion can stay friendly, at least I hope that 
