The HTML of your comment, with some formatting added: <span class="comment">
<font color=#000000>
You are right about text-editors. XML was designed to be reasonable
easy to write and edit by humans without specialized software. The
redundant end-tag helps to catch errors and make structure more
explicit.
<p>
Sure everyone could just use a fancy specialized editor with paren
matching auto-indentation. But one of the goals of XML was
precisely that it should not rely on specialized software to be
able to read and write.
<p>
Your example with the table is a lot clearer with sexpr syntax
<b>because you don't actually have any content in the table.</b>
Try again with a few sentences of mixed content, some bolded
words, a link, and so on, and you will get my point.
<p>
Note that you would also need to gzip your s-expressions if you are
concerned about size.
</font>
</span>
The same thing in S-expressions (an invented syntax): (span (class . comment)
(font (color . #000000)
You are right about text-editors. XML was designed to be reasonable
easy to write and edit by humans without specialized software. The
redundant end-tag helps to catch errors and make structure more
explicit.
(p)
Sure everyone could just use a fancy specialized editor with paren
matching auto-indentation. But one of the goals of XML was
precisely that it should not rely on specialized software to be
able to read and write.
(p)
Your example with the table is a lot clearer with sexpr syntax
(b because you don't actually have any content in the table). Try
again with a few sentences of mixed content, some bolded words, a
link, and so on, and you will get my point.
(p)
Note that you would also need to gzip your s-expressions if you are
concerned about size.))
It's really not a lot different. Of course, parens would need to be escaped, but this is no different from needing to escape < and >.But one of the goals of XML was precisely that it should not rely on specialized software to be able to read and write. But this is the problem with XML... it does rely on special libraries to validate and parse into reasonable data structures. It requires special heuristics to describe how to recover nicely in the event that markup isn't valid. It requires a document describing exactly what the XML needs to look like. S-expressions are easier to parse, less verbose, and can accomplish all the same tasks and more, all while being more flexible in general. |
Yes, XML requires a library to parse - so does s-expressions! The reason XML seem more complex than sexprs is that it defines a higher-level syntax e.g. with element/attribute-distinctions. You have reinvented that yourself in you example, so you need a spec for it and you need the parser to support it. Also the rules of encodings and character sets have to be specified (e.g. how do you detect the encoding of a file? Which characters count as whitespace?). You will end up with a spec much like XML, except with round parentheses. (OK, XML is also complex because of DTD's but that is a optional part. If you want something like DTD's for sexprs, again, you have to specify it, and you get something like XML.)
Btw. there is no heuristics for recovery in XML. XML parsers must fail when encountering malformed syntax. This is one of the major (and controversial) differences between XML and HTML.
I appreciate s-expressions as a syntax for a programming language. But code is a very different use case than documents. I wouldn't like to program in XML syntax either! E.g. programs (hopefully) don't have deeply nested structures covering several pages. That is common in documents, hence the importance of the redundant end tag.
I like sexprs for code and data, but for documents they are only simpler if you ignore a lot of real-world issues.