[Playlist] new rev

[Sebastian Pipping]

Let me just dump a few thoughts about the status quo
of XSPF here.  Feedback is appreciated.


== In this mail ==
1. Location ranking
2. Location mime type
3. Tag spelling fixes
4. Broken attribution concept


== 1. Location ranking ==
For a track with several locations it's currently not
possible for an XSPF processor (e.g. audio player)
to tell which location will likely result in the
best human experience.  It's not possible because
(native) XSPF does not allow specifying a quality
ranking of a location explicitly and because there
is not defined implicit ranking.

How about defining an implicit ranking like this:

  Where several locations are given the quaility
  should decrease from first to last, so the highest
  quality version always comes first.  This way
  software only working with the first entry will
  not result in a reduced user experience.

  For multimedia files (e.g. combined video and
  audio) quality should be ranked with respect
  to the dominant component of that file.
  For instance for a clip of somebody reading
  the news, audio might be the dominant component
  while video might be the dominant component
  for a dancing competition recording.


== 2. Location mime type ==
Let's say you run a Linux distribution which for legal
reasons comes without support for MP3 decoding.  Some do,
I think Fedora is one of them, not sure.
If a track's location would carry mime type information
with it, an audio player taking care could ignore a
location pointing to an MP3 file as it cannot play it
anyway.


== 3. Tag spelling fixes ==
Today I noticed again how bad <trackNum> and <trackList>
fit into an otherwise consistently lowercase naming.
Especially <trackList> and <playlist> together bite hard.
If there ever is a successor to XSPF-1 I personally
want (backwards-compatible) support for <tracknum>
and <tracklist> tags.


== 4. Broken attribution concept ==
With the current concept of attribution support
a derivative playlist is created by moving
either the playlist's <identifier> or <location>
into <aatribution>, e.g.

   <playlist ...>
     ...
     <creator>Leonardo</creator>
     ...
     <identifier>v1_identifier</identifier>
     ...
   </playlist>

is extended to

   <playlist ...>
     ...
     <creator>Mona Lisa</creator>
     ...
     <identifier>v2_identifier</identifier>
     ...
     <attribution>
       <identifier>v1_identifier</identifier>
     </attribution>
     ...
   </playlist>

Notice that <creator> is holding the name of the author
of the latest version of the playlist file, same applies
to <license>.  To find out the creator or license of
any earlier version one has to find an original copy
of this very version's file and look it up from the inside.
In some or even many cases this might work, but what
if this original version has been moved or even deleted?
In that case neither license nor author can be determined.

That's not cool.  I'm aware attribution probably is one
of the least-used features of XSPF but as it seems
inherently broken I feel like we have to fix it on the
next occasion.  How do you feel about this?
Is there a way to fix this backwards-compatibly?



Sebastian