Re: {RFC] XSLT for draft watermarking?

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

 



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

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Red Hat 9]     [Yosemite News]     [KDE Users]

  Powered by Linux