Log Message:
-----------
Normalized a bunch of stuff to deal with error messages coming
from SGML processors with stricter handling of omitted tags...

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        bookindex.sgml (r1.5 -> r1.6)
        defineset.sgml (r1.13 -> r1.14)
        intro.sgml (r1.12 -> r1.13)
        plainpaths.sgml (r1.6 -> r1.7)

-------------- next part --------------
Index: defineset.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/defineset.sgml,v
retrieving revision 1.13
retrieving revision 1.14
diff -Ldoc/adminguide/defineset.sgml -Ldoc/adminguide/defineset.sgml -u -w -r1.13 -r1.14
--- doc/adminguide/defineset.sgml
+++ doc/adminguide/defineset.sgml
@@ -52,8 +52,7 @@
 <listitem><para> If the table hasn't even got a candidate primary key,
 you can ask &slony1; to provide one.  This is done by first using
 <xref linkend="stmttableaddkey"> to add a column populated using a
-&slony1; sequence, and then having the <xref
-linkend="stmtsetaddtable"> include the directive
+&slony1; sequence, and then having the <xref linkend="stmtsetaddtable"> include the directive
 <option>key=serial</option>, to indicate that &slony1;'s own column
 should be used.</para></listitem>
 
Index: intro.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/intro.sgml,v
retrieving revision 1.12
retrieving revision 1.13
diff -Ldoc/adminguide/intro.sgml -Ldoc/adminguide/intro.sgml -u -w -r1.12 -r1.13
--- doc/adminguide/intro.sgml
+++ doc/adminguide/intro.sgml
@@ -144,6 +144,7 @@
 <para>There are a number of distinct models for database replication;
 it is impossible for one replication system to be all things to all
 people.</para></sect2>
+</sect1>
 
 <sect1 id="slonylistenercosts"><title>
 <productname>Slony-I</productname> Communications Costs</title>
@@ -154,8 +155,8 @@
 
 <itemizedlist>
 
-<listitem><para> It is necessary to have <xref linkend=
-"table.sl-listen"> entries allowing connection from each node to every
+<listitem><para> It is necessary to have <xref
+       linkend="table.sl-listen"> entries allowing connection from each node to every
 other node.  Most will normally not need to be very heavily, but it
 still means that there needs to be n(n-1) paths.  </para></listitem>
 
Index: plainpaths.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/plainpaths.sgml,v
retrieving revision 1.6
retrieving revision 1.7
diff -Ldoc/adminguide/plainpaths.sgml -Ldoc/adminguide/plainpaths.sgml -u -w -r1.6 -r1.7
--- doc/adminguide/plainpaths.sgml
+++ doc/adminguide/plainpaths.sgml
@@ -7,32 +7,34 @@
 <itemizedlist>
 
 <listitem><para> <xref linkend="admconninfo"> - controlling how a
-<xref linkend="slonik"> script accesses the various nodes.
+<xref linkend="slonik"> script accesses the various nodes.</para>
 
 <para> These connections are the ones that go from your
-<quote/administrative workstation/ to all of the nodes in a &slony1;
-cluster.
+<quote>administrative workstation</quote> to all of the nodes in a &slony1;
+cluster.</para>
 
-<para> It is <emphasis>vital</emphasis> that you have connections from
-the central location where you run <xref linkend="slonik"> to each and
-every node in the network.  These connections are only used briefly,
-to submit the few <acronym>SQL</acronym> requests required to control
-the administration of the cluster.
+<para> It is <emphasis>vital</emphasis> that you have connections from the
+central location where you run <xref linkend="slonik"> 
+to each and every node in the network.  These connections are only
+used briefly, to submit the few <acronym>SQL</acronym> requests required to
+control the administration of the cluster.</para>
 
 <para> Since these communications paths are only used briefly, it may
 be quite reasonable to <quote>hack together</quote> temporary
-connections using <link linkend="tunnelling">SSH tunnelling</link>.
+connections using <link linkend="tunnelling">SSH
+tunnelling</link>.</para></listitem>
 
 <listitem><para> <xref linkend="stmtstorepath"> - controlling how
 <xref linkend="slon"> daemons communicate with remote nodes.  These
-paths are stored in <xref linkend="table.sl-path">.
+paths are stored in <xref linkend="table.sl-path">.</para>
 
 <para> You forcibly <emphasis>need</emphasis> to have a path between
 each subscriber node and its provider; other paths are optional, and
 will not be used unless a listen path in <xref
-linkend="table.sl-listen">. is needed that uses that particular path.
+linkend="table.sl-listen">. is needed that uses that particular
+path.</para></listitem>
 
-</itemizedlist>
+</itemizedlist></para>
 
 <para> The distinctions and possible complexities of paths are not
 normally an issue for people with simple networks where all the hosts
@@ -53,24 +55,24 @@
 
 <listitem><para> DB1 and DB2 are databases residing in a secure
 <quote>database layer,</quote> firewalled against outside access
-except from specifically controlled locations.
+except from specifically controlled locations.</para>
 
 <para> Let's suppose that DB1 is the origin node for the replication
-system.
+system.</para></listitem>
 
 <listitem><para> DB3 resides in a <quote>DMZ</quote> at the same site;
 it is intended to be used as a &slony1; <quote>provider</quote> for
-remote locations.
+remote locations.</para></listitem>
 <listitem><para> DB4 is a counterpart to DB3 in a <quote>DMZ</quote>
 at a secondary/failover site.  Its job, in the present configuration,
 is to <quote>feed</quote> servers in the secure database layers at the
-secondary site.
+secondary site.</para></listitem>
 <listitem><para> DB5 and and DB6 are counterparts to DB1 and DB2, but
-are, at present, configured as subscribers.
+are, at present, configured as subscribers.</para>
 
 <para> Supposing disaster were to strike at the <quote>primary</quote>
 site, the secondary site would be well-equipped to take over servicing
-the applications that use this data.
+the applications that use this data.</para>
 
 <para> Managers paying bills are likely to be reluctant to let the
 machines at the secondary site merely be <quote>backups;</quote> they
@@ -78,7 +80,7 @@
 be the case.  If the primary site is being used for
 <quote>transactional activities,</quote> the replicas at the secondary
 site may be used for running time-oriented reports that are allowed to
-be a little bit behind.
+be a little bit behind.</para></listitem>
 
 <listitem><para> The symmetry of the configuration means that if you
 had <emphasis>two</emphasis> transactional applications needing
@@ -86,13 +88,14 @@
 additional replication sets so that each site is normally
 <quote>primary</quote> for one application, and where destruction of
 one site could be addressed by consolidating services at the remaining
-site.
+site.</para></listitem>
 
 </itemizedlist>
 
-<para> 
+<para></para> 
 
-<para> There is also room for discussion of SSH tunnelling here...</para>
+<para> There is also room for discussion of SSH tunnelling
+here...</para>
 
 </sect1>
 <!-- Keep this comment at the end of the file