[Axiom-developer] document, graphics

[Bob McElrath]

I would like to separate this discussion for the purpose of clarity.
First, I have been discussing mostly document processing, and
interaction with mathematical output.  As I've suggested, I think this
can be accomplished with an absolutely minimal API:
    AppendInput(input)
    ModifyInput(line, newinput)
    GetOutput(line)
    ComputationStatus()
where the GetOutput call returns an sexp or xml document containing no
code, but hints such as "sumterm1", "paragraph", "type".  Dependency
tracking/re-evaluation can be handled inside Axiom.  The last call
ComputationStatus should return a list of lines for which computation is
underway or need re-computation.

The second part of the discussion is non-mathematical input/output.
e.g. graphs, diagrams.  Can we do the same thing as for mathematical
output?  (e.g. the output contains only data structures and hints, and
no code?)  This requires a graph renderer/manipulator which understands
the underlying data structure.  (e.g. 1-dimensional point set,
2-dimensional graph, 3d point set with mesh, etc) "understanding the
data structure" is a separate problem from "communicating the data
structure" since the latter can be simply marshalled into an sexp or XML
data structure.

Furthermore "draw" should really be an alias for "give me a point-set
approximation".  Axiom generates a point-set.  The *user-interface* must
decide what to do with it.  Axiom shouldn't care whether it ends up in a
pie chart or bar chart.  These are user-interface concepts, not
mathematical concepts.

So, I seem to be convincing myself that I want a back-end which knows
absolutely nothing about user interfaces, but can serialize its output
in either sexp or xml.

Kai Kaminski address@hidden wrote:
> >So you're proposing *three* applications?
> >1) axiom
> >2) sexp -> xml converter
> >3) web browser/javascript
> >
[...]
> Even in the beginning part 2) will be more than an sexp-to-xml 
> converter. Take plots as an example. Axiom supplies a list of points 
> that have to be connected with straight lines/splines/whatever. Then 
> part 2) generates SVG output, which isn't too hard but not trivial 
> either. Suppose the plot contains some text, like a title or a 
> description. We can't just stuff the text into the SVG file, because in 
> XML certain characters have to be escaped. I don't want to implement all 
> this in Javascript. But I don't want to have an SVG generator in Axiom 
> either.

Why would escaping of characters not be part of a sexp->xml converter?
It's a general translation problem, no?

If there is not an svg generator in axiom, what format should axiom
present?

I looked a bit for lisp/scheme scientific graphics libraries, it seems
such a thing is almost non-existant.  :(  SVG scientific graphing is
also non-existant.  Perhaps a scientific SVG generator should be a
completely separate project.

Knowing how we are going to plot...what format the data should be
in...what interactions are possible...would be useful.

> Suppose we want to support LaTeX as an input syntax for 
> HyperDoc pages or something similar (Martin Rubey wants this, as I 
> understand). Do we want to put a LaTeX parser into Axiom? Do we want to 
> implement one in Javascript? 

This is fundamentally impossible because LaTeX is mathematically
amgibuous.  e.g.
    \int_a^b x d x
    \int_a^b d x d x
'd' is a constant.  For that matter presentation MathML is also
mathematically ambiguous.  (hence the creation of content mathml and
OpenMath)

> GUIs are complex and Javascript is an awful language without a 
> development environment (correct me if I'm wrong). If, some day, we add 
> complex behaviour to the Axiom GUI I'd much rather implement that in 
> Common Lisp and push the results to a web browser than implementing all 
> that in Javascript.

I agree on the awful part.  However by writing an XPCOM component for
mozilla, we can offload intensive processing (such as real-time graph
manipulation) to native code.

We should restrict javascript to solely interface elements, and not
allow it to do any mathematical processing.

> >Why should axiom "deliver" help pages at all?  Why can't the interface
> >read them directly off the disk?  And when those help pages contain an
> >axiom session, why can't the interface start a new session for
> >evaluation (so that it does not interfere with the main computation).
>
> AJAX wouldn't work then, but using Mozilla-specific extensions there is 
> obviously a way around this as you have shown with your example. But if 
> someone creates a new HyperDoc page he will have to include the 
> necessary Javascript as well and he will have to write it in HTML.

One wouldn't need AJAX for help pages...or even file access as I have
used in my example, but rather just <a href="file:///...">.

Re: "new hyperdoc page".  For the time being I think we should
concentrate on all new hyperdoc being in the current pamphlet format.
For this interface we can convert to HTML.  In the future we can
contemplate converting pamphlet -> html en masse.  But for now let's
keep an HTML UI document separate from a pamphlet.  We should engineer
things so that we can do a trivial HTML UI document -> pamphlet
conversion.  Javascript is in the document for UI elements, but would be
stripped for pamphlet conversion.  A proper pamphlet representation
should not depend on javascript, or running any code other than what can
be delivered to the axiom engine.

(Does the reverse hold?  Do pamphlets have additional logic other than
what is delivered to axiom?)

> I would much prefer to have a different format for HyperDoc pages than
> HTML, because HTML doesn't capture the semantics of Axiom or HyperDoc. 

Who cares?  We have axiom input (which is just text -- and always should
be) and output which is proper HTML/XML.

> Consider the command line as an example. If we store the pages as HTML 
> so that they can be read by a browser we would probably include some 
> Javascript similar to what I've used for my dynamic jsMath demo. Now 
> imagine that maybe in two years the W3C includes a tag in HTML that does 
> pretty much the same, just better or more beautiful. 

"Pretty much the same" -- you mean rendering the latex?  You mean
MathML?

Yes, HTML documents which jsMath/latex in them will have to be rebuilt,
but this should be as simple as typing "make" if axiom knows how to
generate both latex amd MathML.

> Then we'll have to 
> go through all pages using a command line, rip out the old code put in 
> the new one. If we have our own format for HyperDoc pages (XML with a 
> HyperDoc DTD, sexp-based, LaTeX-based,...) we just change the code in 
> the middle process that is responsible for rendering the HyperDoc pages 
> to HTML and they are all new and shiny.

What I am saying is equivalent.  But you're forgetting that the hyperdoc
pages are built as part of the build process.  So the "code in the
middle" is essentially the build code.

> Of course we could just do the 
> conversion once, every time something like this happens, but that would 
> require us to keep two versions of every page around and sooner or later 
> people would try and modify the rendered HTML instead of the page source.

As I mention above, let's keep "pamphlet" as our primary format for the
time being, and convert it.

When/if we have a new format that we deem as powerful and a suitable
replacement for the latex-based pamphlets, we can convert en masse.  But
that's far down the road.

[re: documentation]
> >The only thing missing from this idea is "search".
>
> Good example. Search is complex. Do we implement that in Javascript or 
> will the search code be part of Axiom? If we have a process between 
> Axiom an browser we can just put it in there.

Neither.  It is a user interface issue, not a mathematical issue.  It
should be in the user interface, somewhere.  (though god no...not in
javascript)  An XPCOM component could do it.

Also note that one could generate an index file with words and URI's.
This could be parsed by javascript to make an efficent search engine.
(But, all the logic has been moved to the build system which generates
the index file)

> I'm not sure what you mean here, but I assume that Axiom already 
> incorporates code to generate plot data. We can use that to create SVG 
> files, which look very nice. PDF is also easy, because of cl-pdf.

I installed a mozilla svg build.  (Hard to find actually -- SVG is not
enabled on linux yet)  I found some interesting examples:
    http://www.croczilla.com/svg/samples/dom2/dom2.xml
this one rotates/translates/scales a polygon using DOM/javascript.  Also
hit "Dump XForms" after doing a couple of operations.  It keeps a list
of transformations that in principle can be converted to axiom commands
and passed back.  Note that this really is "knowledge of the algebra"
that I advocated avoiding above.  Graphics implies a much tighter
coupling between the algebra and graphs.  Nonetheless, I think axiom
should generate point-sets, and an interface should generate axiom
commands.
    http://www.croczilla.com/svg/samples/events2/events2.xml
Someone was worried about drawing on the screen.  With SVG I think it
would be trivial.
    http://www.croczilla.com/svg/samples/xbl-shapes2/xbl-shapes2.xml
Another user-interaction with SVG.

Keep in mind that SVG+DOM has all the elements for a user interface to
graphs.

--
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