Michael Rueger <m.rueger at acm.org> wrote:
	You can use XSLT (or any other transformation) to generate whatever you 
	like. Take a look at the Rosetta project for examples.
	
XSLT isn't the world's worst programming language; that's Intercal.
But it may very well be the second worst.  It's ridiculous when C code
to crunch XML is an order of magnitude shorter than XSLT code designed
by XSLT experts.  It's ridiculous when interpreted Scheme can give libxslt
a run for its money.

	You get multi-lingual character encoding for free.
	
You only get multi-lingual character encoding when your Smalltalk system
supports it.  (One commercial Smalltalk whose manual I happen to have handy
claims to have XML support.  In fact it's not bad, BUT the fine print points
out that they don't actually support Unicode, only Latin-1.)  If you have
Unicode support in Character and ..File..Stream, then you get multi-lingual
character support for any text format; if you don't, you don't.  (And
hacking on &#23168; and the like hardly counts as "for free" compared with
just insisting on UTF-8.)

	If you don't use some of the more bizarre features of XML like entity 
	declaration and inline substitution you can use an extremely simple parser.
	
That is, XML is great if you don't actually use XML.  Not really a
recommendation, is it?

	And because of the evaluation overhead involved in the current chunk 
	format I wouldn't be sure if a carefully design XML based format 
	wouldn't even be faster to parse than the chunk format.
	
Something that parses chunk format and something that parses XML must,
in the end, perform the same operations on system objects.  There is no
reason I know of to expect "if I see this XML pattern I do this" to be
faster than "if I see this parse tree pattern I do this".  Just because
it is XML that is being matched to see what should be done doesn't make
it anything other than "simulated evaluation".