What is the purpose of a Docs CMS?
Karsten Wade
kwade at redhat.com
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://lists.fedoraproject.org/pipermail/docs/attachments/20090127/55dea901/attachment.bin
More information about the docs
mailing list