Re: Text processor

[Bruce Stephens <bruce cenderis demon co uk>]

Havoc Pennington <rhp@zirx.pair.com> writes:

> No DTD, no DSSSL, no XSL. Something much simpler. A "proprietary"
> format; perhaps saved as a standalone XML document, but that's an
> implementation detail. Trying to implement those complicated specs
> is what always stalls these projects; even the command-line SGML
> tools are fairly lame compared to proprietary offerings. Granted,
> XML and XSL are supposed to be simpler.

Yuck.  Give me a format I can grep, anytime.  

How about the following:

        The editor reads and writes SGML (or XML, if you prefer) in
        DTDs it knows about; it rejects anything it doesn't recognise
        (potentially, it could display something for unrecognised XML,
        but that can come later)

        It uses some "proprietary" way of finding out how to present
        and edit documents.  Thus, for DocBook, it would know that
        <sect1> should look like a section (and can only be used in
        certain places), and that <emphasize> can be used pretty much
        anywhere to emphasize text.  Obviously, it'll present these
        things in some way which doesn't require the user to see the
        tags.

        Implementationally, it can use existing libraries to parse the
        SGML---parsing SGML is hard, but it's already been done.
        Similarly, it can use DOM for manipulation, and the writing is
        a solved problem, too (and is pretty easy anyway).

        Conversion for printing (and pretty viewing---like DocBook to
        HTML, for example) can be done using the existing sgmltools
        (with DSSSL).

> I don't want to see any tags. The structure should be there, but it
> should be implicit; it should be visually represented via bold, font
> size, and layout. Should also be possible to move structural blocks
> as a unit via drag-and-drop.

Some aspects need to be more visible than that.  It's quite ordinary
for two structurally different objects to be represented
indistinguishably, so there'll need to be some way for me to see which
fixed-width-font things are supposed to be filenames, and which are
supposed to be bits of example text (say).  Having multiple views
available of the document might be the right way to do this.  

Moving stuff around is a hard problem---some movements are legal, and
some reasonable sequences of movements (which will, ultimately,
produce a valid document), involve intermediate invalid documents.
Perhaps the answer is to have two levels of compliance that the editor
knows about---so it can continue to manipulate techically invalid
documents, but can make sure the user knows when the document is
invalid.

Amaya, <URL:http://www.w3c.org/Amaya>, does some of this, for HTML.
Have you people looked at Amaya?  How do you evaluate it?