Here’s the thread if anyone is curious: Exchanging with darktable
Ah so someone actually found it spelled out in the spec that xmp should replace the original extension. It was always obvious, if not from the existing implementations, but literal minded people on this board insisted that it was unclear. (As if it matters what the spec says when the world has settled on a de facto standard).
I doubt dt will change though.
dt won’t change. PhotoMechanic is considering it, as written in the post above.
Not sure where you’re getting this from. People here said the spec was a bad decision in this regard.
It is spelled out, but buried in a completely non-intuitive place in the “spec”. The first location where the file name convention is discussed (which is where it should be spelled out) is incredibly ambiguous, leaving it up to the reader what is meant by “filename”.
I wouldn’t go so far as to say “literal minded people” thought it was unclear. In a filesystem, every file must have a unique name. The canonical path to the unique file being itself unique, such that:
- /path/to/some/file.ext
is unique and different than:
- /path/to/other/file.ext
despite both files being named “file.ext”. Within a particular directory path, however, one can not have two “file.ext”, therefore, saying “the filename with an extension of .xmp” is ambiguous if you have both “file.ext1” and “file.ext2”. As many here have pointed out, if you have to files with the same name but in different formats, this scenario is a possibility. However, the argument that those two files consist of one RAW and one JPG is invalid, since JPEGs store XMP data internal to the image file itself whereas RAWs do not.
A more convincing argument would be what if I had both IMG_1234.CR2 and IMG_1234.NEF. The probability is small, but not zero.
It would make perfect sense on the part of (all) application developers dealing with XMP data and reading/writing XMP data to provide a user configurable file name format option with a reasonable default.
Most applications would likely default to .xmp, but could provide the option letting the user set it to ..xmp. And if DT wants to be the odd-ball in the industry because DT knows better than everyone else, they could default to the latter, but appease those who care by allowing them to change it to the former.
If PM comes through and supports this request, but DT remains obstinate, I will think far more highly of PM as a result. One thing I’ve learned in my 30+ years involvement with the open source world is that they can at times be incredibly arrogant and stubborn, since they have no paying customers to make happy. Say what you will about proprietary software, but they will usually give the customer what they ask for if there’s money to be made by doing it.
IMO, there is no reason NOT to support the standard, even if you think it’s a stupid standard. Support the existing standard, at least with configurable options, and then show the rest of the world the better way by defaulting to what you think is right.
–
Paul - Not really holding his breath for either side to give in on this :-/
I’m curious would this not have been done so that if someone read in a folder with nice LR or other software generated xmp files that they could then not somehow get overwritten/corrupted by DT if it also used xmp files… I have never owned lightroom so I have no idea how much of an issue this might be… is that much that is useful that you can get from LR or other xmp … I guess maybe the tags and ratings will flow into DT without too much of a problem…
Is the problem that DT might as well have used a totally different identifier but since they used xmp it should be done as other software has decided to do it??
As a linux users, I’m not overly concerned what Photomechanic, Photoshop and similar decide to use as “standard” 
(the cited programs don’t exist in a Linux version so far).
Because there’s another issue: many of the “commercial” players aren’t interested in providing for Linux (that includes drivers for hardware), where they do provide for MacOS (which has/had a similar part of the “official” desktop installations).
A program doesn’t have to understand all the tags in an XMP (XML) file; as long as it doesn’t modify the ones it doesn’t understand, everything is fine. The XML standards actually provide for that situation, as the aim of XML is data exchange between programs…
THX …sounds good in a perfect world. 
As far as I know dt is the only imperfection in this xmp world.
Do note that reading edits from other software is of no interest. It’s the medadata such as tags that should work across software.
For years it was proprietary software that refused to follow standards and made spurious exceptions to ensure lock in. Can’t see how following those same footsteps is a dignified revenge.
But there it was about official (ISO) standards. Here we are dealing with a apparently poorly worded document from a proprietary software company.
Also, I know about at least one other program (digikam) that uses the same convention as darktable, and for pretty much the same reason. The main thing is not so much to distinguish between file types, but between versions. If you stick to simple .xmp you cannot distinguish between different versions (think of a way to use such sidecars in e.g. the playraws).
Different versions have the same capture metadata and usually the same content. When it no longer has the same content (cropping people out) as the parent raw file it makes sense to rename it (append versioning to the file name).
The issue has no bearing what so ever on playraws because tagging and metadata has never (in my time on pixls) been a topic of playraws. It would make for a very boring playraw 
Again the issue of saving edits can be solved in lots of different ways. It’s just important that the xmp standard isn’t mangled to achieve it. Storing edits in xmp is at best a secondary function of the standard and one who’s utility is very limited.
xmp is part of the whole xml metadata initiative such as dublin core and xhtml (back in the day). Abusing it to make it fit some niche editor use case makes no sense.
The iso standard was written by Adobe and if I remember correctly Digikam and Geeqie optionally use the filename.ext.xmp pattern only to work with dt?
Afaik, the ISO part only covers part 1: the data model, serialisation and core namespaces. It does not cover the other parts, among others the file naming conventions.
What? The X in XMP is for “extensible.” So the original designers thought it important, or they wouldn’t have made it extensible.
XMP is the specification of an XML dialect for metadata. Dublin Core is a specific namespace for XMP. XHTML is not specifically metadata and doesn’t have much to do with this.
That’s why I said secondary. Initially edits weren’t saved in xmp format. It was just a sort of hierarchical exif type thing following the xml trend. Naturally it’s very important for a metadata scheme to be extensible and as you know it’s the basis of those xml related initiatives I mentioned.
xhtml was an attempt to bring html closer to xml so that it could benefit from being a markup language rather than a hacked together presentation language. Xmp comes from that same era when everything was made xml to structure data and information. I’m pretty sure you know this.
There’s no getting around that xmp was designed as a next gen exif that would enable images to carry richer and more structured metadata for search, archiving etc. Of course it was extensible and of course Adobe who wrote it used it for storing edits before dt. They didn’t break xmp for that fuction so it’s all good.
I do, you’re the one who incorectly conflated XHTML and metadata.
But not secondary. A huge part of the original design. Since its extensible, it can incorporate past and future metadata in an XML form to provide compatibility.
Huh? XHTML was brought about (not an attempt) to provide a stricter subset of HTML that could be validated against a DTD. HTML is a markup language and so is XHTML. Its a mix of structural and presentational.
The extensibility isn’t secondary but the use case as raw editor “config”. Naturally if done right it’s fine to do so. I can be considered metatada and xmp is extensible to allow new and unforseen uses.
You’re just saying what I just said but formulated for people who know those words. I’m know them but don’t think it adds meaning for this context. You’re marking words and going for irrelevant specificity to sidetrack the discussion. Simply put:
Xmp was designed for digital asset management.
Yeah, no. You should choose your words more carefully.
You continually saying something to the effect of “I’m right” or “that’s what I said” when you’re not right and that isn’t what you said is disingenuous.
Other than that, I think we are done here.