On Wed, 2005-11-30 at 11:41 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" <stickster@xxxxxxxxx>, spake thus: > > > Both <book> and <article> in DocBook support a CDATA attribute called > > "status". (I.e., <book status="published"> or something like that.) > > Does this mean we could have XSLT do the work of deciding which > > stylesheet to use, without having to have a new "make" target? > > Maybe I know this, but I can't remember it at the moment. I need a > little more thinking on this. My question is: > > When is an FDP document "published"? +1 to all your observations, you are totally on track. Our objective is to: * Make it an easy, automated process for a document to move to the state of being published. * Restrict who can do that task, so that it is truly formal. As Paul alluded to, I'm certain we are going to be doing automation on top of this. Imagine a workbench that writers and editors use, essentially a customized and streamlined CMS built on our systems. On the front side it allows writers to add draft content, work with it in their editor of choice on- or off-line, then push that content to the editors. The editors can approve or deny, and may or may not be allowed to edit. This can then be pushed to publish, or, if flagged for it, pushed to a publisher, who does the final approval. What is happening on the back side is dependent on what we choose here. This was the basis for my agreeing with Paul's idea in concept. Something that can be done to a module to make it publish, checked in and tagged or branched, and have that publication approval stick to just that tag or branch. Then revert back to a draft status. The alternative to this is to capture the publish/draft information in a database and work up some metadata about it. That's what traditional CMS does. But we have CVS doing all that for us, why mess with it? > Official, production-quality documents are located (where?) and > produced by (whom?). Only those copies need have the draft > watermarking revoked. For now, we need to do it manually. Sorry. We just need to document the process (on the Wiki) and adhere to it. > Docs included in the distribution are "production". Where else do > the official docs reside? Who places them there? How do they know > when to do this? Part of our process, and eventually tool, is to put the proper CSS in the packaged documentation. Do my concepts answer your conceptual questions? I see this workbench landing in chunks, pieces by quarter ... three months, six months, etc. > I don't think the document itself should know whether it is released > or not. It is too easy to leave the blessing in the document as > modifications are in progress. An external mechanism makes sense to > me. Is CVS okay for this? That is, the tag or branch has meaning or a specific string (PUB). Wherever you build, check the tag on the file in order to use the for-publish stylesheets. This would disable off-line builds of for-publish documents, as CVS would be required. That makes the toolchain enforce behavior > We really need only one CSS stylesheet in the docs CVS: the > fedora-draft.css file, and we have that. > > Any official-looking document renderings should come from whom ever > is constructing the official-looking release, but anything in our CVS > is strictly for draft documents. I don't know about moving this to another repository ... how about a 'publish' module with ACLs? > Does this mean that document authors can't generate official document > renderings? Yes, if by that you mean "Fedora Documentation Project" > official copies. Anyone wanting to produce their own published > renderings are free to take the "fedora-draft.css" stylesheet and > edit as desired. Agreed, make it easy for people to comply with the trademark guidelines ... by making it harder for them to use the trademarked material incorrectly. :) > I would agree to change the XSLT and Makefile.common stuff to > reference "fedora.css" and to make "fedora.css" a symlink to the > "fedora-draft.css" file. That would make switching the CSS > stylesheet easier because a change would not corrupt the local CVS > image. +1 > Comments? Suggestions? Donations? Two out of three ain't bad for today. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
