I've just seen a link to an XML draft for representing sieve (the mail filtering language used in many IMAP servers) …
The way I see things, sieve scripts as they currently stand are expected to be generated and edited by humans. XML, on the other hand, should never take on this role. Therefore any XML representation of sieve scripts would only be sensible for inter-machine communications … however, as there is a tight specification for sieve already, all an XML represenation would add is a generalised correctness-parsing engine. It wouldn't be able to help with semantic parsing.
In fact the Abstract of that article basically says the same thing – "Representing sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools." and then goes on to reveal the only useful aspect of this exercise – "The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently."
So, at the end of the day, this is a land-grab for a generic language for an application to store GUI-application-specific data. How about just writing the application first?
The redeeming factor is that a stylesheet is provided to convert from sieveXML back into sieve. That's a Good Thing. If you could provide a parser that would convert sieve into sieveXML and back again, you'd have a sieve-normalising process that could allow the human user to stick to a useful representation, but use existing XML tools to manipulate the higher-level abstractions.