[Playlist] Playlist and Metadata format specs
rob at eorbit.net
Tue Mar 9 21:48:56 UTC 2004
On Monday, March 8, 2004, at 03:24 PM, Matthias Friedrich wrote:
> 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
>> 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
>> not yet addressing. Lets address them one by one and find the best
> With a lot of help by Rob (who is the expert, definitly not me), I
> created a simple playlist example:
Ha! Don't sell yourself short Matt!
> 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.
I vote for the latter -- I think we can come up with a tight XSD that
will allow RDF heads to parse this data with RDF and folks that are
worried about the footprint of the implementation to parse it with a
standard XML parser.
Plus, this is the cleanest way for us to leverage all the exising RDF
>> 6. We'd love to hear what are considered to be the best practices
>> 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
I feel where you are coming from -- the HTML standard has been beat up
too many times.
However, we need to plan for extensibility -- there is no question
about it. A good idea (IMO) allows for uses that the original creator
never thought of. This applies in this case here -- we cannot think of
all possible applications/formats of the playlist. This would hinder
the usefulness of this specification.
I think we should define a playlist namespace and then let users use
this namespace in combination with other namespaces. If someone feels
tempted to augment the pl namespace, they should do either:
1. Follow the accepted process for changing/augmenting the pl namespace
(i.e. discuss it here)
2. Create a new namespace for their own purposes that supplements the
Note that these two approaches are not mutually exclusive. I could see
someone doing #2 and then having the group adopt the change into the pl
That's how its supposed to work, right? :-)
--ruaok Somewhere in Texas a village is missing its idiot.
Robert Kaye -- rob at eorbit.net -- http://mayhem-chaos.net
More information about the Playlist