I tried the "Export Database to XML" option of jEmplode today, and found myself quite disappointed. My aim was to have something to which I could apply a DSSSL stylesheet, to get a little booklet for passengers to browse the playlists in a form more convenient than the player menus. It would be quite useful, particularly with several passengers who all want to choose music.

I couldn't find the DTD for it anywhere (and there's no DOCTYPE declaration), so ordinary tools that want valid XML won't work.

Geussing at a DTD, it seems that all properties of each entry are represented as #PCDATA content. This seems odd, particularly for playlists, which naturally refer to other entries. I'd expected to see ID attributes based on FIDs (can't be exactly FIDs as XML IDs can't begin with a digit), and playlist contents represented as IDREFS attributes, enabling us to use the built-in power of ID references rather than having to build our own dereferencers.

Obviously, I could deal with the above by some pre-processing Perl script, but I'd rather I didn't have to. So, who is using the current format, and where did the design come from? Are other people suffering from the same frustrations as I am, or is everbody happily using the DTD-less unstructured output we currently have?

The XML format that jEmplode uses is the one that Emplode uses, and I figured that status quo was better than some jEmplode proprietary format. However, If you can send me a sample document of what you would like to see, and maybe a little bit of forum discussion about it, I can pretty easily add it in as an option. There was a big discussion about the XML format from Emplode a while back, but I don't recall what the outcome was ...

In fact, if you're really endeavous, the XMLExporter is actually pretty simple code ... If you wanted to write a new one that does the fancy stuff you want, I'll definitely include it org/jempeg/empeg/util/XMLExporter.java . I don't use XML libs in it, since writing XML is pretty simple w/o and I didn't want to add another couple hundred K onto an already big jar file... Maybe nano-xml would be good to include with jemplode...

Mike

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?

I fixed the encoding thing for CSV and XML exporter ... I also just moved the code that calls them from PlayerDatabase to the action. If you write the Exporter and send it to me I'll do the hookup for it. I agree that we should keep the original one too ... Either we'll make another Export action or make it a property that you can set as to which type of output you want.

As far as that format, it makes sense to me ... It's a pretty simple dataset we're dealing with, so you can't do it but so many different ways. I'd say go for it.

Mike

If anyone comes up with a sane XML output format, I'll look at implementing it in emplode -- the current output code was done in a hurry on a Friday afternoon, IIRC. I'm not that familiar with XML, so I figured (perhaps naively) that it could all just be run through some XSLT to turn it into whatever format you actually wanted.

I just noticed that the current output isn't even well-formed:

pw.println("<nodestore player_name=\"" + name + "\">");

Enumeration keys = nodeMap.keys();
while (keys.hasMoreElements()) {
...
}
pw.println("</nodeset>");

Nodestore, or nodeset?

Oops. I never use that thing. Obivously nobody else does either

Here's my first-cut. It generates valid XML (from my player, anyway), as checked by

SP_CHARSET_FIXED=YES SP_ENCODING=XML nsgmls -wxml -mdeclaration/xml.soc -gues playlists.xml

I've simply overwritten the existing XMLExporter class; since we want to keep it alongside the new stuff, I'm assuming you're willing to move the code to the right place. The encode() method is unchanged, so it may be worth having an abstract base class containing it and declarations of the other methods.

In passing, I noticed that the code puts my owner name in the root element's attributes. I'm guessing that you wanted to have the player's name there, but I don't know how to retrieve that from the core of jEmplode.

The DTD is emitted inline to make it easier for people to use without needing to copy or reference any ancillary files. I've used a variant of my proposal (attribute values are content, not attributes), and I've corrected a syntax error and included declarations for the standard XML general entities (copied directly from the standard). Here's the DTD:


<!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 (#PCDATA) >
<!ATTLIST attribute
name CDATA #REQUIRED >

<!ENTITY lt "&#38;#60;">
<!ENTITY gt "&#62;">
<!ENTITY amp "&#38;#38;">
<!ENTITY apos "&#39;">
<!ENTITY quot "&#34;">


Let's see if I can remember enough DSSSL to actually use this now!

Here's a stylesheet I used to give a summary of what's on the player. It doesn't list every tune (my "artists" playlist takes 10 pages already; I didn't want to make it longer). It does what I want, so I can say "Mission accomplished".

Works with OpenJade 14.1 as in Debian "woody" as at July 2002 (and includes a workaround for a known bug in that version - harmless to other DSSSL processors).