Adobe is pushing for XMP to become the metadata format for the OASIS OpenDocument format, and Leigh Dodds just posted some notes on his review of XMP. He covers the XMP-RDF relationship issues better than I could. He also refers to my article on XMP published in XML.com over a year ago, in which I wrote this:

For now, the use of XMP means either depending on commercial vendor tools or being comfortable with C++ so that you can use Adobe’s SDK, but this is changing. Activity in the XMP User-to-User forum shows that open source Java tools are on the way, which will make it much easier to incorporate the use of XMP into production workflows—for example, to extract the metadata from a batch of images and then load that data into a database.

I’d like to revise that:

The use of XMP means either depending on commercial vendor tools or being comfortable with C++ so that you can use Adobe’s SDK.

As Leigh wrote, “The ability to embed metadata in arbitrary binary document formats is a huge benefit” of XMP. I’ve always thought that XMP had great potential to be a bridge between the often overly-academic world of RDF and the world of commercial media production. It’s too bad that while Adobe is very interested in corporate tool support of XMP, they’re not interested in building the kind of grass roots tool support that would make XMP much more useful and therefore popular.

When Adobe representative Alan Lillich recently made the case to the OpenDocument TC for XMP to become the metadata format, he included a section “About the Adobe XMP SDK” that neglected to mention that it’s limited to use by C++ programmers. When he writes that the “revamped API… [is] much easier to use” I assume that he means that some class libraries have been refactored and the documentation has been improved. (I just downloaded the current SDK again to check, and it’s mostly cpp, hpp, and html files.)

If Adobe looked at the effort that Amazon and Yahoo have put into encouraging application development by part-time programmers using popular scripting languages, they might get some ideas about spreading the popularity of the XMP specification. If Adobe had a wrapper for a popular scripting language around the C++ based binaries two years ago (note that XMP is over four years old), by now flickr users would be clamoring for flickr to pull XMP metadata from their pictures and post it on each picture’s page, as many flickr users did for EXIF metadata. I know that if Adobe offered a python or perl binding, I would have written some apps to insert and pull XMP metadata by now. I did some C++ coding in school, but setting up a C++ environment (free or otherwise) and getting up to speed with it would take more time than I have available. It would take less time, if Adobe offered a Ruby or PHP binding to the API, for me to finally settle down and learn either of those languages.

I’d like to see the OpenDocument TC push for a stronger commitment from Adobe to support grass-roots XMP app development before the TC adds metadata structures to the OpenDocument formats that are, for now, mostly geared to use by tools from Adobe. (I’ve seen lists from Adobe of companies that claim some support for XMP, but a URL like www.kodak.com doesn’t tell me much about what that company’s support is.) Without easier ways to use XMP metadata, I don’t see much payoff to the TC for making it part of the OpenDocument format.