summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAlan Coopersmith <alan.coopersmith@oracle.com>2010-12-16 23:10:06 -0800
committerAlan Coopersmith <alan.coopersmith@oracle.com>2010-12-16 23:10:06 -0800
commit3011b8527ba7370e7e29758ecba0231e7e25bda8 (patch)
tree2a0083c2611a79939a6302abbbe7960f4fad736d
parent2c1cabffad2903867fd352c19f0157d07adde232 (diff)
specs/record.xml: Fix section titles/nesting
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-rw-r--r--specs/record.xml65
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>