Properties used to be simple. They used to be just a name and value pair, like these:

firstName = Ryan
lastName = Lowe

You could store these name-value pairs in a Java Map, and get the values using the name as the Map key. Then id3v2 came along and complicated matters. id3v2 has many properties using keys comprised of more than one value.

A simple example is the Comments frame of id3v2 -- frame ID of COM or COMM -- which can exist multiple times in an id3v2 tag as long as the language and description fields are different (Here's a list of all of the id3v2 frame types). Three fields then become the property key -- id, language, description -- and uniquely identify the property. An application like iTunes uses the key:

id=COM
language=English
description="" (blank)

for the "default" comment -- the one that shows up in the UI. Possibly for other language versions of Mac OS X the language changes, I can't be sure about that. It also uses two other comments to store some iTunes-specific values:

id=COM
language=English
description="iTunNORM"

id=COM
language=English
description="iTunes_CDDB_IDs"

WinAmp is lazy and just picks up the first Comment frame instead of looking for the one with the blank description. So the first could be the user-entered comment or one of this iTunes ones with data in it that doesn't make much sense to a user. The spec says that the comments should be sorted by importance.

Maps are handy for storing properties and I want to keep using them. But my property keys are going to have to get a little more complicated to handle these types of properties. I also want to keep it simple for simple situations though -- the Map should still support regular one string names for keys as well. Of course in a Map all of the keys need to be unique.

---

That's not all. The UI has to be able to know what a valid key looks like. To do that I have to be able to describe keys and the elements in them. In the example above valid id and language values come from a known set (ie. enumeration). The UI could display this set as a dropdown box. The description field is a little more free-form and can even be blank.

In other id3v2 properties some of the keys are numbers that have to be within a certain range or cannot be empty. Expressing these restrictions could be a little tricky...

I don't want to get too far ahead of myself but at the same time I don't want to trivialize metadata properties by thinking they are always easy name-value pairs.

It might be nice to start with a basic name-value pair-based GUI for Durham but at some point Durham is going to have to support these "advanced" kinds of properties as well somehow. Hopefully sooner than later because great id3v2 support could really be a killer feature of Durham and the next AudioMan.

I know Roy's definitely been clamoring for great id3v2 support. ;)