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.
Doug
doug wrote:
> Hi,
>
> I came across this web page titled "xml is not s-expression"
> http://www.prescod.net/xml/sexprs.html
>
It's true that xml and s-expressions are not the same. XML is worse.
See http://homepages.inf.ed.ac.uk/wadler/papers/xml-essence/xml-essence.pdf
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
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: ·····@prescod.net"
(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.
> I came across this web page titled "xml is not s-expression"
> http://www.prescod.net/xml/sexprs.html
The author of that page doesn't seem to know the difference
between strings and text. The author also seems to think that
Lisp's ability to manipulate code in the language implies that
lLisp code and data can't be separate, but they can be. (All
lisp code is lisp data, but some Lisp data is not Lisp code.)
Since his conclusions follow from such errors, none are sound.
Which reminds me, the "Principle of Least Power" is blather
(and the reference is a circular argument). XML/SGML/HTML
are good data formats because they contain/describe their
structure, not because they can't be evaluated. S-expressions
have that property as well, and the advantage that some
s-expressions can be interpreted as code (or not - depends
on what you want to do).
One of these days, I expect someone in the XML community
to notice that packaging some code with data can be quite useful.
If we're really lucky, they'll pick something like Forth bytecodes.
(That's not a criticism of Forth.)
······@earthlink.net writes:
>> I came across this web page titled "xml is not s-expression"
>> http://www.prescod.net/xml/sexprs.html
>
> The author of that page doesn't seem to know the difference
> between strings and text. The author also seems to think that
> Lisp's ability to manipulate code in the language implies that
> lLisp code and data can't be separate, but they can be. (All
> lisp code is lisp data, but some Lisp data is not Lisp code.)
>
> Since his conclusions follow from such errors, none are sound.
>
> Which reminds me, the "Principle of Least Power" is blather
> (and the reference is a circular argument). XML/SGML/HTML
> are good data formats because they contain/describe their
> structure, not because they can't be evaluated. S-expressions
> have that property as well, and the advantage that some
> s-expressions can be interpreted as code (or not - depends
> on what you want to do).
>
> One of these days, I expect someone in the XML community
> to notice that packaging some code with data can be quite useful.
> If we're really lucky, they'll pick something like Forth bytecodes.
> (That's not a criticism of Forth.)
"Place one fresh egg above an empty plate. Break the egg. Pour content
onto the plate. Throw away the shell. Put the plate in microwave. Turn
knob. Wait 62 seconds. Get plate. Eat egg."
Is this a string? Is this data or code?
The point is that even for the deadest coldest data, you can always
invent some interpreter to make it become alive code.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
······@earthlink.net wrote:
> > I came across this web page titled "xml is not s-expression"
> > http://www.prescod.net/xml/sexprs.html
>
> The author of that page doesn't seem to know the difference
> between strings and text. The author also seems to think that
> Lisp's ability to manipulate code in the language implies that
> lLisp code and data can't be separate, but they can be. (All
> lisp code is lisp data, but some Lisp data is not Lisp code.)
Where is the evidence that he makes this mistake?
Many people seem to make it, but I can't see any evidence in the
article that he's one of them.