Re: Open Source XML Editor

[Michael Smith <smith@xml-doc.org>]

Matt Sergeant <matt@sergeant.org> writes:

> I've been holding off on this so that xml.com could publish the article,
> but for those wanting an open source XML document editor, you may find
> http://www.xml.com/pub/a/2001/02/07/openoffice.htm interesting.
> 
> Summary: Author in OpenOffice, save as XML (or in StarOffice 6, the
> default save format), use tools I wrote to convert to docbook, or other
> formats, and you have a perfect tool for the job (IMHO).

Regarding a key point you make in the article:

  What XML geeks really want to see is a free WYSIWYG XML editor like
  XMetaL or Adept. And here it is. If we restrict ourselves (or our
  customers) to using defined styles, OpenOffice can truly be a
  structured XML editor, without ever knowing you are editing XML.

Isn't the main value of a structured or so-called "validating" editor
like XMetaL or Adept/Epic (or Emacs/PSGML, or a WYSIWYG editor like
Morphon or epcEdit) that it enables validated editing against any
_arbitrary_ DTD you plug into it, and gives you clear, direct access
to the structural and semantic richness/complexity of that DTD?

That is, what I think most people have in mind when they hear the
phrase "structured XML editor" is an editor that constrains document
authors to all rules of whatever DTD they want to author with --
including restrictions on element order, on attribute values, and so
on -- not just that it constrains them to a certain set of elements.

I can see a lot of value in the OpenOffice XML format, and recognize
that it may make it easier to author relatively simple documents in
XML. But it can't make authoring of complex XML documents any easier.

The main difficulty I hear about authors running into when authoring
complex documents (with or without XML) is not the lack of WYSIWIG
editing interfaces -- it's lack of guidance in deciding (1) what parts
of their content need to be marked up and (2) how those parts need to
be marked up (i.e., what elements/tags they need to use, and where).

Even with the best editing app in the world, I think document authors
find structured authoring simple only when the content they need to
mark up is simple -- that is, it has a simple structure and lacks a
variety of discrete classes of "objects" that need to be marked up.

Marking up technical documentation, for example, is inherently
difficult because it has a relatively complex structure and variety of
discrete kinds of objects -- variables, filenames, code examples, and
so on -- that authors must recognize and mark up appropriately.

It seems to me that task can become _more_ difficult the further you
obscure the complexity of it from the document author. That is, unless
document authors are creating very simple documents, the goal of
allowing them to write without ever knowing that they're editing XML
is simply not possible. You might in fact just end up further impeding
them by putting another layer of application opacity in their way.

   --Mike Smith