[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] RE: XML

From: Page, Bill
Subject: [Axiom-developer] RE: XML
Date: Tue, 14 Jun 2005 23:24:06 -0400

On Tuesday, June 14, 2005 9:54 PM Tim Daly wrote:

> having lost a year of my life working with XML, XSLT, DOM, SAX,
> JDOM, etc. i can honestly say that i'm religiously opposed to XML.
> you're welcome to try to convince me otherwise but i warn you that
> it is a hard fight as i have a lot of really bad war stories. XML
> is a dead-end technology.

I never argue about religion :) But I used to be a statistician ...

A Google search says:

  Results 1 - 10 of about 191,000,000 for xml
  Results 1 - 10 of about  48,300,000 for xhtml
  Results 1 - 10 of about   8,430,000 for XSLT

> it is the PL/I of web standards. i'd bet you don't program in PL/I
> (which i did) and you won't use XML in 5 years.

As a matter of fact my first programming language *was* PL/I on
an IBM 360 (my second was FORTRAN on an even older IBM computer)
when I was still in high school. And there was APL on a CDC 6400 ...
but don't get me started!

IBM still supports PL/I on UNIX and on Microsoft Windows

There is even an active open source project to revive PL/I as a
GNU language

A Google search says:

  Results 1 - 10 of about 1,240,000 for "PL/I"

So I think it is safe for me to make the counter-claim that PL/I
is not dead and also that XML is more than likely to be still
around in 30 years time.

> that said, this IS open source so you're welcome to pursue the
> path you feel will be best regardless of the curmudgeon in the
> corner.

I like old war stories as much as the next guy ;)

> if we do plan to rewrite the syntax of browser pages i'd prefer
> a lisp-like syntax which would allow us to (a) use the lisp
> (read) and (b) define functions dynamically. this would be
> especially useful as most of the new browser is to be implemented
> in lisp.

Don't get me wrong, I like lisp (although I probably haven't
written more than 20 lines of lisp code in my life) but I
sometimes wonder where lisp will be 30 years from now?

A current Google search returns:

  Results 1 - 10 of about   3,410,000 for lisp  

Keeping programs like Axiom, Maxima and ACL2 alive could very
well help to keep lisp itself alive.

But anyway, I don't see the relevance of either (a) or (b) in
this context. I don't see much difference in parsing a text
stream delimited by parenthesis ( ) compared to brackets < >
Defining lisp functions seems way beyond what would normally
be expected of a browser.

I don't see why you say "most of the new browser is to be
implemented in lisp". As I understand it, that is only one
possible option (if we were to use something like GTK). What
Kai is proposing on the other hand is using an off-the-shelf
web browser (such as FireFox or Mozilla). The lisp code that
he would write implements only the web *server* component, not
the browser. And most of the needed lisp code already exists
in common lisp. What he needs to do is develop the interface
between the web server and Axiom.  One possible option for
doing that involves just writing lisp code in Axiom itself.

>  so instead of
> <a href="foo.html">foo</a>
> you get something like:
> (anchor "foo.html" "foo")

But what do you gain by doing this?

> however the browser pages are fairly close to latex and the
> latex-wiki code can display latex so why rewrite them
> completely?

LatexWiki depends on a huge set of software: Python+PIL, Zope,
ZWiki, tex, ghostscript, etc. just to name the major components.
This is a very large stack of code for a workstation just to
edit and display some mathematics! The web page layout in
LatexWiki is still ultimately done by HTML and the web browser
even though for easy editing it also supports a simpler layout
language called "structured text" as an input language.

In a browser like FireFox a fairly large javascript program
called jsMath (about 140 Kbytes) can be use to render latex
equations and math symbols, but this does *not* include the
text layout, which in web browsers is done by HTML and CSS.

For compatibility with a web browser, the existing latex-like
coding for the Axiom browser pages (except for the mathematics
itself) must be re-coded as HTML (which in modern form is
known as XHTML and is a particular application of XML).

> besides there is functionality there which does not exist in
> XML. For instance you'll see pages which say:
> \spadcommand{x:=2}\bound{x}
> \spadcommand{y:=3}\bound{y}
> \spadcommand{x*y}\free{x}\free{y}

It is peculiar to say that something does not exist is XML since
XML is only a meta syntax. One might as well say that it does not
exist in lisp. But that is irrelevant. In XML nothing stops us
from inventing a syntax for the commands above. For example:

<spadcommand bound="x"}>{x:=2}</spadcommand>
<spadcommand bound="y">{y:=3}</spadcommand>
<spadcommand free="x,y">{x*y}</spadcommand>

In fact that is (more or less) exactly what OpenMath attempts
to do.

> clicking on the third expression tells the browser that it
> needs to find a meaning for x and a meaning for y somewhere
> prior in the page. these are determined by the \bound expression.

I can understand why Axiom needs to know this kind of thing,
but I don't understand how the Axiom browser would use this
kind of information. Can you give an example?

> given the 90 days and assuming 100 lines of code per day (ah,
> to have such productivity i'd give a leg) we're talking 9k
> lines of code for the summer. 

I think for this reason the most effective use of resources is
to write as little new code as possible. One can get the most
mileage out of integrating and modifying existing code for our
purposes. One major component of this is to assume the use of
a modern web browser at the primary means to implement the user
interface. The other existing major components include javascript
such as jsMath and AJAX (aka Asynchronous JavaScript and XML)
and common lisp code for the web server.

I think one should be able to do quite a lot with 9k lines of
lisp and javascript in such an environment.

Bill Page.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]