RE: Emacs as word processor

[Drew Adams <drew.adams@oracle.com>]

> In the context of a WYSIWYG word processor, why in god's name
> would the user be specifying a DTD?

(Why would anyone want to do anything in a god's name, unless
s?he were running for some kind of high priest?)

---

FWIW, and without wanting to dig further into this discussion:

Doc tools used by doc professionals include some that are both
WYSIWYG and structure-based.  And these are typically considered
the best doc tools available currently.  Examples: Framemaker,
Arbortext, and XMetal, with Framemaker being somewhat better
than others in the WYSIWYG department. 

Such tools are typically XML-based nowadays.  They are in fact
XML editors, and generally have excellent round-tripping.

Structure is enforced by XML validation against a DTD or an
XML-Schema schema.  And there is excellent support for structure
editing, both lax (you can create invalid structure and clean it
up later) and strict (you can perform only actions that do not
invalidate the structure, even temporarily).

And yet the display and interaction can be WYSIWYG.  There are
typically multiple views: from WYSIWYG (sometimes multiple such,
depending on what is to be shown/emphasized) to XML markup using
plain-text, with combinations: WYSIWYG but showing XML elements
and attributes.

Typically, such views are not just push-a-button-to-update-result.
Each view is editable, and the effect is reflected immediately in
any and all of them.  Typically, a user edits in both a structure
window and a WYSIWYG window, using whichever is handier for the
editing task at hand.

All this is to say that a structural - and even a textual,
markup, plain-text representation of a document - is NOT
incompatible with a WYSIWYG representation, and the two are not
incompatible wrt interactive editing.

That said, these are mature products with lots of hours of
development behind them.  Emacs could of course try to progress
in such a direction, adding such to its wishlist.  But in that
case I'd suggest biting off small pieces to attack at a time,
as the full realization of something like this would be a lot
of work.

Emacs could choose to build such an effort on top of XML or
JSON (?) or TeX or Org or whatever.  Or just Lisp sexps (lists).
For purposes of exchange and pluggability and tools (e.g. XQuery,
XSLT), XML could be a natural choice.  But then again, those
things are ultimately about I/O and persistence - they impose
nothing about the implementation.

To be clear, I am not proposing that Emacs develop such
capabilities, nor am I opposing that.  Just providing some info.

(BTW, my advice is to forget about MS Word, which much of this
discussion has turned around.  MS Office products are now based
on XML.  But as others have pointed out, it is not the best XML.
And interactively the products are far from a guide wrt what
Emacs could/should do.  The best that can be said for them is
that their use of XML can at least now let other XML-based
products exchange data with them and manipulate their documents,
modulo hiccups.  And they will no doubt get better with time.)