Update: 09-10-2024

Author: cldocid2

accounts/account.md

@@ -98,7 +98,7 @@ Using the `DELETE` method logs out the user because the cookie is considered exp
 | `POST` | `/_session` | Do cookie-based user login. | `Content-Type: application/x-www-form-urlencoded` | `name`, `password` |
 | `GET` | `/_session` | Returns cookie-based login user information. | AuthSession cookie returned by POST request. |  |
 | `DELETE` | `/_session` | Log out cookie-based user. | AuthSession cookie returned by POST request. | 
-{: caption="Table 1. Cookie authentication and methods" caption-side="top"}
+{: caption="Cookie authentication and methods" caption-side="top"}
 
 For more information, see [Security scheme](/apidocs/cloudant#security-scheme){: external} on basic authentication.
 
@@ -145,7 +145,7 @@ The three core roles are defined in the following table:
 | `_admin`  | Change security settings, including adding roles. |
 | `_reader` | Read documents from the database. |
 | `_writer` | Create, update, and delete documents (except design documents) in the database. |
-{: caption="Table 2. Core roles" caption-side="top"}
+{: caption="Core roles" caption-side="top"}
 
 The `_reader` and `_writer` roles are exclusive. If a user has the `_writer` role, they can't read documents that they create unless they *also* have the `_reader` role.
 {: tip}
@@ -170,7 +170,7 @@ The focused roles are defined in the following table:
 | `_design`     | Allows create, read, modify, or delete access to design documents. | [`_design`](/docs/Cloudant?topic=Cloudant-design-documents#design-documents), [`_find`](/docs/Cloudant?topic=Cloudant-query#working-with-indexes), [`_index`](/docs/Cloudant?topic=Cloudant-query#working-with-indexes) |
 | `_replicator` | Allows read access to replicate data from a database, and write access to create checkpoints. | [`_local`](/apidocs/cloudant?code=node#postreplicate){: external}, [`_replicate`](/apidocs/cloudant#postreplicate){: external}, [`_replicator`](/docs/Cloudant?topic=Cloudant-replication-api#the-replicator-database) |
 | `_security`   | Allows read and write access to the `/$DATABASE/_security` endpoint. | [`_security`](/apidocs/cloudant#getsecurity){: external} |
-{: caption="Table 3. Focused roles" caption-side="top"}
+{: caption="Focused roles" caption-side="top"}
 
 The nature of the access that is granted depends on the specific API endpoint.
 For example,

accounts/cors.md

@@ -84,7 +84,7 @@ CORS support is available in the {{site.data.keyword.cloudant_short_notm}} Dashb
 
 You can update your CORS settings by using the CORS tab within the dashboard. See the following screenshot:
 
-![CORS dashboard lets you connect to remote servers directly from the brower. Using CORS, you can host browser-based apps on static pages, and load data directly from {{site.data.keyword.cloudant_short_notm}}.](../images/corsdashboard.png){: caption="Figure 1. CORS dashboard" caption-side="bottom"}
+![CORS dashboard lets you connect to remote servers directly from the brower. Using CORS, you can host browser-based apps on static pages, and load data directly from {{site.data.keyword.cloudant_short_notm}}.](../images/corsdashboard.png){: caption="CORS dashboard" caption-side="bottom"}
 
 To see the current CORS configuration,
 open **Account** > **CORS** in the dashboard.

couchdb/compare.md

@@ -117,4 +117,4 @@ click the corresponding link.
 | `GET /{db}/{docid}/{attname}` \n [Cloudant](/apidocs/cloudant#getattachment){: external}, [CouchDB](https://docs.couchdb.org/en/latest/api/document/attachments.html#get--db-docid-attname) | Retrieve the file attachment associated with the document. For {{site.data.keyword.cloudant_short_notm}}, use `{attachment_name}` instead of `{attname}`. | 
 | `PUT /{db}/{docid}/{attname}` \n [Cloudant](/apidocs/cloudant#putattachment){: external}, [CouchDB](https://docs.couchdb.org/en/latest/api/document/attachments.html#put--db-docid-attname) | Upload the supplied content as an attachment to the specified document. For {{site.data.keyword.cloudant_short_notm}}, use `{attachment_name}` instead of `{attname}`. | 
 | `DELETE /{db}/{docid}/{attname}` \n [Cloudant](/apidocs/cloudant#deleteattachment){: external}, [CouchDB](https://docs.couchdb.org/en/latest/api/document/attachments.html#delete--db-docid-attname) | Delete the attachment associated with the specified doc. For {{site.data.keyword.cloudant_short_notm}}, use `{attachment_name}` instead of `{attname}`. |
-{: caption="Table 1. Compare {{site.data.keyword.cloudant_short_notm}} and Apache CouchDB API endpoints" caption-side="top"}
+{: caption="Compare {{site.data.keyword.cloudant_short_notm}} and Apache CouchDB API endpoints" caption-side="top"}

couchdb/comparison.md

@@ -41,7 +41,7 @@ The following table shows the feature and function differences that you must be
 | Attachment size    | 4 GB (default)     | 4 GB (default) | 4 GB (default) | 10 MB |
 | Security auth    | [CouchDB Auth](https://docs.couchdb.org/en/stable/intro/security.html#){: external}     | [CouchDB Auth](https://docs.couchdb.org/en/stable/intro/security.html#){: external} | [CouchDB Auth](https://docs.couchdb.org/en/stable/intro/security.html#){: external} | [{{site.data.keyword.cloudant_short_notm}} legacy auth with API Keys](/docs/Cloudant?topic=Cloudant-work-with-your-account#authorization), [{{site.data.keyword.cloud_notm}} IAM](/docs/Cloudant?topic=Cloudant-managing-access-for-cloudant), or [CouchDB Auth](https://docs.couchdb.org/en/stable/intro/security.html#){: external} |
 | LDAP    | No     | No | No | No |
-{: caption="Table 1. Feature and function differences between {{site.data.keyword.cloudant_short_notm}} and Apache CouchDB" caption-side="top"}
+{: caption="Feature and function differences between {{site.data.keyword.cloudant_short_notm}} and Apache CouchDB" caption-side="top"}
 
 The CouchDB `_show`, `_list`, `_update`, and `_rewrite` functions were deprecated in Apache CouchDB 3.0. For more information, see [deprecated feature warnings](https://docs.couchdb.org/en/stable/whatsnew/3.0.html#deprecated-feature-warnings).
 

databases/cloudant-redis-cache.md

@@ -136,7 +136,7 @@ When you run this script, it takes the data output from the Terraform script and
 1. Open a browser and visit `https://localhost:8080`. 
    See the button for each team in the following screen capture:
 
-    ![{Click the button for each team. ](../images/teamdir1.png){: caption="Figure 1. Team Directory team selectors" caption-side="bottom"}
+    ![{Click the button for each team. ](../images/teamdir1.png){: caption="Team Directory team selectors" caption-side="bottom"}
 
 1. Click any of the colored buttons and obtain a list of team members.
 
@@ -145,7 +145,7 @@ When you run this script, it takes the data output from the Terraform script and
 1. Click the same button that you clicked in step two.
    You can see the data that comes from the {{site.data.keyword.databases-for-redis}} cache and takes a lot less time to execute in the following screen capture:
 
-    ![Click the team button and see the members of the team. ](../images/teamdir2.png){: caption="Figure 2. Team Directory team list and cache information" caption-side="bottom"}
+    ![Click the team button and see the members of the team. ](../images/teamdir2.png){: caption="Team Directory team list and cache information" caption-side="bottom"}
 
    In a real cloud-based application, the application server and the {{site.data.keyword.databases-for-redis}} instance would be close to each other (in the same data center) so latency between the two would be only a few milliseconds. In this example, extra network hops exist between your locally hosted application server and the cloud-hosted {{site.data.keyword.databases-for-redis}} cache so latency gains aren't as good as in production.
    {: note}

databases/conflicts.md

@@ -53,7 +53,7 @@ The following suggested practices might help you decide when to check for, and r
 | Often but not always connected to the network, for example, a laptop. | Often | - | Y |
 | Often but not always connected to the network. | Occasionally | - | Y | 
 | Occasionally connected to the network, for example, a tablet. | Often | - | Y |
-{: caption="Table 1. Suggested practices" caption-side="top"}
+{: caption="Suggested practices" caption-side="top"}
 
 ## Finding conflicts
 {: #finding-conflicts}

databases/creating-a-db.md

@@ -233,7 +233,7 @@ All Go examples require the `service` object to be initialized. For more informa
 | Argument        | Description | Optional | Type | Default | Supported values |
 |-----------------|-------------|----------|------|---------|------------------|
 | `partitioned`   | Determines whether the database is partitioned. | Yes | Boolean | `false` | `true`, `false` |
-{: caption="Table 1. Query arguments" caption-side="top"}
+{: caption="Query arguments" caption-side="top"}
 
 ## Database naming
 {: #database-naming}
@@ -253,7 +253,7 @@ If your database is successfully created, you get a 201 or 202 response. An erro
 |  202  | The database was successfully created on some nodes, but the number of nodes is less than the write quorum. |
 |  400  | Invalid database name. |
 |  412  | Database exists. |
-{: caption="Table 2. HTTP status codes" caption-side="top"}
+{: caption="HTTP status codes" caption-side="top"}
 
 See the following example response that is received after a database is created successfully:
 

databases/database_partitioning.md

@@ -96,7 +96,7 @@ Let's look at some use cases and some good and bad choices for a partition key.
 | Blogging platform          | One document per blog post | `author_id`    | Good - if many authors participate. Easy to query each author's posts.                                     |
 | IOT - sensor readings      | One document per reading    | `device_id`     | Good - if many devices exist, make sure that one device isn't producing many more readings than the others. |
 | IOT - sensor readings      | One document per reading    | `date`          | Bad - current readings cause a "hot spot" on the current date's partition.                                  |
-{: caption="Table 1. Good and bad choices for a partition key" caption-side="top"}
+{: caption="Good and bad choices for a partition key" caption-side="top"}
 
 Some use cases exist where no viable choice for a partition key exists.
 In these situations, it's likely a non-partitioned database is the best

databases/deleting-a-db.md

@@ -122,7 +122,7 @@ An error response uses the HTTP status code to indicate what went wrong.
 | 200  | Database deleted successfully. |
 | 202  | Database was successfully deleted on some nodes, but the number of nodes is less than the write quorum. |
 | 404  | Database does not exist on all of the nodes. |
-{: caption="Table 1. HTTP status codes" caption-side="top"}
+{: caption="HTTP status codes" caption-side="top"}
 
 See the following example response that is received after a database is deleted successfully:
 
@@ -132,4 +132,3 @@ See the following example response that is received after a database is deleted
 }
 ```
 {: codeblock}
-

databases/getting-changes-to-docs-in-db.md

@@ -41,7 +41,7 @@ The `_changes` endpoint accepts several optional query arguments:
 | `since`        | Start the results from changes after the specified sequence identifier. For more information, see the [`since` information](#the-since-argument). | Sequence identifier or `now` | 0 |
 | `style`        | Specifies how many revisions are returned in the changes array. The `main_only` style returns only the current "winning" revision. The `all_docs` style returns all leaf revisions, including conflicts and deleted former conflicts. | `main_only`, `all_docs` | `main_only` |
 | `timeout`      | Wait this number of milliseconds for data, then stop the response. If the `heartbeat` setting is also supplied, it takes precedence over the `timeout` setting. | Any positive number | |
-{: caption="Table 1. Query arguments for _changes endpoint" caption-side="top"}
+{: caption="Query arguments for _changes endpoint" caption-side="top"}
 
 Using `include_docs=true` might have [performance implications](/docs/Cloudant?topic=Cloudant-using-views#multi-document-fetching).
 {: important}
@@ -231,7 +231,7 @@ The following table describes the meaning of the individual fields:
 | `last_seq` | Identifier of the last of the sequence identifiers. Currently, this identifier is the same as the sequence identifier of the last item in the `results`. | String |
 | `results`  | Array of changes that were made to the database. | Array
 | `seq`  | Update sequence identifier. | String |
-{: caption="Table 2. JSON object response fields for _changes" caption-side="top"}
+{: caption="JSON object response fields for _changes" caption-side="top"}
 
 See the following example (abbreviated) response to a `_changes` request:
 

databases/getting-db-details.md

@@ -127,7 +127,7 @@ The elements of the returned structure are shown in the following table:
 | `sizes`               | A JSON object, containing `file`, `external`, and `active` sizes. `active` is the size in bytes of data that is stored internally (excluding old revisions). `external` is the size in bytes of decompressed user data. This value is the billable data size. The `other/data_size` field is an alias for the `external` field. `file` is the size in bytes of data that is stored on the disk. Indexes aren't included in the calculation. The `disk_size` field is an alias for the `file` field. This size includes  data that is waiting for compaction. |
 | `update_seq`          | An opaque string that describes the state of the database. Don't rely on this string for counting the number of updates. |
 | `partitioned_indexes` | A JSON object that appears only if the database is partitioned. `count` is the number of partitioned indexes. `indexes` list the type of partitioned indexes, and `limit` shows the maximum number of allowed partitioned indexes. |
-{: caption="Table 1. Database details" caption-side="top"}
+{: caption="Database details" caption-side="top"}
 
 See the following example (abbreviated) response that contains database details:
 

databases/getting-docs.md

@@ -38,7 +38,7 @@ The `_all_docs` endpoint accepts the following query string and JSON body argume
 | `skip`              | Skip this number of records before returning the results.                                       | Yes      | Numeric         | 0 |
 | `startkey`          | Return records, starting with the specified key.                                                | Yes      | String          | |
 | `startkey_docid` | Return records, starting with the specified document ID. If `startkey` isn't set, this argument is ignored.  | Yes | String | |
-{: caption="Table 1. Query string and JSON body arguments" caption-side="top"}
+{: caption="Query string and JSON body arguments" caption-side="top"}
 
 ## Notes
 {: #get-documents-notes}
@@ -279,7 +279,7 @@ The following table describes the meaning of the individual fields:
 | `rows`       | Array of document objects.                                                          | Array |
 | `total_rows` | Number of documents in the database or view that match the parameters of the query. | Numeric |
 | `pdate_seq` | Current update sequence for the database.                                           | String |
-{: caption="Table 2. JSON object fields" caption-side="top"}
+{: caption="JSON object fields" caption-side="top"}
 
 See the following example response after a request for all documents in a database:
 

databases/sending-multiple-queries-to-db.md

@@ -192,7 +192,7 @@ The results are returned by using the following response JSON object:
 | Response JSON object    | Description | Type |
 |-------------------------|-------------|------|
 | `results` | An array of result objects - one for each query. Each result object contains the same fields as the response to a regular `_all_docs` request. | Array |
-{: caption="Table 1. Response JSON object" caption-side="top"}
+{: caption="Response JSON object" caption-side="top"}
 
 See the following example request with multiple queries:
 

databases/sharding.md

@@ -29,12 +29,12 @@ The servers are available within a single Region.
 If the Region supports Availability Zones, the replicas are stored on servers in different Zones.
 The collection of servers in a Region is called a cluster. 
 
-![A single database is split into Q shards, which are each stored in triplicate on three separate servers.](../images/sharding_database.svg){: caption="Figure 1. Data storage" caption-side="bottom"}
+![A single database is split into Q shards, which are each stored in triplicate on three separate servers.](../images/sharding_database.svg){: caption="Data storage" caption-side="bottom"}
 
 A document is assigned to a particular shard by using consistent hashing of its ID.
 This assignment means that a document is always stored on a known shard and a known set of servers. 
 
-![A single document is assigned to a single shard so ends up on three replicas on three separate servers. ](../images/sharding_document.svg){: caption="Figure 2. Document consistent hashing" caption-side="bottom"}
+![A single document is assigned to a single shard so ends up on three replicas on three separate servers. ](../images/sharding_document.svg){: caption="Document consistent hashing" caption-side="bottom"}
 
 Occasionally,
 shards are rebalanced.
@@ -244,4 +244,3 @@ By specifying a `W` value,
 the client can inspect the HTTP status code in the response to determine whether `W` replicas responded to the coordinator.
 The coordinator waits until a pre-determined timeout for `W` responses from nodes that host copies of the document 
 before it returns the response to the client.
-

documents/bulk-operations.md

@@ -36,7 +36,7 @@ For both inserts and updates, the basic structure of the JSON document in the re
 | Field  | Description             | Type             | Optional |
 |-------|-------------------------|------------------|---------|
 | `docs` | List of document objects | Array of objects | No |
-{: caption="Table 1. Basic bulk request structure" caption-side="top"}
+{: caption="Basic bulk request structure" caption-side="top"}
 
 It is best not to use the `new_edits` field. By default, if conflicts exist, document updates fail and return an error to the client. However, this option applies document revisions without checking for conflicts, so it is easy to accidentally end up with many conflicts.
 {: note}
@@ -48,7 +48,7 @@ Each `docs` array object has the following structure:
 | `_id`      | Document ID  | String  | Optional only for new documents. Otherwise, it's mandatory. |
 | `_rev`     | Document revision  | String  | Mandatory for updates and deletes, not used for new documents. |
 | `_deleted` | Determines whether the document must be deleted. | Boolean | (Optional) The default value is `false`. |
-{: caption="Table 2. Structure of the docs array object" caption-side="top"}
+{: caption="Structure of the docs array object" caption-side="top"}
 
 Recall that for a partitioned database the `_id` field is formed from
 a partition key part and a document key part.
@@ -275,7 +275,7 @@ you get an array with detailed information for each document in the request.
 |------|-------------|
 | `201` | The request did succeed, but this success doesn't imply all documents were updated. Inspect the response body to determine the status of each requested change, and [address any problems](#bulk-document-validation-and-conflict-errors). |
 | `202` | For at least one document, the write [quorum](#quorum-writing-and-reading-data) wasn't met. |
-{: caption="Table 3. HTTP status codes" caption-side="top"}
+{: caption="HTTP status codes" caption-side="top"}
 
 See an example response from a bulk request:
 
@@ -756,7 +756,7 @@ The structure of the returned information is shown in the following tables:
 | Field  | Description             | Type |
 |-------|-------------------------|-----|
 | `docs` | List of document objects | Array of objects |
-{: caption="Table 4. Structure of JSON returned" caption-side="top"}
+{: caption="Structure of JSON returned" caption-side="top"}
 
 Each `docs` array object has the following structure:
 
@@ -765,7 +765,7 @@ Each `docs` array object has the following structure:
 | `id`     | Document ID                        | String |
 | `error`  | Error type                        | String |
 | `reason` | Error string with extended reason | String |
-{: caption="Table 5. Structure for the docs array object" caption-side="top"}
+{: caption="Structure for the docs array object" caption-side="top"}
 
 When a document (or document revision) is not correctly committed to the database because of an error,
 you must check the `error` field to determine error type and course of action.