[Axiom-developer] Re: converting sexps to XML

[Bob McElrath]

Kai Kaminski address@hidden wrote:
> or something similar, although you probably wouldn't want to. You can't 
> compare Lisp and XML, Lisp is a language, XML is a mark-up scheme. 

I think we can reduce this problem to one of *validating* XML (or
sexp's).  Assuming the sexp is solely data (no macros or functions),
we can always 1:1 translate a tree into another tree (regardless of
markup), what we must do is make sure that the set of tags and
attributes are defined by the schema.  Validation could be done directly
on an sexp if the scheme were known.

This page has a whole lot of discussion of XML, sexp's (from scheme's
perspective), validations, and transformations:
    http://okmij.org/ftp/Scheme/xml.html

> Do we really need the ability to generate all kinds of XML from within a 
> HyperDoc page? I thought that the HyperDoc pages would look something 
> like this (in LaTeX notation):
> 
> \begin{paragraph}[editable]
>  some text
> \end{paragraph}
> 
> and that the back-end would transform this to something like
> <p class="editable" ...>
>  some text
> </p>

I think these two ideas are very distinct.  A latex document is
processed from top to bottom, once.  A change requires essentially a
re-compile of the entire document.  Syntactic validity cannot be ensured
in a sub-document of latex.  (e.g. I could insert "\end{paragraph}" in
the middle of my paragraph...causing the parser to totally barf)  

On the other hand XML has the concept of a DOM, which allows me to
examine nodes individually, add/remove nodes, and modify the text inside
a node, all in a self-contained manner.

Do we want to have both forward and backward translation of hyperdoc to
xml?  This seems very redundant.  I would say pick one format and be
done with it.  However I suspect if I suggest translating all documents
to XML/SGML I will get pelted with rotten tomatoes.

> and also insert the necessary Javascript to make sure the paragraph is 
> actually editable. 

This is almost trivial and actually requires the insertion of *no*
javascript.  e.g. the interface finds the paragraph clicked on with the
"editable" class, and modifies it.  The paragraph itself need not have
any javascript.  (not even an onClick).  Before displaying the document
the javascript can always traverse all "editable" objects and add the
onClick property.

> another issue with having too powerful a page language is that it is 
> difficult to process automatically. you can't validate the pages, you 
> never know if they'll finish rendering eventually or not. We would not 
> only have bugs in the GUI and Axiom but also in the documentation. And 
> if we ever change some aspect of the standard look-and-feel someone will 
> have to go and hunt down and fix dozens if not hundreds of pages 
> containing some Lisp that doesn't mix well with the new standard. If the 
> language is simple markup, we just change the rendering code in the GUI 
> back-end and all pages look all new and shiny.

Perhaps this is a nice separation between interface and documentation.
The document (whether latex/xml/sexp) contains no code, only "hints"
such as "editable".

I worry that in our mad rush to make an interface, somewhere we will
make it not possible to simply print a page and call it "documentation"
without the interaction piece.  (I think hyperdoc already has this
problem)

> If we really want to offer the full power of Lisp, that's easy, too. 
> Give the user the option to supply a Lisp source file as the page 
> source. We would offer some convenience functions/macros of course, 
> something like the following maybe:
> 
> (define-hyperdoc-page
>    :title "MyPowerfulPage"
>    :axiom-ref "MPP"
>    :content #'my-powerful-page)
> 
> (defun my-powerful-page (stream)
>    (with-html
>       ....))
> 
> But I don't think that forcing that degree of control onto everyone on 
> every occasion is a good idea. The other problem is that people would 
> have to learn Lisp or something similar. A good datapoint is LaTeX. It 
> is programmable, but most people don't care. Everyone uses \newcommand, 
> but mostly for abbreviations and other simple things.

I think adding too much power to the document is something to be
avoided.  Both Maple and Mathematica are converging on having a full
operating system, window manager, object-oriented, functional,
list-based language built in.  (not to mention math)  This is just too
big.  The number of bugs scales as the number of
(features/lines-of-code/api calls)^N where N is large.  Furthermore you
end up with a system that is so complex, and has so many interactions
that no one can use it.

For instance, in Mma, copy some output text, and paste it to an input
line.  You get an error:
    "You are attempting to paste a TraditionalForm expression into a
    StandardForm cell.  If you want to be sure that the meaning of the
    expression will be preserved, you should first convert it to
    StandardForm."  

    (Paste with a FormBox wrapper) (Paste literally) (cancel)

What the hell is all this and why should I care?  Why does a math
program have an interface element built in?  (FormBox)  After I paste it
literally it becomes some beast that one cannot edit any longer.  If I
paste it with FormBox it is not executable.  Why does it let me paste
non-executable things into an executable input cell?  Finally, I cannot
convert to StandardForm without entering
%//StandardForm, then hunting through to find what I originally
%selected, re-cut and paste.

Point is, all this is complicated, and unnecessary.  I believe we should
avoid at all costs design decisions which will push us to add buttons,
boxes, etc. to mathematics.  Interface should be interface and math
should be math.

Where interface/math interactions are required, the interface should
identify the piece of math (e.g. term 7 in expression 5) and tell that
to the back-end, and *never* actually go through the step of capturing
output and feeding it back to the back-end as input.

simplify simplify simplify.

I think this suggestion can be accomplished entirely by marking text.
e.g. in some MathML every identifier can be labelled with an id and
class.  It is the interface's responsibility to tell the back-end to do
something with id=47 in class=sum.  We must keep the interface from
having to know any math, lest we find ourselves re-implementing axiom in
the interface.

--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]

    "One of the best ways to get yourself a reputation as a dangerous citizen
    these days is to go about repeating the very phrases which our founding
    fathers used in the great struggle for independence." --Charles A. Beard

signature.asc
Description: Digital signature