{RFC] XSLT for draft watermarking?

[Paul W. Frields]

On Wed, 2005-11-30 at 07:51 -0500, James Laska wrote:
> On Tue, 2005-11-29 at 20:04 -0500, Paul W. Frields wrote:
> > 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?  When the
> > work is approved, the author or editor can add this attribute to the top
> > of their doc, and the next build fixes the make.  If you want to dream
> > really big like Karsten, then think of that status attribute being
> > manipulated by a XML/XSLT capable shell script that is part of a Larger
> > Automated Process.  For example, when the doc is published, it gets
> > branched and the branch gets the status="published" tag, whereas HEAD
> > keeps the default draft.
> > 
> > Is this possible?
> 
> That's a good idea.  Another thought might be to pass in any details by
> way of environment variables when the doc is made.  I do this for some
> "production-style" xsl ...
> 
>   $ XSLHTML=some.xsl make
> 
> Perhaps something like ...
> 
>   $ CSS=../common/css/production.css make
> 
> ... just thinking outloud.  This approach would allow for local CSS
> customization and follows a similar path provided by overloading
> XSLHTML, XSLHTMLNOCHUNK, XSLPDF, FDPDIR.

That's a good point too -- Tommy has already made allowances for this in
his Makefile.common, so this is do-able as well.  I suppose we could do
this based on tagging in CVS as well.  There's probably several other
ways we haven't thought of either.  I like any way that doesn't make us
have to change a big chunk of the current Makefile.common, or put too
many additional "don't forget to..." burdens on the
authors/editors/publishers.  One way or another somebody's got to mark
*something*, it's just a matter of what's the most flexible way to do
it.

If I remember correctly, there's an order to how XSL stuff is inherited,
right?  Like, "whoever's first wins," although it could be the opposite,
I'm not sure.  That would give a pretty easy solution to using your
XSLHTML= method above, I'm thinking, since you could just write the new
XSL to include the original stuff and process the "production"
instructions in the right order.  Am I on the right track with this?
Sorry I don't know the formal terms correctly at this point -- if I did
it would make my comments more readable, I'm sure.  ;-)

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20051130/3169fe62/attachment.sig>