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/
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