Steve Loughran: "So you cannot say that code-in-XML is inherently wrong, as there is clearly a two-way transform at the syntactic level from an XML document into a scheme clause, and since scheme is an elegant and powerful language, so there is an elegant and powerful way to work with XML, within a representation of the document itself." Whether data is code or not depends on what's looking at it. Without an evaluator, code is just notation, just like XML is. What might be wrong are embedding other code notations in XML, or if you are a protocols extremist, embedded verbs, because the verb is being uttered elsewhere through the protocol, and you know, make your furiously colorful sleeping green mind up already. One reason Lisp Kicks Computer Science Ass is because the notation lends to extensible evaluation of the evaluator - when smug Lisp weenies talk about extensibility, they are talking up different stuff than smug middleware weenies who think plugins and namespaces are big woop *. Steve might want to look at JSON if he hasn't already. Yes, Lisp parens are an optimal way to inscribe tokens for evaluation, and are deeply beautiful in that Mandelbrot kind of way (oh! fractals! shiny!), but JSON is less likely to freak javascript/css/java people out. JSON has that worse-is-bettery feel to it. * I fear that this will result in reanimating the XML v Lisp permathread from xml-dev - like the big one, it's due anytime. That particularly inane permathread's source of energy is the confusion between the evaluator and notation....
Previous Topic
