How would that fix the problem? If you receieve invalid s-espression data - e.g. with unmatched parantheses or an unmatched quotation sign - how would you parse it into the structure that the author intended?
Every Lisp hacker has written their own version of XML as s-expressions. Here's one that actually has users other than its implementor:
http://okmij.org/ftp/Scheme/SXML.html
That snippet would look like:
(a (@ (href "http://news.ycombinator.com")) "News for" (b "Hackers") "!")
I'm an Emacs user, so paren-based navigation, highlighting of areas within matching parens, and concision because of the lack of closing tags wins for me. Maybe for somebody using MS Notepad it wouldn't be so great, since they don't have paren-based editing features so closing tags may actually be useful.
The snippet you showed is so small that XML's verbosity doesn't become a problem, so it doesn't really matter in this case.
I honestly dont understand why you think the sexpr syntax will lead to fewer errors? The syntax is just as complex, and there seem to be plenty of quote signs and nested parentheses to forget or mismatch.
Of course I don't doubt that you are able to write syntactically correct sexprs with the help of Emacs. A great number of tools (including Emacs I'm pretty sure) can help you the same way with XML. But for whatever reason - buggy software, bad editors, uneducated developers - invalid XML still happen. Why do you think substituting pointy brackets with rounded ones will change that?
>I honestly dont understand why you think the sexpr syntax will lead to fewer errors?
I already backed off on the strong version of the claim - that s-expressions would lead to fewer errors in general for the average person writing XML - but I still prefer s-expressions because as a Scheme programmer I am accustomed to using sexps and I find them cleaner and easier to us. People who don't use or don't like Scheme or Lisp probably wouldn't feel the same way. It would probably be harder to use sexprs in MS Notepad, like I said. Maybe even in vim.
>The syntax is just as complex, and there seem to be plenty of quote signs and nested parentheses to forget or mismatch.
Any decent text editor will highlight strings, so it will be difficult to mismatch quotes. In Emacs, I like paredit-mode, which inserts a closing paren every time you enter an opening paren, so you always have a balanced number of parentheses. Combined with editor features that highlight whichever s-expression the cursor is in, and auto-indentation which sticks out like a sore thumb if you make a mistake, it's rare to mismatch parentheses and easy to fix if you do.
I'm aware that there are Emacs modes for editing XML, and I tried them, but I still found it worthwhile to write in SXML and then convert to XML, because it's just cleaner and easier. Partly this is just because you use the same editor mode for editing an s-expression-based XML-alike as you would use to edit code, so the commands are already wired into your spinal reflexes, and bound to the most convenient keys. But it's also less verbose when you get rid of all the closing tags and half of the brackets, so you can see more of the data at a time.
Also, if you're using an s-expression based language (and I know most people aren't), it's convenient to use a data format which is simply part of your language itself.
Of course, YMMV. If you're using, say, Python, you might prefer to use something like looks like Python's dictionary syntax (JSON?). I don't really know what Python programmers do. But I do know that there's a reason that there are a jillion XML-knockoffs with different syntaxes - XML is friggin ugly.
