What is the purpose of a Docs CMS?

Wed Jan 28 01:04:11 UTC 2009

On Tue, Jan 27, 2009 at 09:08:05PM +0000, Jared Smith wrote:

> 1. How do we ensure that any editing that gets done in the CMS gets
> pushed back to the authoritative DocBook?  Should we make a rule that
> *no* editing be done in the CMS, and that the CMS is merely for viewing
> the final output of the process you described above?

That is a good rule.

Think of the CMS as like the package repository.

If we do carry a patch on a package, there is a bugzilla report open
that explains why, and it doesn't close until the patch is upstream.

So, we'd want a similar policy.  We might use the CMS to edit a
published document to get a fix up right away, but we'd want it tied
to a bug report that didn't close until the changes was ported to the
proper SCM instance.

> 2. How do we expect the CMS to handle multi-page HTML output from the
> toolchain above?  Typically, the XSL transforms our DocBook source into
> either single-page HTML, multi-page HTML, or PDF documents.  The one
> that concerns me the most is multi-page HTML.  Most CMS systems don't
> take to kindly to importing a whole set of HTML pages, especially ones
> that are all linked together and already have <head> elements, their own
> stylesheets, etc.  This point still makes me wonder if what we need is
> really a CMS, or just some kind of HTML-set management utility.

That's a good question.  My expectation is that a CMS _could_ and
_should_ handle this case.  (I just saw a Zikula module handle this.)

Maybe instead it imports the no-chunks (all-one-page) variety and then
chunks it itself inside of the CMS.

Or we autobuild from SCM to /srv/web/docs, then make container pages
in the CMS that link to the built per-lang PDF, HTML, etc. files.

OTOH, as you say, we may be looking for a different solution for this
publishing problem.  I just don't want us coding it ourselves, that
would be 'Plan F for FAIL.'

- Karsten
-- 
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20090127/55dea901/attachment.sig>