Like many others in this biz, I've been following the development of Adobe's Extensible Metadata Platform (XMP) for quite some time, and for at least three years I've been saying that it would be in Adobe's best interest to hand oversight over this ostensibly open standard to a bonafide Standards Body (rather than let adoption languish as people continue to associate XMP with "Adobe-proprietary"). Happily, Adobe is in fact now doing the right thing: XMP is in the process of becoming ISO-16684-1, via an effort led by my colleague Frank Biederich.
This effort couldn't have come at a better time. The content world is in desperate need of an industry-standard way to represent rich-content metadata, and I strongly believe XMP is the right technology at the right time.
One can quibble over whether embedding XMP in a host file is the correct thing to do (as opposed to placing it in the file's resource fork, or simply creating XMP as a separate sidecar file and managing it separately). There are good arguments pro and con. But packaging issues aside, there's not much question, in my mind, that nearly every form of content benefits from having easily-parsed metadata associated with it. This is particularly true of enterprise content (content that's managed in some kind of access-controlled repository). The availability of metadata makes a given content bit easier to repurpose, easier to track, easier to search -- easier to work with all the way around.
At Day Software (now a part of Adobe), we've long had a saying that "everything is content." I'm fond of saying that once metadata is attached, "everything is an asset."
I think XMP is poised to become a huge success, comparable to, say, Atom or RSS. First of all, the specification itself is short and easily understood (thus easily implemented) -- always a Good Thing where XML standards are concerned. It's also semantically flexible and highly extensible -- again two very good things. The fact that it leverages RDF also bodes well for XMP as we trundle ever-closer to the Ontological Web. The social dimensions of an asset, for example, could easily be accommodated by XMP via RDF triples. Let your imagination dwell on that for a minute.
But I also think the timing for XMP is quite propitious just in terms of where it's at in its lifecycle. I was giving a talk last week at Adobe Research in Basel (on the subject of XMP) in which I mentioned a certain lifecycle theory (whose, I can't remember) that sees all technologies as basically going through three phases, each one lasting about six years. Phase One is Acceptance: It takes around six years for anything truly new to change the way people think about it. (During this period, only alpha geeks will actually adopt the new technology.) Phase Two is Adoption: It takes six years for the (at last understood) new technology to enter the mainstream in earnest. Phase Three is Ubiquity: This is when adoption becomes universal (or as close to that as it's going to get) and the market is saturated.
Not everything goes through an 18-year cycle, obviously. This is just a rough conceptual model, but I find that it applies in a surprising number of cases. If we look at XMP (which dates to 2001) through this model, we see that it is a little more than halfway through the Adoption phase. I think that the ratification of ISO-16684-1 will kick off a Ubiquity phase in which we see XMP used in more ways and in more places than anyone would ever have thought possible.
My talk last week in Basel was in front of a roomful of developers. Everyone there was familiar with aspect-oriented programming, so I made the (admittedly imperfect) analogy with XMP, saying "Imagine if resources could have aspects. What would that look like? It would look a lot like XMP." The info that gets packaged up into XMP often has to do with crosscutting concerns, like access control, DRM, version history, and what might be called "serving suggestions" (mimetype, compatibility hints). It's not that far different from an advice stack in JBossAOP. Even the packaging concerns are familiar from AOP. A classic problem in AOP, after all, is where to put aspects: in the source code itself (as annotations), or in separate descriptors (as in JBossAOP)? The same concerns (and tradeoffs) arise with XMP.
In any case, I think the pressing need for more and better metadata (as it pertains to enterprise content in particular) plus the built-in (in many cases) support for XMP in cell-phone cameras, plus the need for ontology-friendly web formats going forward, and many other factors (including the opening up of XMP under ISO-16684), spell a perfect storm for XMP as we hurtle toward Web.Next. All I can say is: It's about time.
