Received: from habanero.hesketh.net (habanero.hesketh.net [66.45.6.196])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id fAM4NRm84703
	for <pgsql-docs@postgresql.org>; Wed, 21 Nov 2001 23:23:28 -0500 (EST)
	(envelope-from brent@mutt.rcfile.org)
Received: from mutt.rcfile.org (rdu57-26-120.nc.rr.com [66.57.26.120])
	by habanero.hesketh.net (8.11.6/8.11.1) with ESMTP id fAM4NQU22129;
	Wed, 21 Nov 2001 23:23:26 -0500
X-Received-From: brent@mutt.rcfile.org
X-Delivered-To: pgsql-docs@postgresql.org
X-Spam-Filter: check_local@habanero.hesketh.net by digitalanswers.org
X-More-Information: http://spamfighter.hesketh.net
Received: (from brent@localhost)
	by mutt.rcfile.org (8.11.6/8.11.5) id fAM4NeP29113;
	Wed, 21 Nov 2001 23:23:40 -0500 (EST) (envelope-from brent)
Date: Wed, 21 Nov 2001 23:23:39 -0500
From: Brent Verner <brent@rcfile.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-docs@postgresql.org
Subject: Re: sgml cleanup
Message-ID: <20011121232339.A28949@rcfile.org>
References: <20011121224721.A28646@rcfile.org>
 <28119.1006402312@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <28119.1006402312@sss.pgh.pa.us>
User-Agent: Mutt/1.3.23i
X-Archive-Number: 200111/67
X-Sequence-Number: 1140

On 21 Nov 2001 at 23:11 (-0500), Tom Lane wrote:
| Brent Verner <brent@rcfile.org> writes:
| >   In trying to get the doc/ tree in cvs to build, I noticed a _lot_ of 
| > empty closing tags when I ran
| 
| ?? I'm not seeing any of these problems.  Are you using the recommended
| docs toolchain?

I have no clue about the recommended docs toolchain.  I must not be,
since my docbook2man-spec.pl does not (seem to) accept command line
arguments.  I've built postgresql.tar, but man.tar is still giving
me fits. The built html files can be seen at
  http://rcfile.org/posthack/pgdocs/

What I am seeing from a fresh update (at 11:19 EST) is this.

sleepy:~/pgsql/doc/src
brent$ grep '</>' sgml/*  |wc -l
grep: sgml/CVS: Is a directory
grep: sgml/ref: Is a directory
   1639
sleepy:~/pgsql/doc/src
brent$ grep -Hn '</>' sgml/xoper.sgml 
sgml/xoper.sgml:116:     operators <literal>&lt;</> and <literal>&gt;</> for a particular data type are usually each others'
sgml/xoper.sgml:117:     commutators, and operator <literal>+</> is usually commutative with itself.
sgml/xoper.sgml:118:     But operator <literal>-</> is usually not commutative with anything.
sgml/xoper.sgml:179:     For example, <literal>&lt;</> and <literal>&gt;=</> are a negator pair for most data types.
sgml/xoper.sgml:242:    make sense if you think about it.  <literal>=</> will typically accept only
sgml/xoper.sgml:243:    a small fraction of the rows in a table; <literal>&lt;&gt;</> will typically reject
sgml/xoper.sgml:244:    only a small fraction.  <literal>&lt;</> will accept a fraction that depends on
sgml/xoper.sgml:248:    <literal>&lt;=</> will accept a slightly larger fraction than <literal>&lt;</> for the same
sgml/xoper.sgml:251:    rough guess anyhow.  Similar remarks apply to <literal>&gt;</> and <literal>&gt;=</>.
sgml/xoper.sgml:359:     joins.  On machines that meet the <acronym>IEEE</> floating point standard, minus
sgml/xoper.sgml:389:     that can only succeed for pairs of values that fall at the <quote>same place</>
sgml/xoper.sgml:413:     In practice you should only write SORT clauses for an <literal>=</> operator,
sgml/xoper.sgml:414:     and the two referenced operators should always be named <literal>&lt;</>.  Trying
sgml/xoper.sgml:436:  There must be <literal>&lt;</> and <literal>&gt;</> ordering operators having the same left and
sgml/xoper.sgml:438:  operators <emphasis>must</emphasis> be named <literal>&lt;</> and <literal>&gt;</>; you do


confused,
  brent

-- 
"Develop your talent, man, and leave the world something. Records are 
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing."  -- Duane Allman