[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: what next?

I'll try to reply here with all my thoughts to this part of the thread,
rather than repeating myself into this thread-branch.  HTH.

On Tue, 2006-11-07 at 18:46 +0000, Dimitris Glezos wrote:
> So, as I see it we need a balance between a solid solution like 
> "everything in Docbook" or a usable solution like "everything in the 
> wiki or in a kbase". With the first approach 
> *publication/maintainability* is easier and more simple but with the 
> second the actual *writing* is. Second has advantages like better 
> monitoring/live results, but with the cost of less functionality and a 
> cost overhead for producing the final form.
> With the MoinDocbook we try to do a little of both but it seems that the 
> transition from wiki to Docbook is not as easy nor as solid as it sounds 
> (correct me if I'm wrong here). The problem could be that we are trying 
> to maintain the content in two forms instead of one with just two 
> front-ends (the web one and the cvs-checkout/emacs one).

It's a combination of technical and procedural.  For something like the
release notes, I think the Wiki -> DB works great, ideally.  We still
have some bugs to work out, but they are minor in comparison.

> I'll throw another idea on the table (probably a bit bold too), since 
> now it's the best time to do it.
> Maybe a live web front-end to the actual Docbook code in CVS/SVN would 
> be a better solution? Let's say, we can see live the Docbook results and 
> edit individual paragraphs, with each edit resulting in CVS commits? If 
> we hook this up with the accounts system, everybody will be able to chip 
> in like with the Beats system, and the result would be maintainable with 
> the power of Docobok/CVS (no need to convert). 

Not too bold at all, and has been discussed on this list before you came
around.  The idea is solid and we defined some ideas of how to do this
with the upcoming code in Moin Moin.  The basic idea is to have Wiki
constructs for easy block code (<para>, <itemizedlist>, etc.) and then
find some way to expose actual XML within the Wiki itself.  (This is
what 'DocBook Wiki' does that you reference below.)

Personally, I think we need to pursue this with Moin and the plans Mikko
and I made over the summer:


Read through this entire road map to understand a little more:


> I searched a bit and 
> found a project that does exactly that:
>   http://doc-book.sourceforge.net
> I don't know if it's worth it (the customizing etc.), but it could be a 
> candidate to substitute the wiki <-> docbook conversion. It is written 
> in PHP, it uses xmltproc and friends, it seems to support multiple 
> languages, content approving, intermediate docbook-focused syntax (or 
> docbook). Last update was 1.5 year ago.

We took a serious look at this internally at Red Hat and ran into
several show-stoppers.  The content is stored in the SCM (CVS or SVN) in
a very unique way that is hard to map to DocBook needs.  In fact, iirc,
we could not use XIncludes properly because of the directory structure.
There were other technical limitations that don't come to mind; Jeff
Fearn might be able to enlighten us further here, if he wants to

There are also concerns about maintainability.  This DocBook Wiki would
setup an entirely new piece of infrastructure that no one is familiar
with, and FI is not interested in supporting.  It is also a bit out of
date, and while I don't think Dashamir has abandoned the project, it
does not seem to be his main focus.  So, we would likely need to have
someone become an active upstream supported to have success.

With Moin, we have all that already -- it is understood, supported, and
we are working with the very active upstream to get our changes in and
supported, probably maintained by someone from Fedora.

I will balance this with saying that actually looking at the UI for
DocBook Wiki makes it look like a great idea; it is rather elegant the
way he made it work, which is where I got the idea to embed XML within
the Wiki markup.

- Karsten
Karsten Wade, RHCE, 108 Editor    ^     Fedora Documentation Project 
 Sr. Developer Relations Mgr.     |  fedoraproject.org/wiki/DocsProject
   quaid.108.redhat.com           |          gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]