Not all formats support all "standard" metadata options, and not all files contain all possible metadata. You would at least need query functions for each item to say "is it available". Maybe even a different query function to ask "is this item supported by the format"... those are not necessarily the same thing.

Sorry I meant to say the plugin *mechanism* is format neutral. Meaning it can handle any kind of format with any arbitrary metadata. Specific plugins are of course format-specific.

We do a fair amount of processing on the XML without specific code to interpret the items (think XSLT here).

The bottom line is, it's a part of a standard that's embedded in the JRE so it's unlikely to change and almost certainly will not go away (for compatibility reasons). Which is why I suggested a wrapper interface... make it easy to use without affecting existing API's. Practically speaking, changing the API would mean that someone would have to write a new interface for each existing plugin... and that's pretty unlikely. That's why I think a wrapper (which can be used with any plugin that supports the generic interface) is the way to go. Maybe not the ideal design, but we don't exactly have a clean slate here.

Well we have a different definition of "easy". ;-) The problem with that as a general design philosophy is that it assumes that the interface writer is rigidly following the naming conventions... that can be a fairly dangerous assumption.

Yep.

-Bob