An Android Side Project

There are many possibilities. SXML is the one I use.

You need to use a semi-structured editor, like paredit on emacs, to get all of the advantages, though. Otherwise as you mention you'll be grovelling for the closing paren, when the machine could have maintained the balance from the beginning.

But namespaces are just more data. Namespaces, in my experience, have just turned into a hurdle that requires a bunch of needless element decoration to get it to play nice with XPath. The only place I know of where there is great confusion over what "XML" document you're processing is a browser trying to decide what type of document it's working with, i.e. all of the various versions of HTML and XHTML. That's not an argument for namespacing, that's an argument against forking markup languages. In every case where I've built XML processing services, I always knew what the purpose of the document was ahead of time.

Then there's XML Schema. In practice, I doubt few people actually validate documents against an XSD, in the rare cases one actually existed. Have you ever tried writing a reasonable sized XSD? Why are attributes treated differently from elements with a single text node as a child? Why can't I specify that a certain attribute is a prerequisite for another? Why are we specifying document structure and default values at the same time? What safety is type information actually giving me if I have to validate in my consuming service anyway?

I've had to process XML documents that claimed to be of such-and-such standard schema, and it invariably turns out untrue. There's always some 11pm job that fails to validate a doc because the author added an extra attribute or misspelled one you don't care about. Eventually, you just turn validation off and start doing things much more dynamically. I've always had to infer the schema from the document itself, otherwise my apps were too rigid for real-world use.

Someone else mentioned that S-exprs would need an intelligent editor to make writing them more coherent. I personally think the same is true for XML, as reasonably large (i.e. anything beyond tutorial demonstrations) XML documents will have the same problem of guessing what tags are already closed and which order they should be closed in, if only because their openings have scrolled off the top of the screen. Sure, you know you're closing a DIV tag right now, but which one? How long did it take to get decent XML syntax validation? While your Lisp interpreter has been sitting there quietly for the last 60 years. Throw in validation against namespacing and schema, and you still need an intelligent editor either way.

I don't really buy that XML is human readable, either. You don't read a 5000 line XML document, there's nothing to be gained from reading raw XML in that case (even if you have a raw text editor that can handle the file size). XML might have a slight advantage with being easier to demonstrate for new people learning, but once you get into actually using these tools, you don't ever use them in the "human readable/editable" format. That'd be like managing your finances with nothing but text files.

I'm just saying, Lisp was already well understood and parsed by the time XML was invented, and even XML + XSLT isn't even on parity with Lisp. Namespacing and XML Schema just turn out to be conventions that people say they're going to try to adhere to, but never do. Like I said, just like speed limits on roads.