XML is not S-Expressions

http://www.prescod.net/xml/sexprs.html

by yters • 18 years ago

35 63 18 years ago

11ren16• 18 years ago

I have a corollary to Greenspun's Tenth Law, which is that:

  Lisp programmers see everything in terms of as an ad hoc,
  informally-specified, bug-ridden, slow implementation of half of Lisp,
  and don't see other benefits it might have.
  That is, Greenspun's Tenth Law is true - for Lisp programmers.

I came to this conclusion because of a tragic pair of research papers, which had a fantastic usability idea. The second half of the first paper took the focus off the usability, and developed it into a very simple functional language. In their next paper, they dropped the fantastic usability idea completely, and made it into a lisp. :-(

Some XML standards fell into a similar trap, by wanting languages that process XML to be themselves written in XML - such as XSLT. It's a nice abstract concept to be able to process yourself... but at the price of abominations like "i < 10".

Adam Bosworth pointed out that XML's XPath resisted this - by making XPath itself an embedded non-XML mini-language. Imagine an XML representation of path components - now that would be verbose!

In a politically expedient move, I'd like to point out that pg didn't fall into this trap: he made the DSL for users of Viaweb to customize their store to not be lisp (though an easily mapped subset, if I understand correctly.) It's a non-lisp mini-language.

Great link from the article, about "principle of least power", for mini-languages: http://www.w3.org/DesignIssues/Principles.html#PLP Constraints are very empowering, because you know what to expect.

Regarding XML: I'd always thought it was just one of many possible syntaxes for representing hierarchical data; and it really didn't matter which syntax you used. As in a lingua franca (or any standard), provided that it is barely adequate, the key thing is that everyone agrees on it. XML became the Chosen, de facto standard, because everyone was already familiar with HTML, propelled by the mass adoption of the web. So the question becomes: why did we get HTML (based on SGML), instead of S-expressions? The article gives reasons, but I guess the short of it is that if a group of people work towards a specific purpose for years, and are successful at it (as SGML was), it is probably a good base to start from if you want to do something similar, i.e. describe documents.

Also, more directly, if I imagine a large webpage described with S-expressions, I think HTML is a bit clearer.

Nitpick: The article omits that quotes (or apostrophes) must be escaped in XML attributes.

Very telling points about LaTeX - that like XML/HTML, it also uses named end-tags; and that Lisp documentation itself is used LaTeX instead of S-expressions - drinking their kool-aid; but not eating their dog-food.

anamax5• 18 years ago

> Very telling points about LaTeX - that like XML/HTML

No, it's a demonstration of ignorance. LaTeX wasn't written by Lispers, it is merely used by them. The fact that they find its design decisions acceptable must be weighed against the cost of their alternatives. That doesn't imply that they wouldn't have been happier with a more lispish syntax.

At the time that those decisions were made, LaTeX was pretty much the best alternative. The fact that Lispers, like almost everyone else in related communities, made that decision merely says that Lispers don't cut off their noses to spite their face.

11ren16• 18 years ago

The article suggests Lispers could have used sexp as a front-end to LaTeX, in the same way that XML was used as a front-end to LaTeX. Very easy to do.

> If S-expressions were easier to edit, it would be most logical to edit the document in S-expressions and then write a small Scheme program to convert S-expressions into a formatting language like LaTeX. This is, what XML and SGML people have done for decades [...]

mindslight2• 18 years ago

XML definitely adds features over sexps, and is good for adding markup to primarily text-based documents, where the concept of bare text has an intuitive meaning, and elements denote a formally defined machine-readable layer on top.

However, the fight occurs when XML is used as a generic serialization format, or even as syntax for a programming language. There, the features only add redundant complexity (what does unquoted text mean in an ant build file? why am I putting quotes around identifiers, and why am I including the redundant end tags when my editor indents for structure?). When your format already has specific semantics, the wiggle room between element/attribute/text only adds inflexible accidental complexity.

11ren16• 18 years ago

JSON is another contestant in the generic data serialization space, which is doing better than sexp - possibly due to the ubiquity of javascript (free-riding the web). Though, for this technology generation, the fight is over.

I think there'll be another chance when SOA/web services are superseded; but there's still huge scope for improvement within their present architecture/ecosystem (e.g. REST vs. SOAP vs. ?).

For programming languages, sexps are competing against all the other language syntaxes out there, not just XML. I agree that it seems odd that ant uses XML though... perhaps the extensibility of ant is easier with some kind of generic format (like XML/sexp/JSON)? yet other languages manage to be extensible via functions/classes/modules etc.

Thank goodness no one uses JSON to encode a language (in the way that ant uses XML).

michaelneale5• 18 years ago

I am thinking ant did it to get the parser and some kind of tools for free. Certainly no one really likes it as XML.

gruseom14• 18 years ago

Thank goodness no one uses JSON to encode a language (in the way that ant uses XML).

Heh. Of course, they don't need to. As the French guy says in the Holy Grail, "we've already got one, it's very nice!"

Hexstream• 18 years ago

"The XML one does not use standard human-punctuation characters as markup. It doesn't require quoting of apostrophes, double quotes or parentheses."

(:p "Lisp doesn't require quoting of apostrophes (') or parentheses (()) either...")

jodrellblank• 18 years ago

He makes some good points that I didn't consider when first I hated upon XML. I agree that XML is better for its problem domain than s-expressions, but in that case the whole article is an apples to oranges comparison.

He claims that syntax is important, otherwise we'd still be using binary formats. If that's true then the only reason syntax is important is for humans, because machines can read binary formats just as well as anything else. So why compare it to s-expressions instead of to a human-friendly ideal? Is XML the best human-friendly markup language possible? Yes his paragraph is similarly readable in both forms, but would it be if wrapped in XML namespace clauses and an XML Schema? Would the s-expression version be if wrapped in a macro to parse text outside quotes as significant text?

The purpose of XML shouldn't be to make everything more XML-y, but to make everything easier. Maybe it does, in big enterprisey systems and between large data silos. Look at the recent ODF v. Office XML file formats. Have any of you been tempted to process Microsoft Office documents directly because now they're XML they must be easier than the old binary formats?

It's still not human friendly - you can't use the Jabber protocol by hand over telnet like you can use POP3, SMTP, IRC.

11ren16• 18 years ago

> you can't use the Jabber protocol by hand over telnet like you can use POP3, SMTP, IRC.

There's an intriguing view that text can't be used by hand either - you have to use a "text shell". Wouldn't a fair comparison use an "XML shell"? If it knew the schema, it could even autocomplete/intellisense for you, showing you the available choices at that point... it's pretty cool how XML has factored out the grammar of a language, in a reusable way.

I don't know the Jabber protocol, but the difficulty I've experienced with web-based XML protocols (web services) is that the http header needs the length of the message, which is hard to do by hand - it's not due to XML (and a "http shell" would fix that...)

hassy• 18 years ago

http-twiddle mode for Emacs is handy for tinkering with web-based XML stuff:

http://github.com/hassy/http-twiddle/

michaelneale5• 18 years ago

I have found using a lib to process MS document formats from binary is easier then direct XML. The XML formats look more like a memory dump then a marked up document.

cgranade• 18 years ago

Well, that's OOXML. MS chose to employ the pure content model, so that text nodes and elements cannot be mixed as children of a root element. That leads to monstrosities like this (I forgot the actual element names, so I made them up):

  <p>
    <t>This is not bold.</t>
    <t><b>This is.</b></t>
    <t>This isn't.</t>
  </p>

In a mixed content model schema, you could omit the extraneous <t> elements and just directly embed text nodes:

  <p>
    This is isn't bold.
    <b>This is.</b>
    This isn't either.
  </p>

That's just one of the many ways in which MS misused XML to make things worse instead of better.

gruseom14• 18 years ago

The article is refuted by both reality -- the godawful messes that people have made out of XML, the complexity of the systems built on top of it, its failure to amount to more than a bloated machine format, and the exodus in favor of more lightweight notations like JSON -- as well as by itself: the author expects the reader to consider the proliferation of single-shot technologies built on XML as a good thing and not a Tower of Babel. He lists DTDs, RELAX, XML Schema, XPointer, XQuery, XPath (edit: whoops, I snuck that one in), XSLT, and CSS and cites the "decades of person-effort embodied in those specifications" as if it were an argument in their favor!

I found this statement in the article interesting: "The central idea of the XML family of standards is to separate code from data." It explains why all the systems that express programming constructs in XML are such monstrosities (including XSLT, which he cites approvingly and yet which totally violates this separation). I wonder what the author would say to the people who do this kind of thing? They're not using it according to specification?

Edit: some of the arguments are out of date, too. I don't know anything about Lisp documentation in LaTeX; the open-source Lisp world tends to generate HTML documentation from s-expressions, as for example here: http://www.weitz.de/cl-ppcre/.

11ren16• 18 years ago

Do you have references for that exodus?

By Google, XML is winning 50 to 1 - but declining, and JSON is growing: http://www.google.com/trends?q=xml%2C+json&ctab=0

However, a factor is that people already know about XML and don't need to search for it. e.g. HTML is declining even faster: http://www.google.com/trends?q=xml%2C+json%2C+HTML&ctab=...

gruseom14• 18 years ago

Ooh, duelling URLs, can I play? :)

http://www.google.com/trends?q=xml%2C+javascript

Do you have references for that exodus?

Not really. I'm talking about what I observe in the hacker world, which is a thoroughgoing trend away from XML. Do you really see it otherwise? It's not all going to JSON of course.

Most of the XML stuff is in big enterprise projects and, for some value of "count", those just don't count. Last I checked the IT pundits were declaring SOA dead, after having milked it for a decade.

jdale27• 18 years ago

Re: Lisp documentation in LaTeX, the author may be referring, for example, to CLtL; see http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node3.html

gruseom14• 18 years ago

Ah. Well, that was a book. I'll bet Steele would prefer LaTeX over XML too.

anamax5• 18 years ago

From the article: "Nor is it an accident of history that Lisp programmers never came up with these technologies for Lisp data. The central idea of the XML family of standards is to separate code from data. The cental idea of Lisp is that code and data are the same and should be represented the same."

No, that's not the central idea of lisp. The closest "central idea of lisp" is that code should have a standard and convenient representation so it can be readily manipulated by programs.

Lispers separate application code from application data. They do so even when the application data is a program....

It is true that Lisper's didn't engage in years of meta-whinging and defining transform languages, but the fact that the XML folk did was more of an accident of history. When the Semantic Web hype was in full-swing, the Lispers were still licking their wounds from the AI winter.

And, how is that Semantic Web coming along? Pretty much where the Lisper's left it....

echair• 18 years ago

...but it would be better if it were.

jbert• 18 years ago

No love for the binary formats?

Let's hear it for ASN.1 (http://en.wikipedia.org/wiki/ASN.1), so good that google can reinvent it as protocol buffers (http://code.google.com/apis/protocolbuffers) and get people interested.

More seriously, yes, binary formats have their problems. And ASN.1 in particular suffered/suffers from being pre-unicode (and thus having a number of different + mostly useless character set types).

But it seems to me that this nested tag-length-value structure (ASN.1 and protocol buffers) occupies a design sweet spot.

wingo• 18 years ago

I'm surprised no-one mentioned SXML, Kiselyov's representation of XML in Scheme. His paper, "A better XML parser through functional programming", can be found here: http://okmij.org/ftp/papers/XML-parsing.ps.gz.

The introduction covers the difficulty of parsing XML fairly well, which is another way of saying that XML does have a fairly complex "model" behind it that Lispers often ignore.

anamax5• 18 years ago

Lisper's know that XML has a fairly complex model behind it. That's part of the argument against XML because the complexity doesn't seem to buy much.

voidpointer• 18 years ago

I think when arguing about XML, many people forget its relationship to SGML. Many of the drawbacks in XML are design decisions made in order to maintain backwards compatibility with SGML tools that were in use when XML was devised.

In order to simplify parsing (and in order to enable parsing a well formed document without knowing its DTD), XML threw out much of the syntactic sugar that SGML had to offer such as implicitly closed tags. I.e. Many people think that <tr><td>foo<td>bar... is invalid HTML because of missing </td>. In fact, it is perfectly valid because the HTML (SGML-)DTD specifies that a <td>-tag implicitly closes a preceding <td>. Most think it's a browser-hack. It is not.

What both XML (and SGML) add over S-EXPR is support for expressing grammers, a well-defined validation mechanism and quite good support for coping with different character encoding.

asciilifeform3• 18 years ago

Erik Naggum on XML vs. S-Expressions:

"They are not identical. The aspects you are willing to ignore are more important than the aspects you are willing to accept. Robbery is not just another way of making a living, rape is not just another way of satisfying basic human needs, torture is not just another way of interrogation. And XML is not just another way of writing S-exps. There are some things in life that you do not do if you want to be a moral being and feel proud of what you have accomplished."

(http://www.schnada.de/grapt/eriknaggum-xmlrant.html)

eru3• 18 years ago

Pretty strong words for such a trifle.

asciilifeform3• 18 years ago

Yet it is not a trifle.

Wasting what might amount to thousands of man-years by forcing talented people (who might otherwise accomplish something meaningful) to build workarounds for an inferior technology is every bit as criminal as, say, embezzlement.

XML is not S-Expressions

Related Stories