Fix bad link anchors.

Fix broken links in kxproto. The old links hardcoded the output
filename 'XKBproto.htm' and used anchors that didn't convert correctly.
The new anchors are strings that use the same convention as
other anchors in other docs.

Fix links like:
<ulink url="XKBproto.htm#50332257_45660">Compute State Field</ulink>
to be:
<link linkend='computing_a_state_field_from_an_xkb_state'>Compute State Field</link>

Signed-off-by: Matt Dew <marcoz@osource.org>
Reviewed-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>

16 files changed, 200 insertions, 235 deletions

diff --git a/specs/appA.xml b/specs/appA.xml
index fa85a67..6bb0dbe 100644
--- a/specs/appA.xml
+++ b/specs/appA.xml
@@ -175,7 +175,7 @@ capitalization behavior. Any keysyms not explicitly listed in these tables are
 not capitalized by XKB when locale-insensitive capitalization is in effect and
 are not automatically assigned the <emphasis>
 ALPHABETIC</emphasis>
- type as described in <ulink url="protocol.htm#35661"></ulink>.
+ type as described in the <link linkend="the_alphabetic_key_type">Alphabetic Key Type</link>.
 </para>
 
 
diff --git a/specs/ch02.xml b/specs/ch02.xml
index 27a566a..e3558d1 100644
--- a/specs/ch02.xml
+++ b/specs/ch02.xml
@@ -273,8 +273,8 @@ ServerInternalModifiers</emphasis>
 IgnoreLocksModifiers</emphasis>
  and <emphasis>
 IgnoreGroupLock</emphasis>
- controls, described in <ulink url="XKBproto.htm#50332257_45660">See Server
-Internal Modifiers and Ignore Locks Behavior</ulink>, to derive these two
+ controls, described in <link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server
+Internal Modifiers and Ignore Locks Behavior</link>, to derive these two
 states as follows:
 </para>
 
@@ -355,16 +355,15 @@ The core protocol interpretation of
 keyboard modifiers does not include direct support for multiple groups, so XKB
 reports the effective keyboard group to XKB-aware clients using some of the
 reserved bits in the state field of some core protocol events, as described in
-<ulink url="XKBproto.htm#50332257_90933">See Computing A State Field from an
-XKB State</ulink>.
+<link linkend='computing_a_state_field_from_an_xkb_state'>See Computing A State Field from an
+XKB State</link>.
 </para>
 
 <para>
 This modified state field would not be interpreted correctly by XKB-unaware
 clients, so XKB provides a <emphasis>
 group compatibility mapping</emphasis>
-(see <ulink
-url="XKBproto.htm#50332257_40656">See Group Compatibility Map</ulink>) which
+(see <link linkend='group_compatibility_map'>See Group Compatibility Map</link>) which
 remaps the keyboard group into a core modifier mask that has similar effects,
 when possible. XKB maintains three compatibility state components that are used
 to make non-XKB clients work as well as possible:
@@ -399,8 +398,7 @@ of the grab state.
 
 <para>
 Compatibility states are essentially the corresponding XKB state, but with
-keyboard group possibly encoded as one or more modifiers; <ulink
-url="XKBproto.htm#50332257_40656">See Group Compatibility Map</ulink> describes
+keyboard group possibly encoded as one or more modifiers; <link linkend='group_compatibility_map'>See Group Compatibility Map</link> describes
 the group compatibility map, which specifies the modifier(s) that correspond to
 each keyboard group.
 </para>
diff --git a/specs/ch03.xml b/specs/ch03.xml
index 1181172..66b3353 100644
--- a/specs/ch03.xml
+++ b/specs/ch03.xml
@@ -212,8 +212,8 @@ NumLock</emphasis>
 
 <para>
 The virtual modifier mapping is normally updated automatically whenever actions
-are assigned to keys (see <ulink url="XKBproto.htm#50332257_84091">See Changing
-the Keyboard Mapping Using the Core Protocol</ulink> for details) and few
+are assigned to keys (see <link linkend='changing_the_keyboard_mapping_using_the_core_protocol'>See Changing
+the Keyboard Mapping Using the Core Protocol</link> for details) and few
 applications should need to change the virtual modifier mapping explicitly.
 </para>
 </sect1>
diff --git a/specs/ch04.xml b/specs/ch04.xml
index 33b77b3..631d1b0 100644
--- a/specs/ch04.xml
+++ b/specs/ch04.xml
@@ -99,8 +99,8 @@ whether or not it is supported.
 
 
 <para>
-<ulink url="XKBproto.htm#50332257_24503">See Querying and Changing Per-Client
-Flags</ulink> describes the <emphasis>
+<link linkend='querying_and_changing_per_client_flags'>See Querying and Changing Per-Client
+Flags</link> describes the <emphasis>
 XkbPerClientFlags</emphasis>
  request, which reports or changes values for all of the per-client flags, and
 which lists the per-client flags that are supported.
@@ -148,8 +148,7 @@ rejection or release of any key to interested clients using <emphasis>
 AccessXNotify</emphasis>
  events. The <emphasis>
 AccessXNotify</emphasis>
- event is described in more detail in <ulink
-url="XKBproto.htm#50332257_22322">See Events</ulink>.
+ event is described in more detail in <link linkend='events'>See Events</link>.
 </para>
 
 </sect1>
@@ -184,8 +183,7 @@ interested clients by sending an <emphasis>
 AccessXNotify</emphasis>
  event. The <emphasis>
 AccessXNotify</emphasis>
- event is described in more detail in <ulink
-url="XKBproto.htm#50332257_22322">See Events</ulink>.
+ event is described in more detail in <link linkend='events'>See Events</link>.
 </para>
 
 </sect1>
@@ -377,8 +375,8 @@ When <emphasis>
 MouseKeys</emphasis>
  are active and a <emphasis>
 SA_MovePtr</emphasis>
- key action (see <ulink url="XKBproto.htm#50332257_15763">See Key
-Actions</ulink>) is activated, a pointer motion event is generated immediately.
+ key action (see <link linkend='key_actions'>See Key
+Actions</link>) is activated, a pointer motion event is generated immediately.
 If <emphasis>
 MouseKeysAccel</emphasis>
  is enabled and if acceleration is enabled for the key in question, a second
@@ -517,11 +515,11 @@ StickyKeys</emphasis>
 
 <para>
 Some of these key sequences optionally generate audible feedback of the change
-in state, as described in <ulink url="XKBproto.htm#50332257_21748">See The
-AccessXFeedback Control</ulink>, or cause <emphasis>
+in state, as described in <link linkend='the_accessxfeedback_control'>See The
+AccessXFeedback Control</link>, or cause <emphasis>
 XkbAccessXNotify</emphasis>
- events as described in <ulink url="XKBproto.htm#50332257_22322">See
-Events</ulink>.
+ events as described in <link linkend='events'>See
+Events</link>.
 </para>
 
 
@@ -781,8 +779,8 @@ should generate when that overlay is enabled, assign it either the <emphasis>
 KB_Overlay1</emphasis>
  or <emphasis>
 KB_Overlay2</emphasis>
- key behaviors, as described in <ulink url="XKBproto.htm#50332257_81140">See
-Key Behavior</ulink>.
+ key behaviors, as described in <link linkend='key_behavior'>See
+Key Behavior</link>.
 </para>
 
 
@@ -793,11 +791,11 @@ Key Behavior</ulink>.
 <para>
 All of the controls described above, along with the <emphasis>
 AudibleBell</emphasis>
- control (described in <ulink url="XKBproto.htm#50332257_18543">See Disabling
-Server Generated Bells</ulink>) and the <emphasis>
+ control (described in <link linkend='disabling_server_generated_bells'>See Disabling
+Server Generated Bells</link>) and the <emphasis>
 IgnoreGroupLock</emphasis>
- control (described in <ulink url="XKBproto.htm#50332257_45660">See Server
-Internal Modifiers and Ignore Locks Behavior</ulink>) comprise the <emphasis>
+ control (described in <link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server
+Internal Modifiers and Ignore Locks Behavior</link>) comprise the <emphasis>
 boolean controls</emphasis>
 . In addition to any parameters listed in the descriptions of the individual
 controls, the boolean controls can be individually enabled or disabled by
@@ -815,18 +813,18 @@ EnabledControls</emphasis>
  control or specified in any context that accepts only boolean controls:
 <emphasis>
 GroupsWrap</emphasis>
- (<ulink url="XKBproto.htm#50332257_67222">See Computing Effective Modifier and
-Group</ulink>), <emphasis>
+ (<link linkend='computing_effective_modifier_and_group'>See Computing Effective Modifier and
+Group</link>), <emphasis>
 EnabledControls</emphasis>
 , <emphasis>
 InternalMods</emphasis>
- (<ulink url="XKBproto.htm#50332257_45660">See Server Internal Modifiers and
-Ignore Locks Behavior</ulink>), and <emphasis>
+ (<link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server Internal Modifiers and
+Ignore Locks Behavior</link>), and <emphasis>
 IgnoreLockMods</emphasis>
- (<ulink url="XKBproto.htm#50332257_45660">See Server Internal Modifiers and
-Ignore Locks Behavior</ulink>) and <emphasis>
+ (<link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server Internal Modifiers and
+Ignore Locks Behavior</link>) and <emphasis>
 PerKeyRepeat</emphasis>
- (<ulink url="XKBproto.htm#50332257_48937">See The RepeatKeys Control</ulink>)
+ (<link linkend='the_repeatkeys_control'>See The RepeatKeys Control</link>)
 </para>
 
 
@@ -838,8 +836,8 @@ PerKeyRepeat</emphasis>
 The <emphasis>
 auto-reset controls</emphasis>
  are a per-client value which consist of two masks that can contain any of the
-boolean controls (see <ulink url="XKBproto.htm#50332257_12486">See "Boolean"
-Controls and The EnabledControls Control</ulink>). Whenever the client exits
+boolean controls (see <link linkend='boolean_controls_and_the_enabledcontrols_control'>See "Boolean"
+Controls and The EnabledControls Control</link>). Whenever the client exits
 for any reason, any boolean controls specified in the <emphasis>
 auto-reset mask</emphasis>
  are set to the corresponding value from the <emphasis>
@@ -853,8 +851,8 @@ automatically, even if abnormally terminated.
 For example, a client that replace the keyboard bell with some other audible
 cue might want to turn off the <emphasis>
 AudibleBell</emphasis>
- control (<ulink url="XKBproto.htm#50332257_18543">See Disabling Server
-Generated Bells</ulink>) to prevent the server from also generating a sound and
+ control (<link linkend='disabling_server_generated_bells'>See Disabling Server
+Generated Bells</link>) to prevent the server from also generating a sound and
 thus avoid cacophony. If the client were to exit without resetting the
 <emphasis>
 AudibleBell </emphasis>
diff --git a/specs/ch05.xml b/specs/ch05.xml
index d00a26d..e712d56 100644
--- a/specs/ch05.xml
+++ b/specs/ch05.xml
@@ -19,8 +19,7 @@ elapsed while the <emphasis>
 RepeatKeys</emphasis>
  control can cause multiple X events from a single physical key press if the
 key is held down for an extended period. The global keyboard controls affect
-all of the keys on the keyboard and are described in <ulink
-url="XKBproto.htm#50332257_28742">See Global Keyboard Controls</ulink>.
+all of the keys on the keyboard and are described in <link linkend='global_keyboard_controls'>See Global Keyboard Controls</link>.
   </para>
 </listitem>
 <listitem>
@@ -30,8 +29,7 @@ keyboard overlays, in which a key generates an alternate keycode under certain
 circumstances, can be implemented using per-key behavior. Every key has a
 single behavior, so the effect of key behavior does not depend on keyboard
 modifier or group state, though it might depend on global keyboard controls.
-Per-key behaviors are described in detail in <ulink
-url="XKBproto.htm#50332257_81140">See Key Behavior</ulink>.
+Per-key behaviors are described in detail in <link linkend='key_behavior'>See Key Behavior</link>.
   </para>
 </listitem>
 <listitem>
@@ -39,8 +37,7 @@ url="XKBproto.htm#50332257_81140">See Key Behavior</ulink>.
 keyboard has some action associated with it. The key action tells the server
 what to do when an event which yields the corresponding keysym is generated.
 Key actions might change or suppress the event, generate some other event, or
-change some aspect of the server. Key actions are described in <ulink
-url="XKBproto.htm#50332257_15763">See Key Actions</ulink>.
+change some aspect of the server. Key actions are described in <link linkend='key_actions'>See Key Actions</link>.
   </para>
 </listitem>
 </orderedlist>
@@ -53,16 +50,14 @@ event, the client which receives the event processes it in several steps.
 <orderedlist>
 <listitem>
   <para>First the client extracts the effective keyboard group and a set of
-modifiers from the state field of the event. See <ulink
-url="XKBproto.htm#50332257_90933">See Computing A State Field from an XKB
-State</ulink> for details.
+modifiers from the state field of the event. See <link linkend='computing_a_state_field_from_an_xkb_state'>See Computing A State Field from an XKB
+State</link> for details.
   </para>
 </listitem>
 <listitem>
   <para>Using the modifiers and effective keyboard group, the client selects a
-symbol from the list of keysyms bound to the key. <ulink
-url="XKBproto.htm#50332257_24122">See Determining the KeySym Associated with a
-Key Event</ulink> discusses symbol selection.
+symbol from the list of keysyms bound to the key. <link linkend='determining_the_keysym_associated_with_a_key_event'>See Determining the KeySym Associated with a
+Key Event</link> discusses symbol selection.
   </para>
 </listitem>
 <listitem>
@@ -71,9 +66,8 @@ using any modifiers that are "left over" from the process of looking up a
 symbol. For example, if the <emphasis>
 Lock</emphasis>
  modifier is left over, the resulting keysym is capitalized according to the
-capitalization rules specified by the system. See <ulink
-url="XKBproto.htm#50332257_25094">See Transforming the KeySym Associated with a
-Key Event</ulink> for a more detailed discussion of the transformations defined
+capitalization rules specified by the system. See <link linkend='transforming_the_keysym_associated_with_a_key_event'>See Transforming the KeySym Associated with a
+Key Event</link> for a more detailed discussion of the transformations defined
 by XKB.
   </para>
 </listitem>
diff --git a/specs/ch06.xml b/specs/ch06.xml
index cab2624..6476750 100644
--- a/specs/ch06.xml
+++ b/specs/ch06.xml
@@ -261,9 +261,9 @@ Each key has an optional list of actions. If present, this list parallels the
 list of symbols associated with the key (i.e. it has one action per symbol
 associated with the key). For key press events, the server looks up the action
 to be applied from this list using the key symbol mapping associated with the
-event key, just as a client looks up symbols as described in <ulink
-url="XKBproto.htm#50332257_24122">See Determining the KeySym Associated with a
-Key Event</ulink>; if the event key does not have any actions, the server uses
+event key, just as a client looks up symbols as described in <link
+linkend="determining_the_keysym_associated_with_a_key_event">See Determining the KeySym Associated with a
+Key Event</link>; if the event key does not have any actions, the server uses
 the <emphasis>
 SA_NoAction</emphasis>
  event for that key regardless of modifier or group state.
@@ -292,7 +292,7 @@ delay between the activation of one and the other.
 
 <para>
 Most actions which affect keyboard modifier state accept a modifier definition
-(see <ulink url="XKBproto.htm#50332257_51617">See Virtual Modifiers</ulink>)
+(see <link linkend="virtual_modifiers">See Virtual Modifiers</link>)
 named <emphasis>
 mods</emphasis>
  and a boolean flag name <emphasis>
@@ -679,8 +679,8 @@ MouseKeysAccel</emphasis>
  keyboard control is enabled, key press also initiates the mouse keys timer for
 this key; every time this timer expires, the cursor moves again. The distance
 the cursor moves in these subsequent events is determined by the mouse keys
-acceleration as described in <ulink url="XKBproto.htm#50332257_29074">See The
-MouseKeysAccel Control</ulink>.
+acceleration as described in <link linkend="the_mousekeysaccel_control">See The
+MouseKeysAccel Control</link>.
   </para>
 </listitem>
 <listitem>
@@ -1627,8 +1627,8 @@ event that caused them.
 Events sent to clients that have not issued an <emphasis>
 XkbUseExtension</emphasis>
  request contain a compatibility state in place of the actual XKB keyboard
-state. See <ulink url="XKBproto.htm#50332257_39705">See Effects of XKB on Core
-Protocol Events</ulink> for a description of this compatibility mapping.
+state. See <link linkend="effects_of_xkb_on_core_protocol_events">See Effects of XKB on Core
+Protocol Events</link> for a description of this compatibility mapping.
 </para>
 
 
@@ -1646,9 +1646,9 @@ the following changes:
 <itemizedlist>
 <listitem>
   <para>A passive grab triggers if the modifier state specified in the grab
-matches the grab compatibility state (described in <ulink
-url="XKBproto.htm#50332257_32581">See Compatibility Components of Keyboard
-State</ulink>). Clients can choose to use the XKB grab state instead by setting
+matches the grab compatibility state (described in <link
+linkend="compatibility_components_of_keyboard_state">See Compatibility Components of Keyboard
+State</link>). Clients can choose to use the XKB grab state instead by setting
 the <emphasis>
 GrabsUseXKBState</emphasis>
  per-client flag. This flag affects all passive grabs that are requested by the
@@ -1678,15 +1678,15 @@ LookupStateWhenGrabbed</emphasis>
 <listitem>
   <para>Otherwise, the state field of events that do not trigger a passive grab
 report is derived from the XKB effective modifiers and group, as described in
-<ulink url="XKBproto.htm#50332257_90933">See Computing A State Field from an
-XKB State</ulink>.
+<link linkend="computing_a_state_field_from_an_xkb_state">See Computing A State Field from an
+XKB State</link>.
   </para>
 </listitem>
 <listitem>
   <para>If a key release event is the result of an autorepeating key that is
 being held down, and the client to which the event is reported has requested
-detectable autorepeat (see <ulink url="XKBproto.htm#50332257_79074">See
-Detectable Autorepeat</ulink>), the event is not delivered to the client.
+detectable autorepeat (see <link linkend="detectable_autorepeat">See
+Detectable Autorepeat</link>), the event is not delivered to the client.
   </para>
 </listitem>
 </itemizedlist>
@@ -1719,9 +1719,9 @@ interact.
 <itemizedlist>
 <listitem>
   <para>The largest problems arise from the fact that an XKB state field
-encodes an explicit keyboard group in bits 13-14 (as described in <ulink
-url="XKBproto.htm#50332257_90933">See Computing A State Field from an XKB
-State</ulink>), while pre-XKB clients use one of the eight keyboard modifiers
+encodes an explicit keyboard group in bits 13-14 (as described in <link
+linkend="computing_a_state_field_from_an_xkb_state">See Computing A State Field from an XKB
+State</link>), while pre-XKB clients use one of the eight keyboard modifiers
 to select an alternate keyboard group. To make existing clients behave
 reasonably, XKB normally uses the compatibility grab state instead of the XKB
 grab state to determine whether or not a passive grab is triggered. XKB-aware
diff --git a/specs/ch07.xml b/specs/ch07.xml
index 15b5399..500357f 100644
--- a/specs/ch07.xml
+++ b/specs/ch07.xml
@@ -7,7 +7,7 @@ client map</emphasis>
  for a keyboard is the collection of information a client needs to interpret
 key events that come from that keyboard. It contains a global list of <emphasis>
 key types</emphasis>
-, described in <ulink url="XKBproto.htm#50332257_45629">See Key Types</ulink>,
+, described in <link linkend='key_types'>See Key Types</link>,
 and an array of <emphasis>
 key symbol map</emphasis>
 s, each of which describes the symbols bound to one particular key and the
@@ -19,8 +19,8 @@ rules to be used to interpret those symbols.
 
 <para>
 XKB associates a two-dimensional array of symbols with each key. Symbols are
-addressed by keyboard group (see <ulink url="XKBproto.htm#50332257_13933">See
-Keyboard State</ulink>) and shift level, where level is defined as in the
+addressed by keyboard group (see <link linkend='keyboard_state'>See
+Keyboard State</link>) and shift level, where level is defined as in the
 ISO9995 standard:
 </para>
 
@@ -86,14 +86,14 @@ group and shift level that correspond to the event.
 
 <para>
 Group is reported in bits 13-14 of the state field of the key event, as
-described in <ulink url="XKBproto.htm#50332257_90933">See Computing A State
-Field from an XKB State</ulink>. The keyboard group reported in the event might
+described in <link linkend='computing_a_state_field_from_an_xkb_state'>See Computing A State
+Field from an XKB State</link>. The keyboard group reported in the event might
 be out-of-range for any particular key because the number of groups can vary
 from key to key. The XKB description of each key contains a <emphasis>
 group info</emphasis>
  field which is interpreted identically to the global groups wrap control (see
-<ulink url="XKBproto.htm#50332257_67222">See Computing Effective Modifier and
-Group</ulink>) and which specifies the interpretation of groups that are
+<link linkend='computing_effective_modifier_and_group'>See Computing Effective Modifier and
+Group</link>) and which specifies the interpretation of groups that are
 out-of-range for that key.
 </para>
 
@@ -104,7 +104,7 @@ determine the shift level. The description of a key includes a <emphasis>
 key type</emphasis>
  for each group of symbols bound to the key. Given the modifiers from the key
 event, this key type yields a shift level and a set of "leftover" modifiers, as
-described in <ulink url="XKBproto.htm#50332257_45629">See Key Types</ulink>
+described in <link linkend='key_types'>See Key Types</link>
 below.
 </para>
 
@@ -125,8 +125,8 @@ map</emphasis>
  field specifies the shift level that corresponds to some XKB modifier
 definition; any combination of modifiers that is not explicitly listed
 somewhere in the map yields shift level one. Map entries which specify unbound
-virtual modifiers (see <ulink url="XKBproto.htm#50332257_29579">See Inactive
-Modifier Definitions</ulink>) are not considered; each entry contains an
+virtual modifiers (see <link linkend='inactive_modifier_definitions'>See Inactive
+Modifier Definitions</link>) are not considered; each entry contains an
 automatically-updated <emphasis>
 active</emphasis>
  field which indicates whether or not it should be used.
@@ -161,8 +161,8 @@ Any modifiers specified in <emphasis>
 modifiers</emphasis>
  are normally <emphasis>
 consumed</emphasis>
- (see <ulink url="XKBproto.htm#50332257_25094">See Transforming the KeySym
-Associated with a Key Event</ulink>), which means that they are not considered
+ (see <link linkend='transforming_the_keysym_associated_with_a_key_event'>See Transforming the KeySym
+Associated with a Key Event</link>), which means that they are not considered
 during any of the later stages of event processing. For those rare occasions
 that a modifier <emphasis>
 should</emphasis>
@@ -396,8 +396,8 @@ according to the locale-sensitive capitalization rules specified by the system.
 If the <emphasis>
 Control</emphasis>
  modifier is set, the keysym is not affected, but the corresponding character
-should be converted to a control character as described in <ulink
-url="dflttrns.htm#17949"></ulink>.
+should be converted to a control character as described in <link
+linkend="default_symbol_transformations">Default Symbol Transformations</link>.
 </para>
 
 
@@ -427,7 +427,7 @@ Control</emphasis>
     <entry>Report the control character associated with the symbol. This
 extension defines the control characters associated with the ASCII alphabetic
 characters (both upper and lower case) and for a small set of punctuation
-characters (see <ulink url="dflttrns.htm#17949"></ulink>). Applications are
+characters (see <link linkend="default_symbol_transformations">Default Symbol Transformations</link>). Applications are
 free to associate control characters with any symbols that are not specified by
 this extension.</entry>
   </row>
@@ -437,7 +437,7 @@ Lock</emphasis>
     </entry>
     <entry>Capitalize the symbol either according to capitalization rules
 appropriate to the application locale or using the capitalization rules defined
-by this extension (see <ulink url="dflttrns.htm#17949"></ulink>).</entry>
+by this extension (see <link linkend="default_symbol_transformations">Default Symbol Transformations</link>).</entry>
   </row>
 </tbody>
 </tgroup>
@@ -449,11 +449,11 @@ Interpretation of other modifiers is application dependent.
 
 <note><para>This definition of capitalization is fundamentally different from
 the core protocol’s, which uses the lock modifier to select from the symbols
-bound to the key. Consider key 9 in the example keyboard on <ulink
-url="XKBproto.htm#50332257_ClientMapExample">See Consider a simple, if
+bound to the key. Consider key 9 in the example keyboard on <link
+linkend="client_map_example">See Consider a simple, if
 unlikely, keyboard with the following keys (gray characters indicate symbols
 that are implied or expected but are not actually engraved on the
-key):</ulink>; the core protocol provides no way to generate the capital form
+key):</link>; the core protocol provides no way to generate the capital form
 of either symbol bound to this key. XKB specifies that we first look up the
 symbol and then capitalize, so XKB yields the capital form of the two symbols
 when caps lock is active. </para></note>
@@ -677,8 +677,8 @@ to be used. The key type determines which symbol is chosen from the list.
 
 
 <para>
-<ulink url="XKBproto.htm#50332257_24122">See Determining the KeySym Associated
-with a Key Event</ulink> details the procedure to map from a key event to a
+<link linkend='determining_the_keysym_associated_with_a_key_event'>See Determining the KeySym Associated
+with a Key Event</link> details the procedure to map from a key event to a
 symbol and/or a string.
 </para>
 </sect1>
diff --git a/specs/ch08.xml b/specs/ch08.xml
index feaa995..2dd04a9 100644
--- a/specs/ch08.xml
+++ b/specs/ch08.xml
@@ -86,9 +86,8 @@ symbols</emphasis>
 geometry</emphasis>
  names typically correspond to the keyboard components from which the current
 keyboard description was assembled. These components are stored individually in
-the server’s database of keyboard components, described in <ulink
-url="XKBproto.htm#50332257_46669">See The Server Database of Keyboard
-Components</ulink>, and can be combined to assemble a complete keyboard
+the server’s database of keyboard components, described in <link linkend='the_server_database_of_keyboard_components'>See The Server Database of Keyboard
+Components</link>, and can be combined to assemble a complete keyboard
 description.
 </para>
 
@@ -131,8 +130,8 @@ customizations are straightforward.
 
 <para>
 Key aliases can be specified both in the symbolic names component and in the
-keyboard geometry (see <ulink url="XKBproto.htm#50332257_23341">See Keyboard
-Geometry</ulink>). Both sets of aliases are always valid, but key alias
+keyboard geometry (see <link linkend='keyboard_geometry'>See Keyboard
+Geometry</link>). Both sets of aliases are always valid, but key alias
 definitions in the keyboard geometry have priority; if both symbolic names and
 geometry include aliases, applications should consider the definitions from the
 geometry before considering the definitions from the symbolic names section.
diff --git a/specs/ch09.xml b/specs/ch09.xml
index b5cae3f..c78eba9 100644
--- a/specs/ch09.xml
+++ b/specs/ch09.xml
@@ -60,8 +60,8 @@ keyboard, it cannot be directly changed under program control. It is possible,
 however, for the set of physical indicators to be change if a new keyboard is
 attached or if a completely new keyboard description is loaded by the <emphasis>
 XkbGetKeyboardByName</emphasis>
- request (see <ulink url="XKBproto.htm#50332257_13490">See Using the Server’s
-Database of Keyboard Components</ulink>).
+ request (see <link linkend='using_the_servers_database_of_keyboard_components'>See Using the Server’s
+Database of Keyboard Components</link>).
 </para>
 
 
@@ -88,9 +88,8 @@ XkbGetNames</emphasis>
  request reports the symbolic names for all keyboard components, including the
 indicators. Use the <emphasis>
 XkbSetNames</emphasis>
- request to change symbolic names. Both requests are described in <ulink
-url="XKBproto.htm#50332257_14207">See Querying and Changing Symbolic
-Names</ulink>.
+ request to change symbolic names. Both requests are described in <link linkend='querying_and_changing_symbolic_names'>See Querying and Changing Symbolic
+Names</link>.
 </para>
 
 
@@ -233,8 +232,7 @@ mods</emphasis>
  fields of an indicator map determine how the state of the keyboard modifiers
 affect the corresponding indicator. The <emphasis>
 mods</emphasis>
- field is an XKB modifier definition, as described in <ulink
-url="XKBproto.htm#50332257_11005">See Modifier Definitions</ulink>, which can
+ field is an XKB modifier definition, as described in <link linkend='modifier_definitions'>See Modifier Definitions</link>, which can
 specify both real and virtual modifiers. The mods field takes effect even if
 some or all of the virtual indicators specified in <emphasis>
 mods</emphasis>
@@ -307,9 +305,8 @@ IM_UseCompat</emphasis>
 <para>
 The <emphasis>
 controls</emphasis>
- field specifies a subset of the boolean keyboard controls (see <ulink
-url="XKBproto.htm#50332257_12486">See "Boolean" Controls and The
-EnabledControls Control</ulink>). The indicator is lit whenever any of the
+ field specifies a subset of the boolean keyboard controls (see <link linkend='boolean_controls_and_the_enabledcontrols_control'>See "Boolean" Controls and The
+EnabledControls Control</link>). The indicator is lit whenever any of the
 boolean controls specified in <emphasis>
 controls</emphasis>
  are enabled.
diff --git a/specs/ch10.xml b/specs/ch10.xml
index 66b5cab..c20622b 100644
--- a/specs/ch10.xml
+++ b/specs/ch10.xml
@@ -110,8 +110,8 @@ sounds other than simple tones, but it is not required to do so.
 <para>
 Aside from those used by the XKB <emphasis>
 AccessXFeedback</emphasis>
- control (see <ulink url="XKBproto.htm#50332257_21748">See The AccessXFeedback
-Control</ulink>), this extension does not specify bell names or their
+ control (see <link linkend='the_accessxfeedback_control'>See The AccessXFeedback
+Control</link>), this extension does not specify bell names or their
 interpretation.
 </para>
 
diff --git a/specs/ch11.xml b/specs/ch11.xml
index 3164b6c..1be90dd 100644
--- a/specs/ch11.xml
+++ b/specs/ch11.xml
@@ -79,8 +79,8 @@ structures refer to geometry properties.
 <listitem>
   <para>A list of <emphasis>
 key aliases</emphasis>
-, as described in <ulink url="XKBproto.htm#50332257_15645">See Symbolic
-Names</ulink>.
+, as described in <link linkend='symbolic_names'>See Symbolic
+Names</link>.
   </para>
 </listitem>
 <listitem>
@@ -89,8 +89,7 @@ shapes</emphasis>
 ; other keyboard components refer to shapes by their index in this list. A
 shape consists of a name and one or more closed-polygons called <emphasis>
 outlines</emphasis>
-. Shapes and outlines are described in detail in <ulink
-url="XKBproto.htm#50332257_35210">See Shapes and Outlines</ulink>.
+. Shapes and outlines are described in detail in <link linkend='shapes_and_outlines'>See Shapes and Outlines</link>.
   </para>
 </listitem>
 </itemizedlist>
diff --git a/specs/ch12.xml b/specs/ch12.xml
index ff399a1..cd21a48 100644
--- a/specs/ch12.xml
+++ b/specs/ch12.xml
@@ -53,8 +53,8 @@ of a keyboard mapping and XKB and explains the ways they can interact.
 <title>Group Compatibility Map</title>
 
 <para>
-As described in <ulink url="XKBproto.htm#50332257_13933">See Keyboard
-State</ulink>, the current keyboard group is reported to XKB-aware clients in
+As described in <link linkend='keyboard_state'>See Keyboard
+State</link>, the current keyboard group is reported to XKB-aware clients in
 bits 13-14 of the state field of many core protocol events. XKB-unaware clients
 cannot interpret those bits, but they might use a keyboard modifier to
 implement support for a single keyboard group. To ensure that pre-XKB clients
@@ -243,42 +243,41 @@ field for a key can contain any combination of the following values:
     <entry>ExplicitKeyType1</entry>
     <entry>Automatic determination of the key type associated with <emphasis>
 Group1</emphasis>
- (see <ulink url="XKBproto.htm#50332257_35661">See Assigning Types To Groups of
-Symbols for a Key</ulink>)</entry>
+ (see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See Assigning Types To Groups of
+Symbols for a Key</link>)</entry>
   </row>
   <row rowsep='0'>
     <entry>ExplicitKeyType2</entry>
     <entry>Automatic determination of the key type associated with <emphasis>
 Group2 </emphasis>
-(see <ulink url="XKBproto.htm#50332257_35661">See Assigning Types To Groups of
-Symbols for a Key</ulink>)</entry>
+(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See Assigning Types To Groups of
+Symbols for a Key</link>)</entry>
   </row>
   <row rowsep='0'>
     <entry>ExplicitKeyType3</entry>
     <entry>Automatic determination of the key type associated with <emphasis>
 Group3 </emphasis>
-(see <ulink url="XKBproto.htm#50332257_35661">See Assigning Types To Groups of
-Symbols for a Key</ulink>).</entry>
+(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See Assigning Types To Groups of
+Symbols for a Key</link>).</entry>
   </row>
   <row rowsep='0'>
     <entry>ExplicitKeyType4</entry>
     <entry>Automatic determination of the key type associated with <emphasis>
 Group4 </emphasis>
-(see <ulink url="XKBproto.htm#50332257_35661">See Assigning Types To Groups of
-Symbols for a Key</ulink>).</entry>
+(see <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See Assigning Types To Groups of
+Symbols for a Key</link>).</entry>
   </row>
   <row rowsep='0'>
     <entry>ExplicitInterpret</entry>
     <entry>Application of any of the fields of a symbol interpretation to the
-key in question (see <ulink url="XKBproto.htm#50332257_66444">See Assigning
-Actions To Keys</ulink>).</entry>
+key in question (see <link linkend='assigning_actions_to_keys'>See Assigning
+Actions To Keys</link>).</entry>
   </row>
   <row rowsep='0'>
     <entry>ExplicitAutoRepeat</entry>
     <entry>Automatic determination of autorepeat status for the key, as
-specified in a symbol interpretation (see <ulink
-url="XKBproto.htm#50332257_66444">See Assigning Actions To
-Keys</ulink>).</entry>
+specified in a symbol interpretation (see <link linkend='assigning_actions_to_keys'>See Assigning Actions To
+Keys</link>).</entry>
   </row>
   <row rowsep='0'>
     <entry>ExplicitBehavior</entry>
@@ -286,16 +285,15 @@ Keys</ulink>).</entry>
 KB_Lock</emphasis>
  behavior to the key, if the <emphasis>
 LockingKey</emphasis>
- flag is set in a symbol interpretation (see <ulink
-url="XKBproto.htm#50332257_66444">See Assigning Actions To
-Keys</ulink>).</entry>
+ flag is set in a symbol interpretation (see <link linkend='assigning_actions_to_keys'>See Assigning Actions To
+Keys</link>).</entry>
   </row>
   <row rowsep='0'>
     <entry>ExplicitVModMap</entry>
     <entry>Automatic determination of the virtual modifier map for the key
 based on the actions assigned to the key and the symbol interpretations which
-match the key (see <ulink url="XKBproto.htm#50332257_66444">See Assigning
-Actions To Keys</ulink>).</entry>
+match the key (see <link linkend='assigning_actions_to_keys'>See Assigning
+Actions To Keys</link>).</entry>
   </row>
 </tbody>
 </tgroup>
@@ -312,8 +310,7 @@ ChangeKeyboardMapping</emphasis>
 groups that are defined for the key and the width of each group. The XKB
 extension does not change key types in response to core protocol <emphasis>
 SetModifierMapping</emphasis>
- requests, but it does choose key actions as described in <ulink
-url="XKBproto.htm#50332257_66444">See Assigning Actions To Keys</ulink>.
+ requests, but it does choose key actions as described in <link linkend='assigning_actions_to_keys'>See Assigning Actions To Keys</link>.
 </para>
 
 
@@ -490,8 +487,7 @@ ALPHABETIC</emphasis>
     <entry>Describes alphabetic keys that have exactly two symbols per group.
 The default definition of the <emphasis>
 ALPHABETIC</emphasis>
- type provides shift-cancels-caps behavior as described in <ulink
-url="XKBproto.htm#50332257_45629">See Key Types</ulink>. Index <emphasis>
+ type provides shift-cancels-caps behavior as described in <link linkend='key_types'>See Key Types</link>. Index <emphasis>
 2</emphasis>
  in any key symbol map specifies key type <emphasis>
 ALPHABETIC</emphasis>
@@ -541,7 +537,7 @@ lowercase and uppercase forms are defined, the X server treats the key as if
 the first element of the group were the lowercase form of the symbol and the
 second element were the uppercase form of the symbol. For the purposes of this
 expansion, XKB ignores the locale and uses the capitalization rules defined in
-<ulink url="dflttrns.htm#17949"></ulink>.
+<link linkend="default_symbol_transformations">Default Symbol Transformations</link>.
 </para>
 
 
@@ -737,7 +733,7 @@ locking key</emphasis>
  field is set in the symbol interpretation, the behavior of the key is changed
 to <emphasis>
 KB_Lock</emphasis>
- (see <ulink url="XKBproto.htm#50332257_81140">See Key Behavior</ulink>). The
+ (see <link linkend='key_behavior'>See Key Behavior</link>). The
 <emphasis>
 ExplicitBehavior</emphasis>
  component prevents this change.
@@ -791,8 +787,8 @@ indicator maps, internal modifiers or ignore locks modifiers.
 After applying server actions which modify the base, latched or locked modifier
 or group state of the keyboard, the X server recomputes the effective group and
 state. Several components of the keyboard state are reported to XKB-aware
-clients depending on context (see <ulink url="XKBproto.htm#50332257_13933">See
-Keyboard State</ulink> for a detailed description of each of the keyboard state
+clients depending on context (see <link linkend='keyboard_state'>See
+Keyboard State</link> for a detailed description of each of the keyboard state
 components):
 </para>
 
@@ -967,8 +963,8 @@ by all of the actions associated with the key plus all of the modifiers
 associated with any virtual modifiers bound to the key by the virtual modifier
 mapping. If any of the actions associated with a key affect any component of
 the keyboard group, any modifiers specified in any entry of the group
-compatibility map (see <ulink url="XKBproto.htm#50332257_40656">See Group
-Compatibility Map</ulink>) are reported in the modifier mask. The <emphasis>
+compatibility map (see <link linkend='group_compatibility_map'>See Group
+Compatibility Map</link>) are reported in the modifier mask. The <emphasis>
 SA_ISOLock</emphasis>
  action can theoretically affect any modifier, but the modifier map of an
 <emphasis>
diff --git a/specs/ch13.xml b/specs/ch13.xml
index 5797f9f..f00a467 100644
--- a/specs/ch13.xml
+++ b/specs/ch13.xml
@@ -275,8 +275,7 @@ types</emphasis>
  component of a keyboard mapping specifies the key types that can be associated
 with the various keyboard keys. It affects the <emphasis>
 types</emphasis>
- symbolic name and the list of types associated with the keyboard (see <ulink
-url="XKBproto.htm#50332257_45629">See Key Types</ulink>). The types component
+ symbolic name and the list of types associated with the keyboard (see <link linkend='key_types'>See Key Types</link>). The types component
 of a keyboard mapping can also optionally contain real modifier bindings and
 symbolic names for one or more virtual modifiers.
 </para>
@@ -284,7 +283,7 @@ symbolic names for one or more virtual modifiers.
 
 <para>
 The special types component named "canonical" always contains the types and
-definitions listed in <ulink url="types.htm#24591"></ulink> of this document.
+definitions listed in <link linkend="canonical_key_types">Canonical Key Types</link> of this document.
 </para>
 
 
diff --git a/specs/ch14.xml b/specs/ch14.xml
index 98bde5d..fcf127a 100644
--- a/specs/ch14.xml
+++ b/specs/ch14.xml
@@ -9,8 +9,8 @@ keycodes. The server can generate an <emphasis>
 XkbNewKeyboardNotify</emphasis>
  event when it detects a new keyboard, or in response to an <emphasis>
 XkbGetKeyboardByName</emphasis>
- request (see <ulink url="XKBproto.htm#50332257_13490">See Using the Server’s
-Database of Keyboard Components</ulink>) which loads a new keyboard description.
+ request (see <link linkend='using_the_servers_database_of_keyboard_components'>See Using the Server’s
+Database of Keyboard Components</link>) which loads a new keyboard description.
 </para>
 
 
diff --git a/specs/ch15.xml b/specs/ch15.xml
index fb9472f..7cca36a 100644
--- a/specs/ch15.xml
+++ b/specs/ch15.xml
@@ -113,7 +113,7 @@ Keyboard</emphasis>
 
 <para>
 The XKB extension optionally allows clients to assign any key action (see
-<ulink url="XKBproto.htm#50332257_15763">See Key Actions</ulink>) to core
+<link linkend='key_actions'>See Key Actions</link>) to core
 pointer or input extension device buttons. This makes it possible to control
 the keyboard or generate keyboard key events from extension devices or from the
 core pointer.
diff --git a/specs/ch16.xml b/specs/ch16.xml
index 2ec152b..aeaec30 100644
--- a/specs/ch16.xml
+++ b/specs/ch16.xml
@@ -1215,8 +1215,7 @@ affectWhich</emphasis>
 <para>
 If any components are specified in a client’s event masks, the X server sends
 the client an appropriate event whenever any of those components change state.
-Unless explicitly modified, all event detail masks are empty. <ulink
-url="XKBproto.htm#50332257_22322">See Events</ulink> describes all XKB events
+Unless explicitly modified, all event detail masks are empty. <link linkend='events'>See Events</link> describes all XKB events
 and the conditions under which the server generates them.
 </para>
 
@@ -1533,8 +1532,8 @@ effective modifiers minus any server internal modifiers. The <emphasis>
 grabMods</emphasis>
  return value reports the grab modifiers, which consist of the lookup modifiers
 minus any members of the ignore locks mask that are not either latched or
-logically depressed. <ulink url="XKBproto.htm#50332257_13933">See Keyboard
-State</ulink> describes the lookup modifiers and grab modifiers in more detail.
+logically depressed. <link linkend='keyboard_state'>See Keyboard
+State</link> describes the lookup modifiers and grab modifiers in more detail.
 </para>
 
 
@@ -1557,8 +1556,8 @@ compatGrabMods</emphasis>
  return values report the core protocol compatibility states that correspond to
 the XKB lookup and grab state. All of the compatibility states are computed by
 applying the group compatibility mapping to the corresponding XKB modifier and
-group states, as described in <ulink url="XKBproto.htm#50332257_40656">See
-Group Compatibility Map</ulink>.
+group states, as described in <link linkend='group_compatibility_map'>See
+Group Compatibility Map</link>.
 </para>
 
 
@@ -1822,15 +1821,13 @@ The <emphasis>
 numGroups</emphasis>
  return value reports the current number of groups, and <emphasis>
 groupsWrap</emphasis>
- reports the treatment of out-of-range groups, as described in <ulink
-url="XKBproto.htm#50332257_52755">See Key Symbol Map</ulink>. The <emphasis>
+ reports the treatment of out-of-range groups, as described in <link linkend='key_symbol_map'>See Key Symbol Map</link>. The <emphasis>
 internalMods</emphasis>
  and <emphasis>
 ignoreLockMods</emphasis>
  return values report the current values of the server internal and ignore
-locks modifiers as described in <ulink url="XKBproto.htm#50332257_13933">See
-Keyboard State</ulink>. Both are modifier definitions (<ulink
-url="XKBproto.htm#50332257_11005">See Modifier Definitions</ulink>) which
+locks modifiers as described in <link linkend='keyboard_state'>See
+Keyboard State</link>. Both are modifier definitions (<link linkend='modifier_definitions'>See Modifier Definitions</link>) which
 report the real modifiers, virtual modifiers, and the resulting combination of
 real modifiers that are bound to the corresponding control.
 </para>
@@ -1857,8 +1854,8 @@ mouseKeysMaxSpeed</emphasis>
  and <emphasis>
 mouseKeysCurve</emphasis>
  return values report the current acceleration applied to mouse keys, as
-described in <ulink url="XKBproto.htm#50332257_29074">See The MouseKeysAccel
-Control</ulink>. All times are reported in milliseconds.
+described in <link linkend='the_mousekeysaccel_control'>See The MouseKeysAccel
+Control</link>. All times are reported in milliseconds.
 </para>
 
 
@@ -2224,8 +2221,7 @@ If applied, <emphasis>
 repeatDelay</emphasis>
  and <emphasis>
 repeatInterval</emphasis>
- change the autorepeat characteristics of the keyboard, as described in <ulink
-url="XKBproto.htm#50332257_48937">See The RepeatKeys Control</ulink>. If
+ change the autorepeat characteristics of the keyboard, as described in <link linkend='the_repeatkeys_control'>See The RepeatKeys Control</link>. If
 specified, <emphasis>
 repeatDelay</emphasis>
  and <emphasis>
@@ -2241,8 +2237,8 @@ If applied, the <emphasis>
 slowKeysDelay</emphasis>
  field specifies a new delay for the <emphasis>
 SlowKeys</emphasis>
- control, as defined in <ulink url="XKBproto.htm#50332257_59600">See The
-SlowKeys Control</ulink>. If specified, <emphasis>
+ control, as defined in <link linkend='the_slowkeys_control'>See The
+SlowKeys Control</link>. If specified, <emphasis>
 slowKeysDelay</emphasis>
  must be non-zero, or a <emphasis>
 Value</emphasis>
@@ -2255,8 +2251,8 @@ If applied, the <emphasis>
 debounceDelay</emphasis>
  field specifies a new delay for the <emphasis>
 BounceKeys</emphasis>
- control, as described in <ulink url="XKBproto.htm#50332257_12450">See The
-BounceKeys Control</ulink>. If present, the <emphasis>
+ control, as described in <link linkend='the_bouncekeys_control'>See The
+BounceKeys Control</link>. If present, the <emphasis>
 debounceDelay</emphasis>
  must be non-zero or a <emphasis>
 Value</emphasis>
@@ -2276,8 +2272,8 @@ SA_LockPtrBtn</emphasis>
 mouseKeysDfltBtn</emphasis>
  must specify a legal button for the core pointer device, or a <emphasis>
 Value</emphasis>
- error results. <ulink url="XKBproto.htm#50332257_15763">See Key
-Actions</ulink> describes the <emphasis>
+ error results. <link linkend='key_actions'>See Key
+Actions</link> describes the <emphasis>
 SA_PtrBtn</emphasis>
  and <emphasis>
 SA_LockPtrBtn</emphasis>
@@ -2299,8 +2295,8 @@ mouseKeysCurve</emphasis>
  fields change the rate at which the pointer moves when a key which generates a
 <emphasis>
 SA_MovePtr</emphasis>
- action is held down. <ulink url="XKBproto.htm#50332257_29074">See The
-MouseKeysAccel Control</ulink> describes these <emphasis>
+ action is held down. <link linkend='the_mousekeysaccel_control'>See The
+MouseKeysAccel Control</link> describes these <emphasis>
 MouseKeysAccel</emphasis>
  parameters in more detail. If defined, the <emphasis>
 mouseKeysDelay</emphasis>
@@ -2325,8 +2321,7 @@ Value</emphasis>
 <para>
 If applied, the <emphasis>
 accessXOptions</emphasis>
- field sets the AccessX options, which are described in detail in <ulink
-url="XKBproto.htm#50332257_27926">See The AccessXKeys Control</ulink>. If
+ field sets the AccessX options, which are described in detail in <link linkend='the_accessxkeys_control'>See The AccessXKeys Control</link>. If
 either one of <emphasis>
 XkbStickyKeysMask</emphasis>
  and <emphasis>
@@ -2360,8 +2355,8 @@ accessXTimeoutOptionsMask</emphasis>
  and <emphasis>
 accessXTimeoutOptionsValues</emphasis>
  fields change the behavior of the AccessX Timeout control, as described in
-<ulink url="XKBproto.htm#50332257_27038">See The AccessXTimeout
-Control</ulink>. The <emphasis>
+<link linkend='the_accessxtimeout_control'>See The AccessXTimeout
+Control</link>. The <emphasis>
 accessXTimeout</emphasis>
  must be greater than zero, or a <emphasis>
 Value</emphasis>
@@ -2388,7 +2383,7 @@ Match</emphasis>
 If present, the <emphasis>
 groupsWrap</emphasis>
  field specifies the treatment of out-of-range keyboard groups, as described in
-<ulink url="XKBproto.htm#50332257_52755">See Key Symbol Map</ulink>. If the
+<link linkend='key_symbol_map'>See Key Symbol Map</link>. If the
 <emphasis>
 groupsWrap</emphasis>
  field does not specify a legal treatment for out-of-range groups, a <emphasis>
@@ -3328,8 +3323,8 @@ flags</emphasis>
 last key type specified by this request is the last element in the list. If the
 list of key types is shrunk, any existing key definitions that use key types
 that eliminated are automatically assigned key types from the list of canonical
-key types as described in <ulink url="XKBproto.htm#50332257_35661">See
-Assigning Types To Groups of Symbols for a Key</ulink>. The list of key types
+key types as described in <link linkend='assigning_types_to_groups_of_symbols_for_a_key'>See
+Assigning Types To Groups of Symbols for a Key</link>. The list of key types
 bound to a keyboard must always include the four canonical types and cannot
 have more than <emphasis>
 XkbMaxTypesPerKey</emphasis>
@@ -3741,8 +3736,7 @@ XkbSetMapRecomputeActions</emphasis>
  bit is set in <emphasis>
 flags</emphasis>
 , the actions associated with any keys for which symbol or modifier bindings
-were changed by this request are recomputed as described in <ulink
-url="XKBproto.htm#50332257_66444">See Assigning Actions To Keys</ulink>. Note
+were changed by this request are recomputed as described in <link linkend='assigning_actions_to_keys'>See Assigning Actions To Keys</link>. Note
 that actions are recomputed <emphasis>
 after </emphasis>
 any actions specified in this request are bound to keys, so the actions
@@ -4088,8 +4082,8 @@ recomputeActions</emphasis>
 True</emphasis>
 , the server regenerates recalculates the actions bound to all keyboard keys by
 applying the new symbol interpretations to the entire key symbol map, as
-described in <ulink url="XKBproto.htm#50332257_66444">See Assigning Actions To
-Keys</ulink>.
+described in <link linkend='assigning_actions_to_keys'>See Assigning Actions To
+Keys</link>.
 </para>
 
 
@@ -4245,7 +4239,7 @@ XkbIndicatorStateNotify</emphasis>
 The <emphasis>
 maps</emphasis>
  return value reports the requested indicator maps. Indicator maps are
-described in <ulink url="XKBproto.htm#50332257_36844">See Indicator Maps</ulink>
+described in <link linkend='indicator_maps'>See Indicator Maps</link>
 </para>
 
 
@@ -4719,8 +4713,7 @@ If <emphasis>
 setMap </emphasis>
 is <emphasis>
 True</emphasis>
-, XKB changes the map for the indicator (see <ulink
-url="XKBproto.htm#50332257_36844">See Indicator Maps</ulink>) to reflect the
+, XKB changes the map for the indicator (see <link linkend='indicator_maps'>See Indicator Maps</link>) to reflect the
 values specified in <emphasis>
 map</emphasis>
 .
@@ -5529,9 +5522,8 @@ name</emphasis>
  is a valid atom other than <emphasis>
 None</emphasis>
 , the server returns the keyboard geometry description with that name in the
-server database of keyboard components (see <ulink
-url="XKBproto.htm#50332257_46669">See The Server Database of Keyboard
-Components</ulink>) if one exists. If <emphasis>
+server database of keyboard components (see <link linkend='the_server_database_of_keyboard_components'>See The Server Database of Keyboard
+Components</link>) if one exists. If <emphasis>
 deviceSpec</emphasis>
  does not specify a valid keyboard device, a <emphasis>
 Keyboard</emphasis>
@@ -5570,8 +5562,8 @@ found</emphasis>
 True</emphasis>
 , the remaining fields of the reply describe the requested keyboard geometry.
 The interpretation of the components that make up a keyboard geometry is
-described in detail in <ulink url="XKBproto.htm#50332257_23341">See Keyboard
-Geometry</ulink>
+described in detail in <link linkend='keyboard_geometry'>See Keyboard
+Geometry</link>
 </para>
 
 
@@ -5863,36 +5855,36 @@ per-client-flags are:
     <entry><emphasis>
 XkbPCF_DetectableAutorepeat</emphasis>
 </entry>
-    <entry><ulink url="XKBproto.htm#50332257_79074">See Detectable
-Autorepeat</ulink></entry>
+    <entry><link linkend='detectable_autorepeat'>See Detectable
+Autorepeat</link></entry>
   </row>
   <row rowsep='0'>
     <entry><emphasis>
 XkbPCF_GrabsUseXKBStateMask</emphasis>
 </entry>
-    <entry><ulink url="XKBproto.htm#50332257_83380">See Setting a Passive Grab
-for an XKB State</ulink></entry>
+    <entry><link linkend='setting_a_passive_grab_for_an_xkb_state'>See Setting a Passive Grab
+for an XKB State</link></entry>
   </row>
   <row rowsep='0'>
     <entry><emphasis>
 XkbPCF_AutoResetControlsMask</emphasis>
 </entry>
-    <entry><ulink url="XKBproto.htm#50332257_29682">See Automatic Reset of
-Boolean Controls</ulink></entry>
+    <entry><link linkend='automatic_reset_of_boolean_controls'>See Automatic Reset of
+Boolean Controls</link></entry>
   </row>
   <row rowsep='0'>
     <entry><emphasis>
 XkbPCF_LookupStateWhenGrabbed</emphasis>
 </entry>
-    <entry><ulink url="XKBproto.htm#50332257_39705">See Effects of XKB on Core
-Protocol Events</ulink></entry>
+    <entry><link linkend='effects_of_xkb_on_core_protocol_events'>See Effects of XKB on Core
+Protocol Events</link></entry>
   </row>
   <row rowsep='0'>
     <entry><emphasis>
 XkbPCF_SendEventUsesXKBState</emphasis>
 </entry>
-    <entry><ulink url="XKBproto.htm#50332257_67792">See Sending Events to
-Clients</ulink></entry>
+    <entry><link linkend='sending_events_to_clients'>See Sending Events to
+Clients</link></entry>
   </row>
 </tbody>
 </tgroup>
@@ -6117,8 +6109,7 @@ components.
 <para>
 Each pattern uses the ISO Latin-1 encoding and should contain only parentheses,
 the wildcard characters "?" and "*" or characters that are permitted in a
-component class or member name (see <ulink
-url="XKBproto.htm#50332257_49632">See Component Names</ulink>). Illegal
+component class or member name (see <link linkend='component_names'>See Component Names</link>). Illegal
 characters in a pattern are simply ignored; no error results if a pattern
 contains illegal characters.
 </para>
@@ -6162,15 +6153,15 @@ compatMaps</emphasis>
 symbols</emphasis>
  and <emphasis>
 geometries</emphasis>
- return the hints (see <ulink url="XKBproto.htm#50332257_98074">See Component
-Hints</ulink>) and names of any components from the server database that match
+ return the hints (see <link linkend='component_hints'>See Component
+Hints</link>) and names of any components from the server database that match
 the corresponding pattern.
 </para>
 
 
 <para>
-<ulink url="XKBproto.htm#50332257_46669">See The Server Database of Keyboard
-Components</ulink> describes the X server database of keyboard components in
+<link linkend='the_server_database_of_keyboard_components'>See The Server Database of Keyboard
+Components</link> describes the X server database of keyboard components in
 more detail.
 </para>
 
@@ -6309,8 +6300,8 @@ compatMapSpec</emphasis>
 symbolsSpec</emphasis>
  and <emphasis>
 geometrySpec</emphasis>
- component expressions (see <ulink url="XKBproto.htm#50332257_26148">See
-Partial Components and Combining Multiple Components</ulink>) specify the
+ component expressions (see <link linkend='partial_components_and_combining_multiple_components'>See
+Partial Components and Combining Multiple Components</link>) specify the
 database components to be used to assemble the keyboard description.
 </para>
 
@@ -6419,8 +6410,8 @@ If either field contains a GBN component that depends on some database
 component for which the request does not supply an expression, XKB
 automatically substitutes the special pattern "%" which copies the
 corresponding component from the current keyboard description, as described in
-<ulink url="XKBproto.htm#50332257_26148">See Partial Components and Combining
-Multiple Components</ulink>.
+<link linkend='partial_components_and_combining_multiple_components'>See Partial Components and Combining
+Multiple Components</link>.
 </para>
 
 
@@ -6443,9 +6434,8 @@ If all necessary components are both specified and found, the new keyboard
 description is loaded. If the new keyboard description has a different geometry
 or keycode range than the previous keyboard description, XKB sends <emphasis>
 XkbNewKeyboardNotify</emphasis>
- events to all interested clients. See <ulink
-url="XKBproto.htm#50332257_89133">See Replacing the Keyboard
-"On-the-Fly"</ulink> for more information about the effects of replacing the
+ events to all interested clients. See <link linkend='replacing_the_keyboard_on_the_fly'>See Replacing the Keyboard
+"On-the-Fly"</link> for more information about the effects of replacing the
 keyboard description on the fly.
 </para>
 
@@ -6895,9 +6885,8 @@ deviceID</emphasis>
 which values are being returned. The <emphasis>
 supported</emphasis>
  return value reports the set of optional XKB extension device features that
-are supported by this implementation (see <ulink
-url="XKBproto.htm#50332257_36398">See Interactions Between XKB and the X Input
-Extension</ulink>) for the specified device, and the unsupported return value
+are supported by this implementation (see <link linkend='interactions_between_xkb_and_the_x_input_extension'>See Interactions Between XKB and the X Input
+Extension</link>) for the specified device, and the unsupported return value
 reports any <emphasis>
 unsupported</emphasis>
  features.
@@ -7543,8 +7532,8 @@ Once a client receives a new keyboard notify event which reports a new keycode
 range, the X server reports events from all keys in the new range to that
 client. Clients that do not request or receive new keyboard notify events
 receive events only from keys that fall in the last range for legal keys
-reported to that client. See <ulink url="XKBproto.htm#50332257_89133">See
-Replacing the Keyboard "On-the-Fly"</ulink> for a more detailed explanation.
+reported to that client. See <link linkend='replacing_the_keyboard_on_the_fly'>See
+Replacing the Keyboard "On-the-Fly"</link> for a more detailed explanation.
 </para>
 
 
@@ -7911,8 +7900,7 @@ requestMajor, requestMinor: CARD8</entry>
 <para>
 An <emphasis>
 XkbStateNotify</emphasis>
- event reports that some component of the XKB state (see <ulink
-url="XKBproto.htm#50332257_13933">See Keyboard State</ulink>) has changed.
+ event reports that some component of the XKB state (see <link linkend='keyboard_state'>See Keyboard State</link>) has changed.
 State notify events are usually caused by key or pointer activity, but they can
 also result from explicit state changes requested by the <emphasis>
 XkbLatchLockState</emphasis>
@@ -7926,8 +7914,7 @@ deviceID</emphasis>
  field reports the keyboard on which some state component changed. The
 <emphasis>
 changed</emphasis>
- field reports the XKB state components (see <ulink
-url="XKBproto.htm#50332257_13933">See Keyboard State</ulink>) that have changed
+ field reports the XKB state components (see <link linkend='keyboard_state'>See Keyboard State</link>) that have changed
 and contain any combination of:
 </para>
 
@@ -8176,10 +8163,9 @@ requestMinor: CARD8</entry>
 An <emphasis>
 XkbControlsNotify</emphasis>
  event reports a change in one or more of the global keyboard controls (see
-<ulink url="XKBproto.htm#50332257_28742">See Global Keyboard Controls</ulink>)
-or in the internal modifiers or ignore locks masks (see <ulink
-url="XKBproto.htm#50332257_45660">See Server Internal Modifiers and Ignore
-Locks Behavior</ulink>). Controls notify events are usually caused by and
+<link linkend='global_keyboard_controls'>See Global Keyboard Controls</link>)
+or in the internal modifiers or ignore locks masks (see <link linkend='server_internal_modifiers_and_ignore_locks_behavior'>See Server Internal Modifiers and Ignore
+Locks Behavior</link>). Controls notify events are usually caused by and
 <emphasis>
 XkbSetControls</emphasis>
  request, but they can also be caused by keyboard activity or certain core
@@ -9181,10 +9167,9 @@ detail</emphasis>
 slowKeysDelay</emphasis>
  and <emphasis>
 debounceDelay</emphasis>
- fields always reports the current slow keys acceptance delay (see <ulink
-url="XKBproto.htm#50332257_59600">See The SlowKeys Control</ulink>) and
-debounce delay (see <ulink url="XKBproto.htm#50332257_12450">See The BounceKeys
-Control</ulink>) for the specified keyboard.
+ fields always reports the current slow keys acceptance delay (see <link linkend='the_slowkeys_control'>See The SlowKeys Control</link>) and
+debounce delay (see <link linkend='the_bouncekeys_control'>See The BounceKeys
+Control</link>) for the specified keyboard.
 </para>
 
 
@@ -9348,8 +9333,8 @@ extension device feature that is not supported by the XKB implementation in the
 server for the specified device. The <emphasis>
 unsupported</emphasis>
  mask reports the requested features that are not available on the specified
-device. See <ulink url="XKBproto.htm#50332257_36398">See Interactions Between
-XKB and the X Input Extension</ulink> for more information about possible XKB
+device. See <link linkend='interactions_between_xkb_and_the_x_input_extension'>See Interactions Between
+XKB and the X Input Extension</link> for more information about possible XKB
 interactions with the X Input Extension.
 </para>