[Top][All Lists]

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

[Axiom-developer] Re: Axiom wiki

From: Bob McElrath
Subject: [Axiom-developer] Re: Axiom wiki
Date: Fri, 9 Jul 2004 17:31:14 -0700
User-agent: Mutt/

root address@hidden wrote:
> Bob,
> Since there hasn't been any discussions of the long term goal of
> the axiom wiki I guess it's normal to see things move in surprising
> directions. Here are some of the thoughts that Bill's work inspire.
> Axiom is based entirely on pamphlet files. Pamphlet files are just
> standard latex with a couple extras to support "inline" code in
> the file. They are the basis of the literate programming style in
> Axiom. So every file in Axiom is a pamphlet. I'm not familiar with
> the details of "pagetypes" but perhaps a pamphlet pagetype is needed.

A PageType is a ZWiki construct that encapsulates an input format such
as StructuredText, HTML, StructuredText + LaTeX, etc.  See

The format I have been using is StructuredText + LaTeX.  Let me give a
little history on this before you all go converting documents en
masse...  StructuredText (stx) is a big hack of formatting rules piled
on top of one another using regexes.  It is not well-defined as a
structured grammar.  (Though I have been working on this)  For instance
it has no well-defined mechanism to escape markup.  If you play with it
long enough you WILL run into bugs, particularly when mixing escaping
mechanisms (! for stx, \ for latex).  It is nice because it ignores HTML
markup embedded in stx, so you can mix the two.  It is simple enough
that anyone can write it, but really, it is a toy.  I would not want to
base a large project or documentations system around it.  Eventually its
design limitations will become a hinderance.

reStructuredText (rst) is an attempt to more formally define the
grammar.  However its rules differ significantly from StructuredText,
and it uses the backslash as an escape character, meaning mixing latex
with it may be difficult.  However as it is a defined grammar one would
need to add latex syntax (including math) rules.  If someone wants to
investigate further this would be interesting.

This leaves pure latex as an input format.  Now, clearly, pure latex is
an appropriate and powerful input format for documentation.  latex2html
can already generate html (though it is archaic and equations are poorly
aligned -- but we can work on that).  There is also the tex4ht variant
of latex2html which can output mathml.  This is all done using latex
commands and style files, and is rather slow.  Appropriate
web-representation would mean:

    1) separate the Big Book into individual pages (chapters?)
    2) hyperlinking
    3) referencing/footnoting
    4) in-page hyperlinking for equations a la existing latexwiki?

So I see a couple options for all this:

    1) Use a front-end to convert pamphlet files to a web-appropriate
    format (stx + latex or rst + latex)

    2) Use latex all around, defining a new pagetype.  The pagetype does
    not have to be axiom specific, but it could be.

I think the existing stx+latex can co-exist with a pure latex format.
Users can "play" with stx+latex, and more formal documentation can be
written in straight latex and placed on the web (but would not be
user-editable -- this also alleviates the security concern I mentioned
earlier if \write18 is used).

> If the Axiom wiki effort can support pamphlet <=> webpage translations
> it would have two benefits. First it would provide an interesting
> front-end to Axiom, especially with Bill's automation of running
> Axiom on a wiki web page. This turns out to be nearly as powerful
> as Mathematica and Maple notebooks. In fact, with some clever web
> page buttons we could probably reproduce their complete functionality.

Have you looked at Mozilla's XUL?

Since Mozilla already knows about MathML, a complete user interface for
a computer algebra system could be implemented in a totally
platform-independent way inside mozilla, running the axiom process
locally or remotely...

> If web pages could be converted to, or written originally on the wiki as,
> pamphlet files then it would be possible to maintain Axiom directly on
> the wiki which would practically be a research breakthru. It would
> eliminate the hard-to-use CVS mechanism, enable people to use Axiom
> directly as a "service" and encourage open math development on the wiki.

Don't underestimate the usefulness of the CVS revision-and-patch
mechanism.  I've been using darcs lately (better-than-cvs replacement)
and it does this very nicely, incorporating things into logical
patchsets which can be exchanged.  Placing files on the wiki and
allowing multiple editors would result in many small edits, and it
becomes difficult to track down (and possibly revert) dangerous changes.

Especially with mathematical content, changes should be encapsulated in
logical units, carefully reviewed by experts, and run through numerous
test cases to ensure mathematical correctness.

> I've been struggling with the issue of how to develop a browsing 
> structure for Axiom's pamphlet and this wiki has great potential
> to solve that problem in a truly novel way.

It also gets indexed by google.

> Axiom uses a fairly limited range of Latex mostly because my Latex
> talents are limited. Support for the \begin{array} environment or
> the \begin{thebibliography} environment are about the most difficult 
> of the parts of the Latex used. (Actually, if the \bibitems in a 
> bibliography were automatically turned into hyperlinks that would
> be sweet).

This is something that has been on my TODO list for LatexWiki for a

Bob McElrath [Univ. of California at Davis, Department of Physics]
    It is unpatriotic to question the Kleptocracy.

Attachment: signature.asc
Description: Digital signature

reply via email to

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