From 6d1181b15e217039c5dd42efa2b46aff4989004d Mon Sep 17 00:00:00 2001 From: Michael Smith Date: Sat, 2 Sep 2006 04:54:17 +0000 Subject: [PATCH] To make DocBook4-valid (the build ends up validing output of this using xjparse), replaced author/orgname with corpauthor and replaced all instances of tag with sgmltag. --- xsl/common/refentry.xsl | 78 ++++++++++++++++++++--------------------- 1 file changed, 39 insertions(+), 39 deletions(-) diff --git a/xsl/common/refentry.xsl b/xsl/common/refentry.xsl index d998fcb12..8a082767e 100644 --- a/xsl/common/refentry.xsl +++ b/xsl/common/refentry.xsl @@ -22,7 +22,7 @@ $Id$ - The DocBook Project + The DocBook Project 2005 The DocBook Project @@ -58,27 +58,27 @@ etc., is sometimes viewed in isolation from its greater "context". For example, users view Unix man pages as, well, individual pages, not as part of a "book" of some kind. Therefore, it is sometimes necessary to - embed "context" information in output for each refentry. + embed "context" information in output for each refentry. However, one problem is that different users mark up that context information in different ways. Often (usually), the context information is not actually part of the content of the - refentry itself, but instead part of the content of a - parent or ancestor element to the the refentry. And + refentry itself, but instead part of the content of a + parent or ancestor element to the the refentry. And even then, DocBook provides a variety of elements that users might potentially use to mark up the same kind of information. One user - might use the productnumber element to mark up version + might use the productnumber element to mark up version information about a particular product, while another might use - the releaseinfo element. + the releaseinfo element. Taking all that in mind, the get.refentry.metadata function tries to gather - metadata from a refentry element and its ancestor + metadata from a refentry element and its ancestor elements in an intelligent and user-configurable way. The basic mechanism used in the XPath expressions throughout this stylesheet is to select the relevant metadata from the *info element that is - closest to the actual refentry â€“ either on the - refentry itself, or on its nearest ancestor. + closest to the actual refentry â€“ either on the + refentry itself, or on its nearest ancestor. The get.refentry.metadata function is @@ -94,13 +94,13 @@ refname - The first refname in the refentry + The first refname in the refentry info - A set of info nodes (from a refentry + A set of info nodes (from a refentry element and its ancestors) @@ -201,10 +201,10 @@ The man(7) man page describes this as "the title of the man page (e.g., MAN). This differs - from refname in that, if the refentry has a - refentrytitle, we use that as the title; - otherwise, we just use first refname in the first - refnamediv in the source. + from refname in that, if the refentry has a + refentrytitle, we use that as the title; + otherwise, we just use first refname in the first + refnamediv in the source. @@ -212,14 +212,14 @@ refname - The first refname in the refentry + The first refname in the refentry - Returns a title node. + Returns a title node. @@ -244,8 +244,8 @@ The man(7) man page describes this as "the section number the man page should be placed in (e.g., - 7)". If we do not find a manvolnum - specified in the source, and we find that the refentry is + 7)". If we do not find a manvolnum + specified in the source, and we find that the refentry is for a function, we use the section number 3 ["Library calls (functions within program libraries)"]; otherwise, we default to using 1 ["Executable programs or shell @@ -257,7 +257,7 @@ refname - The first refname in the refentry + The first refname in the refentry @@ -330,13 +330,13 @@ refname - The first refname in the refentry + The first refname in the refentry info - A set of info nodes (from a refentry + A set of info nodes (from a refentry element and its ancestors) @@ -349,7 +349,7 @@ - Returns a date node. + Returns a date node. @@ -496,13 +496,13 @@ refname - The first refname in the refentry + The first refname in the refentry info - A set of info nodes (from a refentry + A set of info nodes (from a refentry element and its ancestors) @@ -516,7 +516,7 @@ - Returns a source node. + Returns a source node. @@ -613,13 +613,13 @@ refname - The first refname in the refentry + The first refname in the refentry info - A set of info nodes (from a refentry + A set of info nodes (from a refentry element and its ancestors) @@ -782,13 +782,13 @@ refname - The first refname in the refentry + The first refname in the refentry info - A set of info nodes (from a refentry + A set of info nodes (from a refentry element and its ancestors) @@ -953,13 +953,13 @@ refname - The first refname in the refentry + The first refname in the refentry info - A set of info nodes (from a refentry + A set of info nodes (from a refentry element and its ancestors) @@ -973,7 +973,7 @@ - Returns a manual node. + Returns a manual node. @@ -1101,16 +1101,16 @@ The DocBook XSL stylesheets include several user-configurable - global stylesheet parameters for controlling refentry + global stylesheet parameters for controlling refentry metadata gathering. Those parameters are not read directly by the - other refentry metadata-gathering functions. Instead, they + other refentry metadata-gathering functions. Instead, they are read only by the get.refentry.metadata.prefs function, which assembles them into a structure that is then passed to - the other refentry metadata-gathering functions. + the other refentry metadata-gathering functions. So the, get.refentry.metadata.prefs function is the only interface to collecting stylesheet parameters for - controlling refentry metadata gathering. + controlling refentry metadata gathering. @@ -1118,7 +1118,7 @@ does rely on a number of global parameters. - Returns a manual node. + Returns a manual node. @@ -1186,7 +1186,7 @@ refname - The first refname in the refentry + The first refname in the refentry -- 2.50.1