Okay i have seen the XML export option in emplode could some one please tell me what is it and what would i use it for

Right now the XML Export is not very useful to most people as compared to the Comma Seperated Variable (CSV) output that Emplode currently does (and has done for some time).

However, the usefulness of the XML version is that it should be quite easy to create a 'map' that takes the XML file and produces say a HTML page displayable within your web browser. Or a variant of the CSV file output now or any of a hundred different output formats people would like emplode to support.

This 'map' (Written in a language called XSL by the way) is much easier to produce from XML file than it is from a CSV file or any other sort of file and the map should work the same whether you have a Linux box or a Windows Pc or whatever.

For right now, the easiest way to work with this sort of file directly is to use Excel 2002 which is part of Office XP. You can do some really whizzy stuff in Excel 2002 with XML files that beats the pants off of plain old CSV files.

There is another thread on this BBS where Roger [the guy who wrote the Emplode XML export feature] is hinting at a way that these 'maps' (written by other BBS members) could be packaged with/able to interface with emplode in the future so that you can select to output your playlist in whatever supported formats are available - simply by downloading new maps.

And of course you could write your own maps if you have the time and inclination.

But right now, its ahead of itself but it is a worthwhile feature for going forward.

Ah so it is of no use to me Yet i shall just continue to fool around with CVS

If you 'fool around' with CSV programmatically (say, from a Perl script), XML might ba a way to go even now. There are nice libraries/modules/whatever for XML parsing for various languages (both scripting and 3GL).

It seems that currently half of total WWW content is about XML and related stuff, but a good place for a novice to start might be O'Reilly's www.xml.com (see in particular 'Essentials' menu on the left).

XML is the way everything is going. I do mean everything. There's even a thing called XHTML, which is an HTML implementation in XML. XML is must easier to deal with than a CVS because lots of languages already have parsers. Which means all you have to do is say "parse this file" then traverse the node tree. It's a very easy and powerful technology and I'm _VERY_ pleased that they added it.

Er, I agree, that's why I suggested that processing the form of XML export we have now (without waiting for fancy XSLT transformation scripts) is better idea than attacking CSV.

Allow, however, this 20+ years IT veteran a bit of cynicism: XML is surrounded with too much hype and too little understanding, like any new[1] information technology. It's not the silver bullet. It enables global, transparent B2B applications? What was wrong with using EDI for that?

There are too many competing standards for ancillary functions. Trivial applications are hawked as and-all solutions. There is far too much of reinventing the wheel. But, I guess that cannot be helped and happens elsewhere (for example, it is amusing to see 'Agile programming' reinvent concepts of rapid or prototype-based development of decade ago )

Don't get me wrong: global acceptance of XML does hold a lot of potential. I live in good part from it. It's just that it is not Second Coming.

[1] If we can call decades old technology 'new'. XML is, after all, just simplified SGML. Granted, other techniques that 'surround it' (for storing it, querying, transforming, using it as middleware substrate...) make the difference. SGML's primary raison d'etre was markup.

I agree with you, XML does have tons of hype, I've talked to people that say they know it, but all they know is that it's "html but you define your own tags"...which is wrong, there's SO much more to it. It's a very valuable tool to use. I use it for almost everything I do now, from web applications to config files. It's so valuable, and the parsers allow you to focus on the data itself, not getting it.

On a side note, I'd be willing to write some XSLT stylesheets that would transform a playlist into an html file if there was an outcry for them.

I'm crying out for them. It'll vindicate me putting the feature in there .

what kinda XSLT reports are you wanting?

Actually, right now, I could do with some XSL that turns the XML into a shell script to update the ID3 tags on my music collection on my PC -- my empeg died horribly yesterday, and I suspect that I'll have to reload most of my music .

Of course, my only correct set of tags were done using emplode (damn if it's not quite a good tag editor -- someone ought to make it work on real files ).

This leaves me with a bit of a problem.

what should the script look like.

i.e. supply the xml file. and a example of what a couple of the entries 'scripted' should look like.

I'll then knock up a XSL script to do what you want.

Of course, theory can do the same.
Problem is I'm about to go to bed as its 11:30pm at night.
so I won't look at it until tomorrow [about 8 hours from now].

Unfortunetly the XML that emplode generates doesn't contain any file names so there's no real way to generate a script that modifies the id3 tags, unless you had some specific way of naming *all* of them

The definition of "Died Horribly" being that it took him about five minutes to fix it again, without losing anything

Rob

Ah, but I do -- they're all named {album} - {tracknr} - {artist} - {title}.mp3.

What a coincidence, that appears to be exactly the same as the format used by the download feature .

It's just that I went to a lot of effort to fix up the years in emplode, and I didn't want to have to do that again.

Well, about 45 minutes, if we're honest. I had to apply an upgrade and then run fsck on the first music partition, which found some highly dodgy stuff, but seemed to sort it out.

Seems to be completely OK now -- it's been playing music for sixteen hours now, and hasn't crashed. Touch wood.