John Barton (jjb at watson.ibm.com) wrote:
: Could you outline the key reasons why another formating language
: is preferable to better translators between the ones we already
: have and better than extensions to languages still in flux like
: HTML+? With due respect to your effort here, is another incompatible
: format what we need at this point?
We have thought about this and came to the conclusion that neither
HTML nor LaTEX nor RTF are easy to write. What we (i.e. biologists) need
is a simple language which will allow anyone to write without in-depth
knowledge. Historically, the discussion on a reasonable 'faq format'
pushed us to formulate a language based on previous experience we had
with the Survival Guide. The 1990 version of the Biocomputing Tutorial
was in LaTEX and difficult to update. The 1993 version of the Biocomputing
Survival Guide was in MS Word and lots of people complained. We tried
various translators and found that none of them gives a reasonable,
cross-compatible format.
Key features why we like JAM are
* No need for the average user to modify any text. Just start the
application (which is provided in binary format) and click on the
items which shall or shall not be included. Select format, operating
system and site-specificity by a mouse click.
IMPACT: One single image (the jam application) fits all. No need for
translators and learning inclusion, conditional or other statements.
* It is available *now*. Extensions like HTML+ started promising and
are still pending, but the current versions are useless for now.
* It produces _identical_ text in all languages. What a link is in HTML
will show up as boxed command in LaTEX, and as boldface italics in
RTF. What the user sees in print shows up as 'live' page on the screen.
* It has (will have) the abilities of a menu system (still to be
released). What we showed on the Bio-MOO seminar was the extension to
the HTML version. The slide shown was the following:
**********************************************************************
WHAT NEXT?
We anticipate to have the links more active. If the user selects the
command, it shall be executed on this home shell. The way how to do
this is to use a special MIME type and transfer the command to a
program on the user's side. This program is called a JAM REFLECTOR.
user ----> JAM HTML document ----+
|
REFLECTOR <------ CGI script --------+
|
v
program at the user side
*********************************************************************
The reflector system allows to have the user use JAM HTML as if it were
a menu system. The receptor system is a GUI which allows even parameter
selection at the local site. We will release a biocomputing general
purpose interface which uses this principle.
* It is _simple_ - if you do not include links it takes you 6 commands
to learn, and it is ASCII readable (in contrast to LaTEX and HTML, not
to mention RTF).
We are aware of the problem that there are other 'standards' and consider
these as options for colleagues who want to go the complicated route. JAM
is a successful approach to demystify different presentation techniques
(electronic, printed, profesionally typeset) in a very intuitive fashion.
We are already running JAM in-house in combination with the HASSLE protocol
and expect to release the Reflector/Receptor system early next year.
--
+-------------------------------+----------------------------------------+
| Biocomputing Survival Guide | contributions to: |
| | survival at comp.bioz.unibas.ch |
| Biozentrum der Universitaet | FAX x41 61 267 2078 |
