documentation/manual tool (Re: [DotGNU]Newbies questions, Tex, gnome, topposting)

[Jonathan P Springer]

On Sat, Feb 02, 2002 at 10:56:11PM +0530, Gopal.V wrote:
> If memory serves me right, Tomislav Sajdl wrote:
> > Some XML based tool (even) with some totally inflexible UI may help a 
> > lot. Have in mind that our documents should not be much more than set of 
> > paragraphs, with a mark what that paragraph means (ie. heading, 
> > introduction, plain text, bulleting list, example, "see also") [and we 
> > need hyperlinks]. Word processing tool give you much more freedom, but 
> > they have to be most general as they can be.
>       What about using some good old GPL stuff. Abiword is an excellent
> WYSWIG option. It has a default XML format inside, with support for
> Latex and Docbook. It's *very* userfriendly and almost an M$ W0rd cl0ne.
> Also I can even code for Abiword using Emacs/Vim if I hack the XML tags.
> It's just like HTML in a new bottle. XML which is presentation oriented.
> This totally destroys the META-DATA that XML is meant to convey. So
> in the docs, we have data but cannot convert it into logical tree. But
> I guess we can live with it right now. Also we lack hyperlink support 
> there .... :-(

I did some nosing around, and it looks like the biggest appetite right
now is for Docbook XML.  The notes from the 2nd Annual Documentation
Summit in San Diego <http://ibiblio.org/guylhem/documents/PR> were quite
revealing -- most folks like DocBook, but bemoan the lack of tools for
dealing with it :-).

In a fit of optomism, I started writing up my results in AbiWord and 
tried "Save As Docbook" to see what would happen.  I was less then 
impressed with the results.  I shan't go into detail here; I'll go 
post comments to the AbiWord developers.

Right now I envision some sort of Web-based document system built on top
of phpGroupware.  Content can be added directly from the page (a la
WikiPedia) or by importing well-structured documents.  For example, one
could upload a "Section" Docbook to fill in a section of a "Book".  The
underlying document is stored in the logical form of Docbook (or another
XML).  The key is that if one creates a document component, one can pick
one's own tool (thus avoiding yet another editor flame war).  This is a
document collaboration/management system, not an XML/TexInfo editor.

Separately, to get from XML to TexInfo requires a decent amount of work.  
Docbook2texi breaks on Docbook XML (as opposed to SGML), and I'd prefer 
translation to be entirely XSL based anyway, to allow authors to configure 
alternate XMLs or XSLs for their underlying documents. Any input?

I'm also toying with the idea of distributed documents, which goes
something like this:

   1.  The complete document is a logical entity, but need not exist
   physically until it must to support a complete parse (i.e. an XSL
   parse).

   2.  Each tag and its contents are represented internally by some sort
   of URI.  Namespace and such concerns TBD, but the "host" of the tag
   would be implicit in the URI.

   3.  When necessary the document can be constructed by traversing the
   URI's and recursively retrieving the actual content.  (I'm toying
   with whether some sort of Usenet-like "distribution" mechanism should
   be used in this case).

To be sure, there are some practical concerns with this approach.  I
doubt it will be ready in v1.0.  For one thing, I'd like to see
phpGroupware support some sort of "single-signon" or "trusting"
mechanism across instances.  I'll post it on their suggestion board once
I've got this idea drilled down a bit more.

That's all for now.  I'm about halfway through compiling my notes into a
scoping document of sorts.  Once that happens I'll run the project
through the DotGNU proposal process and, if it flies, set up space on Savannah
and a spin-off mailing list.

Thanks to all for their continuing input.

Regards,
-jonathan