Subject: Why XML caught on where LISP and Scheme failed to?

From: Omer Zak <[email-masked]>
Date: Fri, 28 May 2004 09:42:33 +0300

As I read "Extensible Programming for the 21st Century"
(URL:http://pyre.third-bit.com/~gvwilson/xmlprog.html), I pondered the 
secret of success of XML. In a way, I am already using XML software 
(glade, the GUI editing tool, saves the edited GUI description in a XML 
file, which can later be read by a Python library and used to construct 
the GUI for a script).

After all, it can be considered to be just another syntactic 
representation of LISP or Scheme. For example, the transformation between

(+ 1 2)

and

<paren>
    <token name="+"/>
    <token name="1"/>
    <token name="2"/>
</paren>

is trivial.

My guess is that XML succeeds because it allows the developer to add 
types to S expressions and to constrain them and their contents. This is 
like imposing hard-typedness on variables and/or their values in a 
conventional programming language. It works because the developer can 
give different names to his expressions besides the equivalent of naming 
every tag <paren>.

As a proof of concept, it may be a good idea to develop a XML 
representation of a Python script, along with code for transforming a 
Python script to its XML representation and vice versa.
                                              --- Omer
My own blog is at http://www.livejournal.com/users/tddpirate/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 30 May 2004 07:05:30 +0300

> representation of LISP or Scheme. For example, the transformation between

What makes you think it isn't:

<paren>
    <op name="+" />
    <token name="1" />
    <token name="2" />
</paren>

Or:

<paren op="+">
     <token name="1" />
     <token name="2" />
</paren>

Both of these forms suffer from the fact that if one of the operands (or the 
operations) is an expression, then it would be difficulty to encode it that 
way. A better way would be:

<paren>
	<op>+</op>
	<token>1</token>
	<token>2</token>
</paren>

That way the Scheme expression ((if cond + -) (+ 5 6) 7) would be encoded as:

<paren>
	<op>
		<paren>
			<op>if</op>
			<token>cond</token>
			<token>+</token>
			<token>-</token>
		</paren>
	</op>
	<token>
		<paren>
			<op>+</op>
			<token>5</token>
			<token>6</token>
		</paren>
	</token>
	<token>7</token>
</paren>

Furthermore, we may as well use the tag <expr> or <expression> instead of 
<paren> and the tag <element> instead of <token>. Another thing that exists 
in XML that is missing from S-expressions is the in-text markup. Like:

<p>The quick brown fox jumps over the <b>incredibly</b> lazy dog.</p>
                                      ^^^          ^^^^

Generally XML (and its philosophical father- SGML) is a superset of the markup 
functionality given by S-expressions. For every S-expression, there are many 
ways (possibly infinite) to encode as XML, while XML conversion to 
S-expressions is not always possible in a straightforward manner, may be 
lossy, or otherwise will simply be a verbose pseudo-XML encoding into 
S-expressions. 

Then there's YAML (YAML A'int a Markup Language) of course, which is basically 
just nested arrays and associative arrays and their values. This is somewhere 
between S-expressions (which are just nested lists) and XML. XML-RPC is a way 
to encode YAML-like structures into XML, which makes one not understand why 
XML is necessary in this case.

Regards,

	Shlomi Fish

-- 

---------------------------------------------------------------------
Shlomi Fish      [email-masked]
Homepage:        http://shlomif.il.eu.org/

Quidquid latine dictum sit, altum viditur.
        [Whatever is said in Latin sounds profound.]

---

From: "Nadav Har'El" <[email-masked]>
Date: Sun, 30 May 2004 10:55:16 +0300

> representation of LISP or Scheme. For example, the transformation between

I think you're misunderstanding XML. XML is was not supposed to be a
programming language, but rather a data representation (markup) language.
Lisp and XML are only related by the fact that both use "0" and "1" bits ;)

I remember that 6-7 years ago or so, at work, I had to invent a file format
for saving large sets of result coming from a certain program. The format had
to be relatively simple to read or write and machine-independant (so ASCII
was a benefit) and extentible (i.e., the reading program could look at
certain sections written by a newer writer, and know that it doesn't recognize
these sections and simply skip them, with no error). XML was exactly right
for this job, but at that time XML was not very popular, so I chose not to
use it and invented my own format that basically looked like a (possibly
recursive)
  <section_name> <type> <length>
  ....

Which corresponds to the XML
  <type section_name>
  ...
  </type>

Nowadays, unfortunately, XML is so hyped that I hear of people using XML
for things that even a simple tab-separated format would do.

In any case, as these data formats do not contain any executable instructions,
loops, and so on, using lisp would not make much sense. Surely, for hand-
edited input files the power of a programming language (having things like
conditionals and loops) can come in handy, but these aren't essential for
machine-generated data files, which are what most XML files are nowadays.

You might want to compare Postscript and PDF - the former was a full
programming language used as a printed page input format, and it was later
replaced by a more simplistic, not-a-language, format.

-- 
Nadav Har'El                        |       Sunday, May 30 2004, 10 Sivan 5764
[email-masked]             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |A messy desk is a sign of a messy mind.
http://nadav.harel.org.il           |An empty desk is a sign of an empty mind.

---

From: Oleg Goldshmidt <[email-masked]>
Date: 30 May 2004 14:54:03 +0000

"Nadav Har'El" <[email-masked]> writes:

> On Fri, May 28, 2004, Omer Zak wrote about "[hackers-il] Why XML
> caught on where LISP and Scheme failed to?":

> > secret of success of XML. 
> 

Obligatory disclaimer: I know Lisp pretty well, but my understanding
of XML is rudimentary. You've been warned.

Well, from the Lisp (shall I say, abstract CS?) point of view there is
no difference between program and data. If you have a lisp-like
interpreter for Omer's (or similar) XML representation you can write
code. For all intents and purposes it will be Lisp. I don't think that
anyone here will argue that the actual tokens matter[1].

On the other hand, representing structured data in Lisp is also
possible and frequently done. I did it myself a few times, including
writing custom tools to "lispify" and "delispify" independently
formatted data.

I seriously doubt though that there is a "secret" to XML's success on
the technical level. It's not the first or the last markup
language. It's not the first or the last extensible language. I would
guess ("assert without proof," borrowing an expression from Wilson)
that big business support[2] + some familiarity of syntax to those who
had been using HTML "forever" (on the Internet timescale) were the key
factors. I also suspect that XML is successful as a structured data
representation, with custom tools written in every programming
language known to mankind, including, significantly, Lisp.  Since
anybody can write their own tools one can live with structured data
representation and a small (a.k.a. limited) tool, and without a
full-blown Lisp interpreter (but maybe a JVM :).

Of course, there is Greenspun's 10th Rule of Programming:

"Any sufficiently complicated <insert your favourite language here -
OG[3]> program contains an ad hoc informally-specified bug-ridden slow
implementation of half of Common Lisp."

All the rest is likely to be religious wars. ;-)

[1] One can argue that XML tags afford you some additional capabilities
    w.r.t. error checking, since the closing tag echoes the type of the
    opening one. Any decent editor will match parentheses in Lisp code
    though, making such checking very easy.

[2] IMH(umble)O the same is true, to a significant extent, for Java.

[3] The original said, "C or Fortran" - OG ;-).

-- 
Oleg Goldshmidt | [email-masked]