It's also complex in the fact that it adds extra bytes. Imagine a 10 Mb XML file....now figure out how much of that is space wasted on closing tags.

Let's say I hate XML and I love S-expressions. I'm willing to replace all my XML with Sexp now and all I need is a clearly defined syntax with charsets, escapes and all, so that I can write generators and parsers. That spec would probably fit 2 or 3 pages, but someone has to do it carefully. So where is it, the Sexp syntax for representing tree structures everybody's talking about?

(html (head (title "hi" ) ) (body (h1 "hello" ) ) )

then (defmacro html ... ) to transform it. so lisp already has the syntax, the parsers, and the generators

Lucky for you, Greenspun's Tenth Rule (http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule) comes into play. All of those languages actually have Lisp embedded inside them: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

S-expressions are beautiful for lisp code and for many kinds of structured data, but it gets ugly when you try to use it on something as messy as a human-writable hypertext document format. XML syntax on the other hand is designed for this.

I think it shouldn't necessarily be parsable by Lisp. Attributes, for example, could be as simple as

  (a (href=/path)  ...)

So use :named attributes instead?

  (a :href "/path" ...)

    <p>here is a <a href="http://example.com">link</a>.</p>

    (p "here is a" (a (@ (href "http://example.com")) "link") ".")

---------

don't judge straight translations. if s-exp's were the standard i suspect links would look more like:

(p "here is a" (a "link" @href "http://example.com" ) )

Just as if a smalltalk enthusiast proposed exchange of serialized smalltalk-images as the universal solution for data interchange. Because XML is just to complex to parse.

That's not a bad idea, and as I understand it, the Lisp operating systems back in the day passed actual objects back and forth between programs instead of strings.

JSON is a precise DSL for declaring basic data structures -- semantic batteries included! Why re-invent the wheel?

"A markup language is predicated on the idea that the markup is an exception in a river of text."

It's the difference between

     <p>here is a <a href="http://example.com">link</a>.</p>

    <name>bct</name>
    <dob>19xx-07-03</dob>
    <address>...</address>

I know that a JSON version of my XHTML fragment up there would suck pretty hard; would a s-exp one be any better? (honest question)

I think to make that judgement, we need to consider things like when do we really need namespaces? How often is a particular expression written by hand, how often is it generated automatically? How important are different character encodings? Does it have to be bandwidth efficient? Is this a type of data that might actually morph into a program or is that something we want to exclude for security or complexity reasons? Are there existing tools that help us to process one or the other representation more easily?

All these things depend on many more aspects than just data or document.

The fragment uses attributes and mixed content - something that would be quite ugly to express in JSON. I wont event try.

    ["p", "this is a", ["a", { "text" : "link", "href": "http://example.com" } ], "." ]

Certainly there are lots of other factors to be considered, but that just goes to prove my point; that "XML Sucks" rarely looks at anything beyond very simple uses of XML.

["p", "this is a", ["a", "link", {href: "http://example.com"}], "."]

If that is uglier is debatable, maybe a little bit. However, the point is really that suckyness is not just a matter of esthetics. All the more I agree with your second point.

 {"p":{">":"this is a","a":{"@href":"http://example.com","b":{">":"link"}},">":".","@class":"my-p-class"}}

 {"p":{">":"this is a","a":{"@":"http://example.com",">":"link"},">":"."}