The problems of XML have been quite often discussed here. People have
often mentioned how lisp read syntax performs the same job much more
simply.
But lisp read syntax in its normal state has some problems. Different
lisp implementations read it in slightly different ways, for example.
Also there is no way to describe a "valid" piece of data, except by a
lisp program that checks it.
These things would not be impossible to solve. Has anyone actually
done this and written a list based system similar in aims to XML?
I know about LML and the other things like it. But they appear to be
made for representing HTML.
As the guy who appears to have launched the "XML is s-expressions in
drag" comment, I'll take this one.
There is no spec for "lisp read syntax". There are detailed specs for
Common Lisp read and Scheme read, and implementations that purport to
implement those specs are compatible with each other. If you restrict
your s-expressions to ASCII atoms, double-quoted strings, integers, and
floating-point numbers, they'll be readable by just about anything.
I haven't found much use for validation, for s-expression-based
messages or XML documents. XML validation systems are somewhat useful
as documentation, but they tend to enforce non-useful constraints (it's
hard to say in a DTD that I want these 5 elements, in any order - you
end up saying they must come in one specific order) while not letting
you check simple-sounding but important constraints (like each of these
elements must have a corresponding element somewhere else). You end up
changing trivial stuff to make the validator happy, then feeding the
result to your program and having to fix other stuff anyway.
XML does do some things s-expressions can't do well, most notably
handling extended and multiple character sets well. Individual
implementations of CL/Scheme handle those, but there isn't overarching
spec support for much outside ASCII. If there were a spec for
character set support, it wouldn't be hard to define an s-expression
document format - one s-expression up front restricted to ASCII that
was the moral equivalent of <?XML ... ?> followed by a payload
s-expression.
bob_bane wrote:
> As the guy who appears to have launched the "XML is s-expressions in
> drag" comment, I'll take this one.
>
> There is no spec for "lisp read syntax". There are detailed specs for
> Common Lisp read and Scheme read, and implementations that purport to
> implement those specs are compatible with each other.
Unfortunately they're not really completely compatible with each other.
Some CL and some scheme implementations expand and change read syntax
is ways that go beyond the standard.
> If you restrict
> your s-expressions to ASCII atoms, double-quoted strings, integers, and
> floating-point numbers, they'll be readable by just about anything.
Yes. I think the approach of having a separate language, like the
s-expression language Antonio mentions below might solves the problem
better though. It allows for more flexibility than just using the
simple atoms you mention.
> I haven't found much use for validation, for s-expression-based
> messages or XML documents.
Interesting. Currently I'm writing a program that uses s-exprs to
store and recall data. Since I didn't know about Rivest s-expression I
decided to take the approach you mention of using only simple atoms.
It works OK.
I found that I wanted some level of verification though in order to
give sensible error messages at sensible times. The program reads the
s-exprs when a user opens a file and does simple validation. Then
later after more user input it walks the lists extracting data and
processing it.
If it didn't do simple validation I would have to issue errors about
malformed files when they were processed, which would be confusing. It
would also complicate the processing code with more error reporting
code.
> XML validation systems are somewhat useful
> as documentation, but they tend to enforce non-useful constraints (it's
> hard to say in a DTD that I want these 5 elements, in any order - you
> end up saying they must come in one specific order) while not letting
> you check simple-sounding but important constraints (like each of these
> elements must have a corresponding element somewhere else). You end up
> changing trivial stuff to make the validator happy, then feeding the
> result to your program and having to fix other stuff anyway.
I'm sure that's true. But theres no reason why a validation system
should have the limitations of DTDs. I much better validating system
could be made. It certainly wouldn't be difficult at all to make a
validation system a *little* better.
> XML does do some things s-expressions can't do well, most notably
> handling extended and multiple character sets well. Individual
> implementations of CL/Scheme handle those, but there isn't overarching
> spec support for much outside ASCII.
This is a problem. Maybe it would be easier to solve by using a
separate format than the lisp/scheme languages s-exprs like the
s-expression format?
I think a lot of lisp/scheme implementations could support Unicode in
their readers and printers if they wanted too. The problem they have
is that doing so implies the need to support it everywhere else too,
which is harder.
> If there were a spec for
> character set support, it wouldn't be hard to define an s-expression
> document format - one s-expression up front restricted to ASCII that
> was the moral equivalent of <?XML ... ?> followed by a payload
> s-expression.
That's a good idea. In the program I'm currently writing each file
begins ..
(version 1)
It would also be interesting to see if a format could be devised where
a lisp language is a specific application. That is, for example Scheme
s-exprs can be considered to be format X with rules Y.
The main arguments for S-expressions over XML (as far as I know) are:
1) S-expressions are simpler. They don't have the attribute/element
asymmetry. They're just nested lists, with key/value pairs as a special
case.
2) S-expressions are terser. This isn't an important argument, in my
opinion, since either can be compressed, and neither is really meant
for human consumption. (Ouch! Maybe not, since we program in
S-expressions. But raw sexprs would certainly not make a good markup
language. Of course, at the same time, programming in XML would be
miserable, so they're both imperfect notations. That's what I mean when
I say that they're not meant for human consumption.)
3) S-expressions are programs. This doesn't initially appear to be a
superb argument, since you need a Lisp implementation to execute
S-expressions as programs. An S-expression parser is certainly a *far*
cry from a Lisp implementation. However, there is something to be said
for the fact that it's actually humanly possible to program in
S-expressions, which opens up the possibility of manipulation
S-expressions with S-expression programs. Substitute "S-expressions"
for "XML" and you have XSLT, but XSLT basically sucks. Anyway, an
S-expression programming language is a really good thing because it
gives you code-data equivalency, which is, of course, good.
There's my $0.02.
"Rob Thorpe" <·············@antenova.com> writes:
> The problems of XML have been quite often discussed here. People have
> often mentioned how lisp read syntax performs the same job much more
> simply.
>
> But lisp read syntax in its normal state has some problems. Different
> lisp implementations read it in slightly different ways, for example.
> Also there is no way to describe a "valid" piece of data, except by a
> lisp program that checks it.
>
> These things would not be impossible to solve. Has anyone actually
> done this and written a list based system similar in aims to XML?
Take a look at http://theory.lcs.mit.edu/~rivest/sexp.html
and also
http://www.umu.se/it/projupp/spocp/doc/intro.html
Ant�nio Leit�o.
Antonio Menezes Leitao wrote:
> "Rob Thorpe" <·············@antenova.com> writes:
>
> > The problems of XML have been quite often discussed here. People have
> > often mentioned how lisp read syntax performs the same job much more
> > simply.
> >
> > But lisp read syntax in its normal state has some problems. Different
> > lisp implementations read it in slightly different ways, for example.
> > Also there is no way to describe a "valid" piece of data, except by a
> > lisp program that checks it.
> >
> > These things would not be impossible to solve. Has anyone actually
> > done this and written a list based system similar in aims to XML?
>
> Take a look at http://theory.lcs.mit.edu/~rivest/sexp.html
>
> and also
>
> http://www.umu.se/it/projupp/spocp/doc/intro.html
Thankyou, that was what I was looking for.
Maybe it would be useful to modernise this a bit (adding Unicode
support for example, like in SCOCP) and create a new version.
I might have a go if I get a little time in the next few months.
"Rob Thorpe" <·············@antenova.com> writes:
> The problems of XML have been quite often discussed here. People have
> often mentioned how lisp read syntax performs the same job much more
> simply.
Yes!
> These things would not be impossible to solve. Has anyone actually
> done this and written a list based system similar in aims to XML?
I wrote a program to read Rational Rose designs and then generate Java
code because the Rose code generator was incapable of doing the job;-(
Once you can read the file into lisp, you can do many things with it:
generate some common patterns you use often, generate statistics or
diagrams.
So have a look at Rational Rose petal data files. They are sexps with
some funny bits in it which you can easily fix in common lisp:
(defun read-petal-file (filename)
"Read petal file FILENAME and return list of objects."
(labels ((bar-reader (stream char) ; to read multi-line strings
(declare (ignore char))
(loop for s = (read-line stream t nil t)
then (progn (read-char stream t nil t)
(read-line stream t nil t))
collect s
while (eql (peek-char nil stream nil nil t) #\|))))
(let ((*readtable* (copy-readtable nil)))
;; multi-line strings start with |
(set-macro-character #\| #'bar-reader)
;; get rid of comma in (123, 456)
(set-syntax-from-char #\, #\space *readtable*)
(with-open-file (stream filename :direction :input
:external-format charset:ISO-8859-1)
(let ((*package* (find-package :rose2java)))
(loop for object = (read stream nil nil)
while object
collect object))))))
;; from http://www.jeewiz.com/demo_hospital.html I think:
;;(read-petal-file "~/src/rose2java/mdl/hospital/hospital98.mdl")
Shame they are moving towards XML but this shouldn't be a problem
either as you can read/write XML in lisp easily too.
Tomas