RE: XML

Jeffrey Baker (jwb nospam at cp.net)
Tue, 9 Mar 1999 10:25:59 -0800

> >>>>> "MO" == Mike Oliphant <oliphant nospam at ling.ed.ac.uk> writes:
>
> MO> Why XML? Let's be realistic here. 99% of users are going to
> MO> just want disc title, artist, and track names. Not to mention
> MO> that I don't want to have to write a stack-based parser just
> MO> to be able to do disc lookup.
>
> I'm sort of with Mike here on this one. While XML is sexy and cool
> and you could do all sorts of nifty things with it, it's far better to
> have a quick, fast, easy to understand and easy to parse format. Such
> a format would _encourage_ developers to adopt the new DB code instead
> of the old cddb stuff.

If anyone could show me a format that isn't based on a relational database,
and has a significatly lower byte count that the corresponding XML, I might be
swayed. If I was a CD-player developer, I would love for an extensible format
to arise, because I could use it to differentiate my player from the other
players.

> If you're going to go with XML, be prepared to offer precoded engines
> to everyone that they can just link in to their player code with a
> simple set of API's.

lib-dmi. Cool. (that's digital media index, for those who missed it)

> On second thought, that's not too bad of an idea. You could supply a
> reference library (for _everyone_, not just the unix-heads in the
> crowd) that used a standardized API and provided a precoded parser.

Well, for us unix-heads, there is a nice lib-xml. The GNOME project is using
it successfully.

As for driving away developers, we could offer our core service of XML via
HTTP for new, sexy clients. Requests that come in for the CDDB protocol could
be handled by an XML-CDDB parser. That would allow us to transition the CDDB
clients to the new service immediately.

Later,
-jwb