Ah, I didn't realise that Emplode also has this functionality. You're right that compatibility is important. I reckon that you should keep that, even if we add another XML-based output format.

Looking at the code - yes, you're right that the code should be writing XML pretty directly - it's a stated aim (and acheived strength) of XML to be simple to write without needing any libraries. I might consider using MessageFormat and friends to allow tweaking the output from the properties file (but probably not for the first cut, and perhaps not ever, for performance reasons).

Character coding issues: I noticed that this class gets passed a Writer, but didn't discover where that comes from (I'm too lazy to read all the code!). It writes all characters directly (with the exception of &, <, and >), but looking at the generated output file, I see that non-ASCII characters appear as question marks. Either the writer should be created to use ISO-8859-1, and an appropriate XML declaration issued, or it should use ASCII and encode non-ASCII characters as numerical character references. I mention ISO-8859-1 as that's the usual coding for the player - people who have hacked alternative codings will have to process the output to get the characters they wish.

To put something up for discussion, I'd go for something like

<!ELEMENT player (playlist|tune)* >
<!ATTLIST player
name CDATA #IMPLIED >


<!ELEMENT playlist (attribute*) >
<!ATTLIST playlist
id ID #REQUIRED
content IDREFS #IMPLIED >

<!ELEMENT tune (attribute*) >
<!ATTLIST tune
id ID #REQUIRED >

<!ELEMENT attribute EMPTY >
<!ATTLIST attribute
name CDATA #REQUIRED
value CDATA #REQUIRED >


(I've attached this, for convenience)

I don't know what to say about it, other than that it uses the same "bag of stuff" approach as (j)Emplode's, because tunes and playlists can have many parents. The containment graph is implemented by the id and content attributes.

The attribute element (hmm, confusingly worded...) represents tune/playlist tags, and has a name and value (a bit like HTML applet parameters). This is not ideal for selecting particular paramaters, though no worse than the previous approach. The q-element and match-element? functions of DSSSL can still select individual parameters; it requires a small change to the pattern argument. Perhaps there's a case for having the value as the content of the attribute element - I'm totally agnostic on this, and would be happy with it either way.

Element IDs can be based on FIDs - I propose using 'x'+fid (as opposed to the current '0x'+fid).

Any suggestions, before I code it up?