specs/record.xml: Fix section titles/nesting

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

1 files changed, 31 insertions, 34 deletions

diff --git a/specs/record.xml b/specs/record.xml
index f5d48ac..4256c15 100644
--- a/specs/record.xml
+++ b/specs/record.xml
@@ -72,9 +72,7 @@ from the X Consortium.
 </legalnotice>
 </bookinfo>
 
-<chapter>
-<title>TITLE</title>
-<sect1 id="Introduction">
+<chapter id="Introduction">
 <title>Introduction</title>
 <para>
 Several proposals have been written over the past few years that address some
@@ -168,7 +166,7 @@ changes, drawing of certain text strings, etc.) can capture the
 information it needs using RECORD facilities.
 </para>
 
-<sect2 id="Acknowledgements">
+<sect1 id="Acknowledgements">
 <title>Acknowledgements</title>
 <para>
 The document represents the culmination of two years of debate and
@@ -189,9 +187,9 @@ clarification of the recorded event policy, and Kent Siefkes of
 Performance Awareness has assisted in clarification of the timestamp
 policy.
 </para>
-</sect2>
+</sect1>
 
-<sect2 id="Goals">
+<sect1 id="Goals">
 <title>Goals</title>
 <itemizedlist>
   <listitem>
@@ -216,9 +214,9 @@ To provide the ability to record arbitrary X protocol extensions.
     </para>
   </listitem>
 </itemizedlist>
-</sect2>
+</sect1>
 
-<sect2 id="Requirements">
+<sect1 id="Requirements">
 <title>Requirements</title>
 <para>
 The extension should function as follows:
@@ -256,17 +254,17 @@ support the recording of synchronization information for user events.
     </para>
   </listitem>
 </itemizedlist>
-</sect2>
 </sect1>
+</chapter>
 
-<sect1 id="Design">
+<chapter id="Design">
 <title>Design</title>
 <para>
 This section gives an overview of the RECORD extension and discusses
 its overall operation and data types.
 </para>
 
-<sect2 id="Overview">
+<sect1 id="Overview">
 <title>Overview</title>
 <para>
 The mechanism used by this extension for recording is to intercept
@@ -287,7 +285,7 @@ In addition, the
 extension does not provide data compression before intercepted protocol
 is returned to the recording clients.
 </para>
-<sect3 id="Data_Delivery">
+<sect2 id="Data_Delivery">
 <title>Data Delivery</title>
 <!-- .XS -->
 <!-- (SN Data Delivery -->
@@ -314,8 +312,8 @@ might be collected
 into a single reply.
 Nevertheless, all data are returned to the client in a timely manner.
 </para>
-</sect3>
-<sect3 id="Record_Context">
+</sect2>
+<sect2 id="Record_Context">
 <title>Record Context</title>
 <!-- .XS -->
 <!-- (SN Record Context -->
@@ -342,9 +340,9 @@ it is required to do so immediately.  That is, it is not permissible for
 the server to wait until recording is enabled to register clients
 or recording is disabled to unregister clients.
 </para>
-</sect3>
+</sect2>
 
-<sect3 id="Record_Client_Connections">
+<sect2 id="Record_Client_Connections">
 <title>Record Client Connections</title>
 <!-- .XS -->
 <!-- (SN Record Client Connections -->
@@ -374,8 +372,8 @@ to the "enable" request is sent by the server.  Therefore, unless a
 recording client never has the need to disable the interception and reporting
 of protocol data, two client connections are necessary.
 </para>
-</sect3>
-<sect3 id="Events">
+</sect2>
+<sect2 id="Events">
 <title>Events</title>
 <!-- .XS -->
 <!-- (SN Events -->
@@ -429,9 +427,9 @@ and
 <function>KeyRelease</function>
 device events are reported.
 </para>
-</sect3>
+</sect2>
 
-<sect3 id="Timing">
+<sect2 id="Timing">
 <title>Timing</title>
 <!-- .XS -->
 <!-- (SN Timing -->
@@ -441,10 +439,10 @@ Requests are recorded just before
 they are executed; the time associated with a request is the server
 time when it is recorded.
 </para>
-</sect3>
 </sect2>
+</sect1>
 
-<sect2 id="Types">
+<sect1 id="Types">
 <title>Types</title>
 <para>
 The following new types are used in the request definitions that appear
@@ -869,9 +867,9 @@ resource base that identifies the intercepted client.  The
 <emphasis remap='I'>intercepted-protocol</emphasis> field specifies the protocol to intercept
 for the <emphasis remap='I'>client-resource</emphasis>.
 </para>
-</sect2>
+</sect1>
 
-<sect2 id="Errors">
+<sect1 id="Errors">
 <title>Errors</title>
 <para>
 <emphasis role="bold">RecordContext</emphasis>
@@ -887,10 +885,10 @@ in a request does not name a defined record context.
     </para>
   </listitem>
 </itemizedlist>
-</sect2>
 </sect1>
+</chapter>
 
-<sect1 id="Protocol_Requests">
+<chapter id="Protocol_Requests">
 <title>Protocol Requests</title>
 <!-- .XS -->
 <!-- (SN Protocol Requests -->
@@ -1678,9 +1676,9 @@ is closed down and the close-down mode is <function>DestroyAll</function>.  When
 <function>RecordContext</function>
 error results.
 </para>
-</sect1>
+</chapter>
 
-<sect1 id="Encoding">
+<chapter id="Encoding">
 <title>Encoding</title>
 <para>
 Please refer to the X11 Protocol Encoding document as this document uses
@@ -1691,7 +1689,7 @@ conventions established there.
 The name of this extension is "RECORD".
 </para>
 
-<sect2 id="Types_2">
+<sect1 id="Types_2">
 <title>Types</title>
 <para>
 RC: CARD32
@@ -1756,8 +1754,8 @@ CLIENT_INFO
      24n  LISTofRECORDRANGE   intercepted-protocol
 </literallayout>
 
-</sect2>
-<sect2 id="Errors_2">
+</sect1>
+<sect1 id="Errors_2">
 <title>Errors</title>
 
 <literallayout class="monospaced">
@@ -1768,9 +1766,9 @@ CLIENT_INFO
      4     CARD32             invalid record context
      24                       unused
 </literallayout>
-</sect2>
+</sect1>
 
-<sect2 id="Requests">
+<sect1 id="Requests">
 <title>Requests</title>
 
 <literallayout class="monospaced">
@@ -1889,7 +1887,6 @@ CLIENT_INFO
      4     RC                    context
 </literallayout>
 
-</sect2>
 </sect1>
 </chapter>
 </book>