fix links in sdam

Author: blink1073

source/extended-json.md

@@ -275,7 +275,7 @@ JSON format. If generators provide a default format, the default SHOULD be the R
 
 A generator MAY be capable of exporting strings that adhere to other formats, such as Legacy Extended JSON formats.
 
-A generator SHOULD support at least 100 \[levels of nesting\](#levels of nesting) in a BSON document.
+A generator SHOULD support at least 100 levels of nesting in a BSON document.
 
 #### Transforming BSON
 

source/server-discovery-and-monitoring/server-discovery-and-monitoring.md

@@ -24,15 +24,13 @@ The server discovery and monitoring method is specified in four sections. First,
 [configured](#configuration). Second, it begins [monitoring](#monitoring) by calling
 [hello or legacy hello](../mongodb-handshake/handshake.rst#terms) on all servers. (Multi-threaded and asynchronous
 monitoring is described first, then single-threaded monitoring.) Third, as hello or legacy hello responses are received
-the client [parses them](#parsing-a-hello-or-legacy-hello-response), and fourth, it \[updates its view of the
-topology\](#updates its view of the topology).
+the client [parses them](#parsing-a-hello-or-legacy-hello-response), and fourth, it updates its view of the topology.
 
-Finally, this spec describes how \[drivers update their topology view in response to errors\](#drivers update their
-topology view in response to errors), and includes generous implementation notes for driver authors.
+Finally, this spec describes how drivers update their topology view in response to errors, and includes generous
+implementation notes for driver authors.
 
 This spec does not describe how a client chooses a server for an operation; that is the domain of the Server Selection
-Spec. But there is a section describing the \[interaction between monitoring and server selection\](#interaction between
-monitoring and server selection).
+Spec. But there is a section describing the interaction between monitoring and server selection.
 
 There is no discussion of driver architecture and data structures, nor is there any specification of a user-facing API.
 This spec is only concerned with the algorithm for monitoring the server topology.
@@ -206,7 +204,7 @@ Fields:
   increase, as electionId takes precedence in ordering Default null. Part of the (`electionId`, `setVersion`) tuple.
 - servers: a set of ServerDescription instances. Default contains one server: "localhost:27017", ServerType Unknown.
 - stale: a boolean for single-threaded clients, whether the topology must be re-scanned. (Not related to
-  maxStalenessSeconds, nor to \[stale primaries\](#stale primaries).)
+  maxStalenessSeconds, nor to stale primaries.)
 - compatible: a boolean. False if any server's wire protocol version range is incompatible with the client's. Default
   true.
 - compatibilityError: a string. The error message if "compatible" is false, otherwise null.
@@ -234,13 +232,13 @@ Fields:
   least until
   [drivers allow applications to use readConcern "afterOptime".](../max-staleness/max-staleness.md#future-feature-to-support-readconcern-afteroptime))
 - (=) type: a [ServerType](#servertype) enum value. Default Unknown.
-- (=) minWireVersion, maxWireVersion: the wire protocol version range supported by the server. Both default to 0. \[Use
-  min and maxWireVersion only to determine compatibility\](#use min and maxWireVersion only to determine compatibility).
+- (=) minWireVersion, maxWireVersion: the wire protocol version range supported by the server. Both default to 0.
+  [Use min and maxWireVersion only to determine compatibility](#checking-wire-protocol-compatibility).
 - (=) me: The hostname or IP, and the port number, that this server was configured with in the replica set. Default
   null.
 - (=) hosts, passives, arbiters: Sets of addresses. This server's opinion of the replica set's members, if any. These
-  [hostnames are normalized to lower-case](#hostnames-are-normalized-to-lower-case). Default empty. The client
-  \[monitors all three types of servers\](#monitors all three types of servers) in a replica set.
+  [hostnames are normalized to lower-case](#hostnames-are-normalized-to-lower-case). Default empty. The client monitors
+  all three types of servers in a replica set.
 - (=) tags: map from string to string. Default empty.
 - (=) setName: string or null. Default null.
 - (=) electionId: an ObjectId, if this is a MongoDB 2.6+ replica set member that believes it is primary. See
@@ -575,6 +573,8 @@ Whenever the client checks a server (successfully or not), and regardless of whe
 to the previous server description as defined in [Server Description Equality](#server-description-equality), the
 ServerDescription in TopologyDescription.servers MUST be replaced with the new ServerDescription.
 
+<span id="checking-wire-protocol-compatibility"></span>
+
 ##### Checking wire protocol compatibility
 
 A ServerDescription which is not Unknown is incompatible if:
@@ -960,9 +960,9 @@ See error handling in the [Server Monitoring spec](server-monitoring.rst).
 
 #### Application errors
 
-When processing a network or command error, clients MUST first check the error's \[generation number\](#generation
-number). If the error's generation number is equal to the pool's generation number then error handling MUST continue
-according to [Network error when reading or writing](#network-error-when-reading-or-writing) or
+When processing a network or command error, clients MUST first check the error's generation number. If the error's
+generation number is equal to the pool's generation number then error handling MUST continue according to
+[Network error when reading or writing](#network-error-when-reading-or-writing) or
 ["not writable primary" and "node is recovering"](#not-writable-primary-and-node-is-recovering). Otherwise, the error is
 considered stale and the client MUST NOT update any topology state. (See
 [Why ignore errors based on CMAP's generation number?](#why-ignore-errors-based-on-cmaps-generation-number))
@@ -1275,9 +1275,9 @@ Better to call hello or legacy hello for each new socket, as required by the [Au
 hello or legacy hello response associated with that socket for maxWireVersion, maxBsonObjectSize, etc.: all the fields
 required to correctly communicate with the server.
 
-The hello or legacy hello responses received by monitors determine if the topology as a whole \[is compatible\](#is
-compatible) with the driver, and which servers are suitable for selection. The monitors' responses should not be used to
-determine how to format wire protocol messages to the servers.
+The hello or legacy hello responses received by monitors determine if the topology as a whole is compatible with the
+driver, and which servers are suitable for selection. The monitors' responses should not be used to determine how to
+format wire protocol messages to the servers.
 
 ##### Immutable data
 
@@ -1667,8 +1667,8 @@ shard.
 
 ### Why ignore errors based on CMAP's generation number?
 
-Using CMAP's \[generation number\](#generation number) solves the following race condition among application threads and
-the monitor during error handling:
+Using CMAP's generation number solves the following race condition among application threads and the monitor during
+error handling:
 
 1. Two concurrent writes begin on application threads A and B.
 2. The server restarts.
@@ -1711,7 +1711,7 @@ after its check would happen after the pool was cleared and thus avoid putting i
 ### What is the purpose of topologyVersion?
 
 [topologyVersion](#topologyversion) solves the following race condition among application threads and the monitor when
-handling \[State Change Errors\](#State Change Errors):
+handling State Change Errors:
 
 1. Two concurrent writes begin on application threads A and B.
 2. The primary steps down.

source/server-discovery-and-monitoring/server-monitoring.md

@@ -466,9 +466,9 @@ clients MUST cancel the hello or legacy hello check on that server and close the
 
 ### Polling Protocol
 
-The polling protocol is used to monitor MongoDB \< 4.4 servers or when \[streaming is disabled\](#streaming is
-disabled). The client [checks](#check) a server with a hello or legacy hello command and then sleeps for
-heartbeatFrequencyMS before running another check.
+The polling protocol is used to monitor MongoDB \< 4.4 servers or when streaming is disabled. The client
+[checks](#check) a server with a hello or legacy hello command and then sleeps for heartbeatFrequencyMS before running
+another check.
 
 ### Marking the connection pool as ready (CMAP only)
 
@@ -499,9 +499,8 @@ the client MUST follow these steps:
    [JAVA-1159](https://jira.mongodb.org/browse/JAVA-1159).)
 5. Otherwise, wait for heartbeatFrequencyMS (or minHeartbeatFrequencyMS if a check is requested) before restarting the
    monitoring protocol on a new connection.
-   - Note that even in the streaming protocol, a monitor in this state will wait for an application operation to
-     \[request an immediate check\](#request an immediate check) or for the heartbeatFrequencyMS timeout to expire
-     before beginning the next check.
+   - Note that even in the streaming protocol, a monitor in this state will wait for an application operation to request
+     an immediate check or for the heartbeatFrequencyMS timeout to expire before beginning the next check.
 
 See the pseudocode in the `Monitor thread` section.
 

source/server-selection/server-selection.md

@@ -331,6 +331,8 @@ The primary and all secondaries are candidates, but only eligible candidates are
 spec defines several other server types that could appear in a replica set. Such types are never candidates, eligible or
 suitable.
 
+<span id="algorithm-for-filtering-by-staleness"></span>
+
 ##### maxStalenessSeconds
 
 The maximum replication lag, in wall clock time, that a secondary can suffer and still be eligible.
@@ -393,6 +395,8 @@ After filtering servers according to `mode`, and before filtering with `tag_sets
 
 See the Max Staleness Spec for overall description and justification of this feature.
 
+<span id="algorithm-for-filtering-by-tag_sets"></span>
+
 ##### tag_sets
 
 The read preference `tag_sets` parameter is an ordered list of tag sets used to restrict the eligibility of servers,
@@ -687,7 +691,7 @@ For multi-threaded clients, the server selection algorithm is as follows:
     ["Server selection succeeded" message](#server-selection-succeeded-message). Do not go onto later steps.
 09. Request an immediate topology check, then block the server selection thread until the topology changes or until the
     server selection timeout has elapsed
-10. If server selection has timed out, raise a \[server selection error\](#server selection error) and log a
+10. If server selection has timed out, raise a [server selection error](#server-selection-errors) and log a
     ["Server selection failed" message](#server-selection-failed-message).
 11. Goto Step #2
 
@@ -711,7 +715,7 @@ Therefore, for single-threaded clients, the server selection algorithm is as fol
 04. If the topology is stale, proceed as follows:
     - record the target scan time as last scan time plus `minHeartBeatFrequencyMS`
     - if [serverSelectionTryOnce](#serverselectiontryonce) is false and the target scan time would exceed the maximum
-      time, raise a \[server selection error(#server selection error) and log a
+      time, raise a [server selection error](#server-selection-errors) and log a
       ["Server selection failed" message](#server-selection-failed-message).
     - if the current time is less than the target scan time, sleep until the target scan time
     - do a blocking immediate topology check (which must also update the last scan time and mark the topology as no
@@ -728,11 +732,11 @@ Therefore, for single-threaded clients, the server selection algorithm is as fol
     ["Server selection succeeded" message](#server-selection-succeeded-message).; otherwise, mark the topology stale and
     continue to step #9.
 09. If [serverSelectionTryOnce](#serverselectiontryonce) is true and the last scan time is newer than the selection
-    start time, raise a \[server selection error\](#server selection error) and log a
+    start time, raise a [server selection error](#server-selection-errors) and log a
     ["Server selection failed" message](#server-selection-failed-message); otherwise, log a
     ["Waiting for suitable server to become available" message](#waiting-for-suitable-server-to-become-available-message)
     if one has not already been logged for this operation, and goto Step #4
-10. If the current time exceeds the maximum time, raise a \[server selection error\](#server selection error) and log a
+10. If the current time exceeds the maximum time, raise a [server selection error](#server-selection-errors) and log a
     ["Server selection failed" message](#server-selection-failed-message).
 11. Goto Step #4
 
@@ -801,8 +805,8 @@ If `mode` is 'secondary' or 'nearest':
 > 3. From the remaining servers, select servers matching the `tag_sets`.
 > 4. From these, select one server within the latency window.
 
-(See \[algorithm for filtering by staleness\](#algorithm for filtering by staleness), \[algorithm for filtering by
-tag_sets\](#algorithm for filtering by tag_sets), and
+(See [algorithm for filtering by staleness](#algorithm-for-filtering-by-staleness),
+[algorithm for filtering by tag_sets](#algorithm-for-filtering-by-tag_sets), and
 [filtering suitable servers based on the latency window](#filtering-suitable-servers-based-on-the-latency-window) for
 details on each step, and
 [why is maxStalenessSeconds applied before tag_sets?](#why-is-maxstalenessseconds-applied-before-tag_sets).)