RE: [docbook-apps] Using OpenOffice as a DocBook editor

["David Cramer (Tech Pubs)" <dcramer@motive.com>]

> > I think to convince non-geeks, you have to give them something
that's no
> > more complicated than Frame wrt tagging, crossreferencing, etc. and
in
> > addition gives them convenience tools that repay them immediately
for
> > the extra effort of doing semantic markup (e.g. various views of the
doc
> > based on the semantics: a list of figures, tables, remarks, that
make it
> > possible to move around quickly...like Word's Document Map but with
> > semantics).
> 
> If the style information reflects semantics, and is available in the
> saved
> document... why put in the extra effort David?

Not completely sure what you're asking :-) But I'll elaborate: 

The problem I see is that while some existing xml editors give you
convenience features for DocBook out of the box, none really matches the
ease of use of a garden variety dtp tool. Take xrefs. When you want to
cross reference to something, you probably could pick the title of the
thing you want to xref to from a list pretty easily. With all the xml
editors I've seen you need to 1) Add an id to the element you want to
xref to if you haven't already, and 2) pick your linkend value from a
list of IDs (if you're lucky, the editor will let you do that since it
sees that linkend is an IDREF). Xrefing in an xml editor _could_ be
easier than in a traditional dtp too if the semantics were used. The
ideal implementation would 1) automatically assign unique ids to
elements (or to all elements that are typical xref targets at least) and
present you with a list of titles organized by type. So, for example, if
you're xrefing to a procedure, you insert the xref and have some
convenient way to select your target from a list or lists of titles that
reflects the structure of the doc and lets you easily see which titles
are titles of sections v. procedures v. formalparas etc.

One of the benefits of structured authoring and semantic markup is that
the content is more valuable because it can be processed into various
formats, profiled, processed to meet unanticipated needs etc. What I'm
saying is that the authoring tool as well should use the semantics to
provide the author with information about the doc in real time. For
example, you should be able to have a view along side the doc itself
listing all the <remark> elements and you should be able to filter the
list (e.g. via a text box that accepts a regex by which to filter the
list). The list of remarks doesn't need to show the whole remark, just
enough to give you an idea of what it says. Clicking on a remark in the
list should take you to that point in the document. Likewise, you'd want
a list of figures, tables, etc. I can imagine what the implementation
would look like in several existing xml editors and have implemented a
feature like this in ours (xmetal). 
 
I think the lack of basic convenience features is a hindrance to
adoption. Ironically, it's easy to imagine an editor that not only gives
you the typical dtp convenience features, but does things no
unstructured tool ever could.

David