Actually, I don't see how he would have to write or incorporate any parser at all.

It's funny, I had written Mark an email about this a couple of days ago too, and orginally came down on the html template side, using some kind of token system to identify where the variables should be added to the html. But if we're really looking for flexibility, xml is the way to go. That will totally abstract the data from the presentation, which might be good for some other future applications. Perhaps you'd have an application (not a browser) that would want access to that playlist / tune data, but you don't want to have to wade through the html. XML would be the way to go.

The reason I don't think Mark would need to write or incorporate a parser is that all he'd be doing is writting an output stream, just like he is with the html. He didn't write an html parser, did he? If the code on the empeg simply enclosed the data in xml tags, and it was well-formed, we could take it from there. Even the people that don't know XSLT very well could easily be able to change a simple stylesheet to include what they wanted. The XML / XSLT parser lives on the client in this case. The server (the empeg) doesn't need to "process" the XML at all. It doesn't need to query, or store, or present the data, it just writes it out. The browser (or any other application) will do that work.

Let me know if you think I'm off base here, but again, I don't see any reason not to spit out xml.

I wanted to get this out there first. In my next post, I'll show an example xml and an example XSLT stylesheet to process it so everyone can see how easy this is.

Chris