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 http://www-306.ibm.com/software/awdtools/pli/ There is even an active open source project to revive PL/I as a GNU language http://pl1gcc.sourceforge.net/ 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. Regards, Bill Page. _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
