Re: xml and s-expression
- From: "Rob Thorpe" <robert.thorpe@xxxxxxxxxxxx>
- Date: 31 May 2006 05:17:06 -0700
doug wrote:
Hi,
I came across this web page titled "xml is not s-expression"
http://www.prescod.net/xml/sexprs.html
One of the points raised by the author is the separation of code from
data as oppose
to treating them as the same thing in lisp. I don't know enough about
lisp to make an
educated evalutation on that claim. Thus I am posting that link here
to elicit reviews
from the lisp community.
Many of his criticisms are true:
1. S-exprs and XML were not made to solve the same problems
2. S-exprs do not treat random characters like text as XML does
3. S-exprs do requires escaping quotes and double quotes, whereas XML
only requires escaping <>. The latter is probably less heavily used,
so less escaping is necessary.
#2 and #3 above are only relevant if you're using XML as a language for
marking up documents, and then only if you're requiring it to be very
easy for humans to change. Most practical uses of XML I've seen treat
it as a method of storing data that just happens to use markup. Most
seem to be only accidentally designed for humans to read. So neither
criticism is very important.
4. XML documents have end tags which makes it easier to spot errors of
unbalanced tagging.
This is true, but there is no reason why you can't write a s-expr
format in the same way. You could write one so that the atom that
begins a list is repeated at the end. So his example would look like:
(document author: "paul@xxxxxxxxxxx"
(para "This is a paragraph " (footnote "(better than the one under
there)" "." para)
(para "Ha! I made you say \"underwear\"." para) document)
It is now just as easy for a programmer without an editor capable of
understanding parens to find the error. But almost all editors around
these days seem to know how to balance parens anyway.
5. XML has loads of useful technologies around it.
This is certainly true, I agree with him here. Some of the things XML
takes immense pain over are extremely simple though.
6. To the lisp community the lisp equivalent of an XML Schema would be
"lisp program". I.e. there are no special purpose
description/extraction languages for working with s-exprs.
Its true that there are no equivalents right now. It would be nice to
fix this, see the thread "s-expression data language"
7. This ignore the "principle of least power"
Tim-Berners Lee wrote this about this principle:
"Computer Science in the 1960s to 80s spent a lot of effort making
languages which were as powerful as possible. Nowadays we have to
appreciate the reasons for picking not the most powerful solution but
the least powerful. The reason for this is that the less powerful the
language, the more you can do with the data stored in that language. If
you write it in a simple declarative from, anyone can write a program
to analyze it in many ways."
This is wrong, it mistakes complexity for power. Lisp (and scheme) are
both powerful languages, but they are simple and it's simple to write
programs to analyze data in them, even in other languages.
The other reason not mentioned for wanting languages not to be too
powerful is security. This is a more valid reason in some cases.
8. Lastly Prescod says:
"You could also argue that it might not be appropriate to define one
language for both documention processing and data processing. My own
sense is that the benefits of integrating the two domains outweighs the
costs in having a technology that is not optimized for the data
processing domain."
I'm not sure I agree with him here. I think the data processing domain
is important, and in the end what a huge group(most?) of people
actually use XML for. XMLs weaknesses in do cause real problems. For
example, a programmer was telling me this week about a system that used
several 150MB XML files, to process one of these took an SMP server
many hours. Much of this is probably down to the relative complexity
of parsing it.
There are also problems he doesn't mention with XML. XML does not
preserve itself under identity. If you read it with a parser without
all the information it is not possible to print it out again without
making it possibly unreadable by a parser that does have all the
information. In a great many cases it is, but not in all.
I.e.
Write(Read (XML)) ~ XML.
Whereas Write(Read (s-expr)) = s-expr
This is mentioned in the paper Pascal mentions.
Lastly, it's more or less required that you use a packaged XML parser
to parse XML and get it right. Whereas s-exprs are simple enough that
you can write a parser to parse simple s-exprs without too much
difficulty. It is quite a simple program in almost any language. An
s-expr parser would be practical in many embedded programs where an XML
parser is not. And it's much easier to optimize a simple program for
speed.
.
- References:
- xml and s-expression
- From: doug
- xml and s-expression
- Prev by Date: Re: Specializing MAKE-INSTANCE
- Next by Date: Re: Raw Terminal I/O in lisp
- Previous by thread: Re: xml and s-expression
- Next by thread: Re: xml and s-expression
- Index(es):
Relevant Pages
|
