Yes, what I think we need to do is this.

0. Agree that a XML file is the best way forward as a alternative method of outputting the playlist infomation currently available from the hijack kernel. I don't think we will hear too many objections to XML from Mark as its so much like what he's doing now with HTML and is the most 'platform' and implementation independant way of making this info available.

1. Decide amoungst ourselves what this XML output should look like, bearing in mind that Mark has said he wants to implement what we decide, but he does like the ?.xml idea to request xml output [assuming we agree on this point].
We need to bear in mind that the XML file will contain both [by design], both tunes and playlists - and should show the order in which the tunes and playlists should be mixed [relatively easy to do given that all tunes are in a playlist, and the playlist could itself contain playlists].

2. Address the issue of a [optional] xslt file to allow some browsers to format/process the XML as HTML or whatever the XSLT does [automatically], on the Client-Side.
I think that the request for a XML playlist could include a second parameter [like ?.xml&xslt=.... ] which could contain a URL encoded XSLT file location. Mark Lord's XML generation routine will then embed this second parameter as a reference in the output XML file it spits back.
Its important that the Client gets to indicate the XSLT file location as it could be a file local to the client, or the empeg itself or somewhere on the internet - the client will know this and Mark shouldn't need to care - he just echoes it back in the right place in the XML

However, the issue then arises about what if we should want a 'default' XSLT file stored on the empeg itself and a reference to it is delivered in the XML file if no XSLT is requested in the .xml request.

In this case I think we need to be able to have a 'default' xslt file 'location' in config.ini - and Mark can embed this location reference in the XML file even if we don't ask for it.
This has a benefit that a simple xml request will come back, [with possibly a xslt file reference in it, if a default xslt file location is defined in config.ini] and the client then either ignore the xslt reference in the XML file, or process the xml using that xslt reference.

3. Any implementation should be designed with compliance to the w3C standard in this area [for XSLT references and XML format] and structure (e.g. XML elements versus attrributes), but needs to be aware that not all XML implementations [read few], actually work with the W3C standards now but obviously when they are made compliant they will to the W3C standards.
So some kind of 'compatibility' mode needs to be considered for (to use a MS term) "downlevel browsers/client".

Once we have agreed on how much of the above we want, we need to then write it all up nicely and give it to Mark for him to implement when he gets time.

And then we need everyone who wants these features to help us all test the implementation on their platforms and OS's and clients.