> There was talk of extending it to include lyrics. But as it is, are
> there any objections to using that as the formal, very-difficult-to-
> change-in-the-future data type for CD information interchange?
XMl is inherently not difficult to change -- personally I do not see the need to take care of lyrics right this second. I think we've got other priorities. However, if someone feels very strongly about including lyrics right now we can do that. I suppose extending the DTD to do this should be no problem, even if we do not have code to support it. How about adding it in the DTD now for future use, but focusing the code we write on basic functionality?
> The issue for developing information adapters is only that you could
> build a valid XML document conforming to this DTD from any of the data
> sources. As I read it, it is possible to do this with freedb, since
> the IdInfo tag is optional.
Indeed -- having the data is a good thing, even if the data is not associated with a particular DiskID. It is trivial for a user to add a new association to a CD if the data is available, as opposed to having to type in all the data.
> As it is, I'm happy to take what's in this DTD and write an API around
> it for submission and fetching. The lower levels of the API, for
> parsing SCSI TOCs and launching web browsers (in case the CD player
> doesn't want to present the UI) can be worked out later.
I met with Marc in Cologe few days agao and he is also interested in writing this API. I remember last time you guys deadlocked on a few issues that were never resolved. I would very much like to see all of us work together to come up with an API that meets everyones needs.
I would like to offer my services as a moderator to settle any differences that arise. I would prefer this over the standard 'the first person with code wins' attitude. I think this will serve the community best.
Today will probably be the last you hear of me until I return to work in the states on monday. (using a *real* keyboard then!)
-ruaok