[Playlist] Playlist and Metadata format specs
ian c rogers
ian at fistfulayen.com
Mon Mar 8 21:30:43 UTC 2004
Yes, the two pages were reversed. My mistake. Apologies. Fixed.
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
1. I haven't seen anyone arguing pro anything but XML. If there is an
argument against, lets hear it.
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.
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.
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.
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?
Robert Kaye wrote:
> On Monday, March 8, 2004, at 09:07 AM, ian c rogers wrote:
>> Dave Brown took a first pass at the specs for both Playlist and
>> Metadata. I put 'em in the Wiki. Comments, please:
> [ Does the content of these two pages seem reversed? ]
> I was hoping to work out the requirements in detail before throwing
> around specification drafts. But, here are my comments anyway:
> 1. Simply assumes XML. It does not take into account the previous and
> current discussions on the right format to use.
> 2. It does not address playlist portability at all. There are no
> references to files, URIs or URNs -- no support for canonical
> identifiers. This format is weak for resolving content, which is the
> key to this new format.
> 3. It ignores the previous work on defining metadata standards. A good
> specification should do its best to reinvent the least amount of
> things. Dublin core and MusicBrainz Metadata should be used because
> these 'standards' have already done a lot of work defining the basics
> we're talking about here. KISS includes not reinventing the wheel.
> 4. It does not use international standards for specifiying simple
> things like dates and times. (ISO 8601
> 5. It supports composer, but it does not fully support classical
> music. What about the opus? Conductor? Orchestra? Performer(s)? We
> need to decide to support classical music fully or not at all. There
> is no in between.
> 6. It is not good XML -- the x-type tags are not how new tags are
> added to XML specifications. The whole point behind XML is to be able
> to add new elements at a later point in time, and using x-type tags is
> not using XML's best features.
> Please, if you must post specifications, please please please have
> them take into account the things we're currently discussing.
> --ruaok Somewhere in Texas a village is missing its idiot.
> Robert Kaye -- rob at eorbit.net -- http://mayhem-chaos.net
> Playlist mailing list
> Playlist at lists.musicbrainz.org
More information about the Playlist