Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 May 1997 11:06:10 -0500 (EST)
From:      John Fieber <jfieber@indiana.edu>
To:        Amancio Hasty <hasty@rah.star-gate.com>
Cc:        "Pedro F. Giffuni" <pgiffuni@fps.biblos.unal.edu.co>, hackers@FreeBSD.ORG, doc@FreeBSD.ORG
Subject:   Re: Is Thot (WYSIWIG editor) for you? 
Message-ID:  <Pine.BSF.3.96.970514075151.311s-100000@fallout.campusview.indiana.edu>
In-Reply-To: <199705140805.BAA03496@rah.star-gate.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 14 May 1997, Amancio Hasty wrote:

> For sure the algorithms used in Thot are worth looking into.
> 
> What I am pitching is for is that if Thot is good we can start advertising it
> and hopefully standardize our internal documentation based on its format.
> Internal documentation meaning things like : reports, articles, etc...

It is important to make clear the difference between
standardizing the *data* and standardizing the *application*.
The computer industry on the whole has focused on the latter to
the benefits of vendors and at great cost to the user.  The
typical user has a much greater investment in their data than in
the software they used to create it, yet the data formats are
only of secondary consideration.

Breaking this dammaging tradition requires inverting the standard
line of "does it work with my favorite application" and thinking
about in terms of "does the application work with the data".  For
this to work, the data standard must be nailed down.  This is
where SGML, or possibly its recent offspring, XML, come in.  SGML
is application neutral, yet flexible enough for most any
documentation task.  It is rapidly gaining momentum as well.
Corel WordPerfect, for example, is quite proficient at dealing
with SGML documents and is even shipped with the Docbook DTD.
Even Microsoft is drifting (slowly) toward SGML support.

The critical thing is that SGML documents can be exchanged
between all these tools with absolutely *no* markup loss or
corruption.  The same cannot be said for any other format that
I'm aware of.

Basically, understand the data, then write the application.  My
concern is that the focus here is on the application (Thot).




About the application, from by brief exposure (via Amaya) the
general model that Thot uses is seems to be conceptually
compatible with SGML, but I don't know how well the compatibility
carries down to the nitty gritty details.  If it doesn't it
shouldn't be too much of a stretch to fix it.

However, a year or two ago I did a little research project on
structure enforcing editors for both programming languages and
human languages.  The problem with all of them is that they tend
to impose the structure of a *finish* program or document.  The
only time the program exists in that state is when you are done
editing it.  During the editing process, it is absolutely
essential that an editor allows the authors to create and fiddle
structurally/syntactically incorrect document fragments with
ease.  If not, the editor will hinder more than it helps.

My only experience with Thot is through Amaya and my initial
impression was that it would be a royal pain to actually write
something with it.  Other SGML editors are afflicted with similar
problems.  In my opinion, emacs+psgml strikes a nice balance by
allowing you to check structure/syntax and get help on
structure/syntax without actually imposing it in a dictatorial
fashion.  (...but I personally use nedit most of the time...) 

-john




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970514075151.311s-100000>