Some arguments against XML-languages have got me thinking. Mainly as a way to put off massively reworking my Xom-based app.

This is a purchase order. It the hypothetical PO that Exxon made to the white house to get the G8 group to deny that global warming is a problem or man made.

<purchase>
 <originator>
  <name>Exxon</name>
 </originator>
 <destination>
  The president of the united states
 </destination>
 <routing>
 A lawyer on loan to the government
 </routing>
 <items>
  <item>
    <name>denial of global warming in US science documents</name>
    <cost>5000000</cost>
  </item>
  <item>
    <name>denial of global warming in G8 announcements</name>
    <cost>3000000</cost>
  </item>
 </items>
 <payment>
  <total>8000000</total>
  <destination>
  Republican election committee
  </destination>
 </payment>
</purchase>

Now, is this data? Obviously. Is it code? Probably not. But what about this?

(purchase
    (originator (name "exxon"))
    (destination "The president of the united states")
    (routing "A lawyer on loan to the government")
    (items
        (item
            (name "denial of global warming in US science documents")
            (cost 5000000)
            )
        (item
            (name "denial of global warming in G8 announcements")
            (cost 3000000)
            )
        )
    (payment
        (total 8000000)
        (payment "Republican election committee")
        )
    )

It contains exactly the same data as before, and the document structure is also retained. Is this data? Obviously. Is it code? If evaluated in the right context, most definitely. And as we all known, scheme is one of the CS-hard languages, the one they teach to students as it is more pure than the hacker languages like C++ and Perl. (yes, I have chosen a doc without attributes, but they can be turned into elements and hence into clauses)

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.

All you need therefore, is (1) an appropriate expression evaluation engine and (2) a representation for XML that you are prepared to work with. It is unfortunate that classic-XML is not the best structure for humans, S-expressions are neater once you get used to them -but spend enough time and XML becomes readable too. All that leaves is the appropriate expression evaluation language. No, I dont think water is it either. It looks a bit LISPy, but seems to be trying to do that inside content markup.