Hardening Doc Preview

tuxxer tuxxer at cox.net
Sun Sep 5 23:56:30 UTC 2004


On Sun, 2004-09-05 at 10:33, Dave Pawson wrote:
> On Sat, 2004-09-04 at 23:36, Charlie wrote:
> 
> > Now if the document could be included (as an entity???), so that work
> > isn't duplicated, but your document actually contains the same
> > instructions, that might have value.
> 
> Nice idea.
> 
> Exploring it a bit further...
> 
> You said you wanted draft mode..
>   A customising stylesheet might look like
> 
> <xsl:param name="draft.mode" select="'maybe'"></xsl:param>
> <?xml version="1.0" encoding="utf-8"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>                 version="1.0">
>   <xsl:import href="
> /sgml/nw/docbook/docbook-xsl-1.65.1/html/docbook.xsl"/>
> 
> <xsl:param name="draft.mode" select="'yes'"></xsl:param>
> 
> 
> 
> <!-- Process the yum material, by inclusion -->
> <xsl:template match="processing-instruction('charlie')">
> <xsl:copy-of
> select="document('http://fedora-docsURL/yumFDC/xxx.xml')//sect1[@id='start']"/>
> 
> </xsl:template>
> 
> </xsl:stylesheet>
> 
> Lets say in your source document you had a pi
> <?charlie yum ?>
> 
> then add to the stylesheet as shown,
> 
> That (untested) should pull in the yum stuff, xml version, starting at
> a specific sect1 tag.
> 
> 
> Next question, are the xml files available without a cvs pull?
> I dont' think they are.
> 
> The basics are there though.
> 
> Equally, an entity in the XML would do it, but not in such a selective
> way.
> 
> 
> 

It would also depend on how the author of the particular document that
you were referencing authored the doc.  I tend to think in a more
modular way, so writing different files for different chapters (or
sections), just makes more sense to me.  To digress for an example, I
know that PHP and JSP both support "includes" which can be retrieved
from another file.  If the document were written in a more modular
format, the referenced document could be "included" in another doc.  I
would suspect that XML would have this same functionality.

There could also be an argument for a "detailed" doc, and a "summary"
doc.  The summary doc would be a smaller doc, which would go over the
steps of a particular process, but not in the same detail (obviously) as
the "detailed" doc.

Also, something to consider, if I can cover updating your system with
up2date or yum, in 2 sections (one for GUI and one for command line),
does it really require a doc of it's own?  Now I could see writing one
[for yum], explaining all of the different functionalities of the tool,
but not just for the simple purpose of updating your system.

Just my $.02.

-- 
--

tuxxer <tuxxer(a)cox(dot)net>

     <== tuxxer's gpg key fingerprint ==>
57EB F948 76AE 25BC E340  EFA9 FAF6 E1AC F1E1 1EA1
-------------- 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/20040905/37826b27/attachment.sig>


More information about the fedora-docs-list mailing list