[Playlist] Playlist and Metadata format specs

Matthias Friedrich matt at mafr.de
Mon Mar 8 23:24:04 UTC 2004

On Monday, 2004-03-08, ian c rogers wrote:
> I appreciate that you were trying to work out detailed requirements 
> first.  I like working with examples and there was call from Lucas that 
> echoed my feeling here, so we went ahead and kicked something out 
> there.  I actually think that by example is a great way to get to the 
> point faster.  Look at how quickly we surfaced many issues that we were 
> not yet addressing.  Lets address them one by one and find the best 
> solutions. 

With a lot of help by Rob (who is the expert, definitly not me), I
created a simple playlist example:


This is mainly a technical demo, to show that Lucas' RDF with fixed XML
serialization really works. See example.xml for the playlist.
example.xsl is an XSLT stylesheet that transforms this playlist to XHTML.
Nothing fancy so far, and no special layout. Click on example2.xml and
the stylesheet should be executed automatically and the resulting XHTML
page should be displayed.

An XML Schema or a DTD could also be created.

> 1. I haven't seen anyone arguing pro anything but XML.  If there is an 
> argument against, lets hear it.

XML for syntax is definitly consensus.

We heard arguments for XHTML but there's only one supporter so far.

Then there's the choice between using XML as a data model vs. using XML
as a serialization format for the RDF data model.

> 2. The desire is to create a format with support for multiple means of 
> identifying content.  The playlist format should not be tied to the 
> lookup mechanism, but it should not prevent the use of any and all 
> lookup mechanisms.  I don't think we're short-circuiting this discussion 
> here by suggesting a basic format.

Basically, there are two ways of identifying a track: using a resource
locator (like file://) or using a canonical identifier (like the
MusicBrainz URIs). Unfortunately, it isn't possible to know from an
URI like "http://www.mafr.de/whatever" if this is a resource locator
or canonical identifier. Therefore, we have to make this decision
by other means when reading a playlist. In the example playlist, I
introduced two properties (in RDF speech): pl:id and pl:cid (c for

> 3. You have much more experience with these other metadata formats than 
> we do.  Please shed some light on why they're better and how they might 
> be used here.  I agree we shouldn't reinvent the wheel -- remember that 
> my original question to you was, "If we could ask the world to use one 
> playlist format, what would it be?"  I didn't want to do any of this, 
> originally.  If existing formats are usable, lets use them.  Educate us.

Lucas has written a great survey that covers all popular playlists and
then some. Some are better, some are worse, but they all have a common
problem: It isn't possible to share playlists with others. They are not

Portability can only be achieved if a track can be identified uniquely.
Unfortunately, there could be many ID schemes (MusicBrainz being only
one) and you don't know which scheme is used. Probably many in parallel.
So a single track you list in your playlist maps to many identifiers.

> 4. We should support classical fully.  Also Punk Rock and Ugandan Tribal 
> Rhythms.  These were not meant to be definitive lists of fields, only a 
> start.  If everyone can start to add or suggest necessary fields given 
> what they know that'd be great.

Sorry, I'm no expert for classical stuff.

> 6. We'd love to hear what are considered to be the best practices here.  
> Your criticism doesn't suggest any alternative.  How do you suggest we 
> handle non-standard items?

If the playlist format is supposed to be used universally, we have to
take care that it isn't augmented or "improved" by certain vendors.
That's the root of all evil as you can see from all the problems HTML
had when two companies defined their own tags.

We have to decide if we want extensibility at all, and if, to what
degree. I think we definitly need a single DTD or schema that covers
*all* playlists. So custom defined tags aren't possible.
In RDF, it's pretty simple for anyone to add statements about a
resource. In XML you could use something like

<app-info application="fancy.app-v1.0" key="mood">depressed</app-info>

For our RDF + fixed XML serialization things are a bit more difficult.
I'll have to think about it some more.

Sorry if any of the above doesn't make sense. It's 0:30 here.


More information about the Playlist mailing list