Re: Request on Cosource: Visual DocBook editor: XML


Subject: Re: Request on Cosource: Visual DocBook editor: XML
From: Paul Rohr (paul@abisource.com)
Date: Fri Apr 07 2000 - 12:48:29 CDT


At 09:43 AM 4/7/00 -0700, Danic, Stephen wrote:
>There's a request on CoSource which could be right up your alley.
>http://www.cosource.com/cgi-bin/cos.pl/wish/info/296
>
>The request is for a visual DocBook Editor.
>
>"I need a document editor which saves XML/docbook documents. This can be an
>extension of an existing editor (Lyx, AbiWord, etc) or a completely new
>application.
>
>"I want to replace all instances of Word97 with an XML editor which enforces
>strict docbook tags. The target users are secretaries, not linux gurus.
>
>"It has to be wysiwyg or at least wysiwym. The text must be rendered on the
>fly. Most computer novices aren't comfortable editing documents in plain
>text. It has to support at least docbook, but it would be more useful if it
>can support multiple document type definitions.
>
>"Most of the existing XML editors (FrameMaker, XMetal, ArborText) are over
>$500."
>
>
>I figured since ABIWord already handles XML storage and rendering, maybe it
>would be easy to extend it to DocBook.

Steve,

Thanks for forwarding this. We've had a few requests for adding DocBook
support to AbiWord, and put a little thought into how this could be done.

If anyone's interested in tackling this, I can think of two approaches which
could be considered.

1. Fork
--------
While this obviously isn't the preferred approach, it is one way to ensure
that any specialized needs for this project get addressed directly in
whatever fashion you wish. The plus side of this is that you can take
advantage of all the work already done for AbiWord, but you don't have to
worry how to integrate your changes with the core AbiWord feature set. The
downside is that it's likely to become increasingly difficult to take
advantage of further work done on AbiWord.

For example, this is the approach currently being taken by the ScriptWriter
folks. So far, since their changes haven't been very extensive --
essentially, they're working around the lack of a template system in AbiWord
-- the "merging problem" hasn't been that big an obstacle for them.

2. Add template support to AbiWord's style system
--------------------------------------------------
AbiWord already has rudimentary support for style sheets, but they default
to a small hardwired set of styles. If you add a template mechanism to
AbiWord (.atw/.abw, instead of .dot/.doc), then any document should be able
to inherit a custom set of styles instead.

From what little I know of DocBook ...

  http://www.oasis-open.org/docbook/documentation/reference/html/docbook.html

... there's a very large set of tags, but it seems plausible that you could
create a one-to-one mapping between:

  - named paragraph or character-level styles in AbiWord and
  - individual DocBook tags

Once the template mechanism is in place, the DocBook-specific work would
divide into the following three steps:

  - devise a DocBook template which defines one style for each tag
  - add custom DocBook importer & exporter to convert between styles & tags

The basic idea is that you'd be converting back and forth between two
parallel kinds of markup:

  <abiword version=... template="DocBook.atw">
  <section>
  ...
  <p style="BlockQuote"><c style="CiteTitle">Moby Dick</c> sucks.</p>
  ...
  </section>
  </abiword>

versus the DocBook equivalent:

  <Book>
  ...
  <BlockQuote><CiteTitle>Moby Dick</CiteTitle> sucks.</BlockQuote>
  ...
  </Book>

(Yes, it does get more complex than this. Some DocBook constructs should
probably map to AbiWord fields, and you might also need named section-level
styles. I'm just trying to suggest the general idea.)

Note that AbiWord is *not* a full-generality XML editor, and sufficiently
complex tag nesting could not be handled by such a solution. Also, since
the style system doesn't provide a lot of integrity constraints (just
paragraph vs. section, and followedby), any DTD-like validation would
probably get done either externally or at export time.

However, it's a *great* way to get WYSIWYG or WYSIWYM support for fairly
little work.

>Anyone want to take a crack at it?

Volunteers anyone? The existing styles code is quite simple, but if you
need help figuring out how to extend it for these purposes, let me know.

Paul



This archive was generated by hypermail 2b25 : Fri Apr 07 2000 - 12:42:54 CDT