Removing TBD links

SnehaGunda · SnehaGunda · commit c496a3c90dc0 · 2018-11-09T15:06:49.000-08:00
diff --git a/articles/cosmos-db/account-overview.md b/articles/cosmos-db/account-overview.md
@@ -17,7 +17,7 @@ Azure Cosmos DB is a fully managed platform-as-a-service (PaaS). To begin using
 
 The Azure Cosmos DB account is the fundamental unit of global distribution and high availability. For globally distributing your data and throughput across multiple Azure regions, you can add and remove Azure regions to your account at any time. You can configure your account to have either a single or multiple write regions. For more information, see [how to add and remove Azure regions to your Cosmos account](how-to-manage-database-account.md). You can configure the [default consistency](consistency-levels.md) level on Cosmos account. Cosmos DB provides comprehensive SLAs encompassing throughput, latency at the 99th percentile, consistency, and high availability. For more information, see [Azure Cosmos DB SLAs](https://azure.microsoft.com/en-us/support/legal/sla/cosmos-db/v1_2/).
 
-To securely manage access to all the data within your Azure Cosmos DB account, you can use the master keys associated with your account. To learn more, see [how to authorize requests by using master keys and resource tokens](TBD) article. To further secure access to your data, you can configure a VNET service endpoint and IP-firewall on your Azure Cosmos account. For more information, see [VNET and subnet access control for your Cosmos account](how-to-configure-vnet-service-endpoint.md) and [IP-firewall for your Cosmos account](how-to-configure-firewall.md).
+To securely manage access to all the data within your Azure Cosmos DB account, you can use the master keys associated with your account. To further secure access to your data, you can configure a VNET service endpoint and IP-firewall on your Azure Cosmos account. For more information, see [VNET and subnet access control for your Cosmos account](how-to-configure-vnet-service-endpoint.md) and [IP-firewall for your Cosmos account](how-to-configure-firewall.md).
 
 Currently, you can create a maximum of 100 Azure Cosmos DB accounts under an Azure subscription. A single account can virtually manage unlimited amount of data and provisioned throughput. To manage your data and provisioned throughput, you can create one or more Azure Cosmos databases under your account and within that database, you can create one or more containers.
 
diff --git a/articles/cosmos-db/change-feed-functions.md b/articles/cosmos-db/change-feed-functions.md
@@ -57,11 +57,6 @@ The Azure Cosmos DB Trigger leverages the Change Feed Processor library internal
 
 * [Overview of change feed](change-feed.md)
 * [Ways to read change feed](change-feed-reading.md)
-* [Using change feed with SDK](TBD)
 * [Using change feed processor library](change-feed-processor.md)
-* [How to work with change feed processor library](TBD)
-* [How to work with change feed using JavaScript](TBD)
-* [How to work with change feed using Java](TBD)
-* [How to work with change feed using Spark](TBD)
-* [Concurrency Control](TBD)
-* [Serverless database computing using Azure Cosmos DB and Azure Functions](https://docs.microsoft.com/en-us/azure/cosmos-db/serverless-computing-database)
+* [How to work with change feed processor library](change-feed-processor.md)
+* [Serverless database computing using Azure Cosmos DB and Azure Functions](serverless-computing-database.md)
diff --git a/articles/cosmos-db/change-feed-processor.md b/articles/cosmos-db/change-feed-processor.md
@@ -70,11 +70,4 @@ You are charged for RUs consumed, since data movement in and out of Cosmos conta
 
 * [Overview of change feed](change-feed.md)
 * [Ways to read change feed](change-feed-reading.md)
-* [Using change feed with Azure Functions](TBD)
-* [Using change feed with SDK](TBD)
-* [Using change feed processor library](change-feed-processor.md)
-* [How to work with change feed processor library](TBD)
-* [How to work with change feed using JavaScript](TBD)
-* [How to work with change feed using Java](TBD)
-* [How to work with change feed using Spark](TBD)
-* [Concurrency Control](TBD)
+* [Using change feed with Azure Functions](change-feed-functions.md)
diff --git a/articles/cosmos-db/change-feed-reading.md b/articles/cosmos-db/change-feed-reading.md
@@ -13,20 +13,14 @@ ms.author: rafats
 
 You can work with the Azure Cosmos DB change feed using any of the following options:
 
-* **Using Azure Functions:** Azure Functions is the simplest and recommended option. When you create an Azure Cosmos DB trigger in an Azure Functions application, you can select the container to connect, and the Azure Function gets triggered whenever there is a change to the container. Triggers can be created by using the Azure Functions portal, the Azure Cosmos DB portal or programmatically with SDKs. Visual Studio and VS Code provide support to write Azure Functions, and you can even use the Azure Functions CLI for cross-platform development. You can write and debug the code on your desktop, and then deploy the function with one click. See [Serverless database computing using Azure Functions](serverless-computing-database.md) and [Using change feed with Azure Functions](TBD) articles to learn more.
+* **Using Azure Functions:** Azure Functions is the simplest and recommended option. When you create an Azure Cosmos DB trigger in an Azure Functions application, you can select the container to connect, and the Azure Function gets triggered whenever there is a change to the container. Triggers can be created by using the Azure Functions portal, the Azure Cosmos DB portal or programmatically with SDKs. Visual Studio and VS Code provide support to write Azure Functions, and you can even use the Azure Functions CLI for cross-platform development. You can write and debug the code on your desktop, and then deploy the function with one click. See [Serverless database computing using Azure Functions](serverless-computing-database.md) and [Using change feed with Azure Functions](change-feed-functions.md)) articles to learn more.
 
 * **Using change feed processor library:** The change feed processor library hides complexity and still gives you a complete control of the change feed. The library follows the observer pattern, where your processing function is called by the library. If you have a high throughput change feed, you can instantiate multiple clients to read the change feed. Because you're using change feed processor library, it will automatically divide the load among the different clients without you having to implement this logic. All the complexity is handled by the library. If you want to have your own load balancer, then you can implement `IParitionLoadBalancingStrategy` for a custom partition strategy to process change feed. To learn more, see [using change feed processor library](change-feed-processor.md).
 
-* **Using SDK:** With the SDK, you get a low-level control of the change feed. You can manage the checkpoint, access a particular logical partition key, etc. If you have multiple readers, you can use `ChangeFeedOptions` to distribute read load to different threads or different clients. To learn more, see [using change feed with SDK](TBD).
+* **Using SDK:** With the SDK, you get a low-level control of the change feed. You can manage the checkpoint, access a particular logical partition key, etc. If you have multiple readers, you can use `ChangeFeedOptions` to distribute read load to different threads or different clients. 
 
 ## Next steps
 
 * [Overview of change feed](change-feed.md)
-* [Using change feed with Azure Functions](TBD)
-* [Using change feed with SDK](TBD)
-* [Using change feed processor library](change-feed-processor.md)
-* [How to work with change feed processor library](TBD)
-* [How to work with change feed using JavaScript](TBD)
-* [How to work with change feed using Java](TBD)
-* [How to work with change feed using Spark](TBD)
-* [Concurrency Control](TBD)
+* [Using change feed with Azure Functions](change-feed-functions.md)
+* [Using change feed processor library](change-feed-processor.md)
diff --git a/articles/cosmos-db/change-feed.md b/articles/cosmos-db/change-feed.md
@@ -56,7 +56,7 @@ If a TTL (Time to Live) property is set on an item to -1, change feed will persi
 
 ### Change feed and _etag, _lsn or _ts
 
-The _etag format is internal and you should not take dependency on it, because it can change anytime. _ts is a modification or a creation timestamp. You can use _ts for chronological comparison. _lsn is a batch id that is added for change feed only; it represents the transaction id. Many items may have same _lsn. ETag on FeedResponse is different from the _etag you see on the item. _etag is an internal identifier and is used for concurrency control (see [Concurrency Control](TBD)), it tells about the version of the item, whereas ETag is used for sequencing the feed.
+The _etag format is internal and you should not take dependency on it, because it can change anytime. _ts is a modification or a creation timestamp. You can use _ts for chronological comparison. _lsn is a batch id that is added for change feed only; it represents the transaction id. Many items may have same _lsn. ETag on FeedResponse is different from the _etag you see on the item. _etag is an internal identifier and is used for concurrency control tells about the version of the item, whereas ETag is used for sequencing the feed.
 
 ## Change feed use cases and scenarios
 
@@ -91,10 +91,8 @@ The following are some of the scenarios you can easily implement with change fee
 
 You can work with change feed using the following options:
 
-* [Using change feed with Azure Functions](TBD)
-* [Using change feed with SDK](TBD)
+* [Using change feed with Azure Functions](change-feed-functions.md)
 * [Using change feed with change feed processor library](change-feed-processor.md) 
-* [Using change feed with Spark](TBD)
 
 Change feed is available for each logical partition key within the container, and it can be distributed across one or more consumers for parallel processing as shown in the image below.
 
@@ -106,7 +104,7 @@ Change feed is available for each logical partition key within the container, an
 
 * You can use your [provisioned throughput](request-units.md) to read from the change feed, just like any other Azure Cosmos DB operation, in any of the regions associated with your Azure Cosmos database.
 
-* The change feed includes inserts and update operations made to items within the container. You can capture deletes by setting a "soft-delete" flag within your items (for example, documents) in place of deletes. Alternatively, you can set a finite expiration period for your items with the [TTL capability](TBD). For example, 24 hours and use the value of that property to capture deletes. With this solution, you have to process the changes within a shorter time interval than the TTL expiration period. 
+* The change feed includes inserts and update operations made to items within the container. You can capture deletes by setting a "soft-delete" flag within your items (for example, documents) in place of deletes. Alternatively, you can set a finite expiration period for your items with the [TTL capability](time-to-live.md). For example, 24 hours and use the value of that property to capture deletes. With this solution, you have to process the changes within a shorter time interval than the TTL expiration period. 
 
 * Each change to an item appears exactly once in the change feed, and the clients must manage the checkpointing logic. If you want to avoid the complexity of managing checkpoints, the change feed processor library provides automatic checkpointing and "at least once" semantics. See [using change feed with change feed processor library](change-feed-processor.md).
 
@@ -118,16 +116,10 @@ Change feed is available for each logical partition key within the container, an
 
 * Changes are available in parallel for all logical partition keys of an Azure Cosmos container. This capability allows changes from large containers to be processed in parallel by multiple consumers.
 
-* Applications can request multiple changes feeds on the same container simultaneously. ChangeFeedOptions.StartTime can be used to provide an initial starting point. For example, to find the continuation token corresponding to a given clock time. The ContinuationToken, if specified, wins over   the StartTime and StartFromBeginning values. The precision of ChangeFeedOptions.StartTime is ~5 secs. See an [example of getting a change feed from a specified time period](TBD).
+* Applications can request multiple changes feeds on the same container simultaneously. ChangeFeedOptions.StartTime can be used to provide an initial starting point. For example, to find the continuation token corresponding to a given clock time. The ContinuationToken, if specified, wins over   the StartTime and StartFromBeginning values. The precision of ChangeFeedOptions.StartTime is ~5 secs. 
 
 ## Next steps
 
 * [Ways to read change feed](change-feed-reading.md)
-* [Using change feed with Azure Functions](TBD)
-* [Using change feed with SDK](TBD)
-* [Using change feed processor library](change-feed-processor.md)
-* [How to work with change feed processor library](TBD)
-* [How to work with change feed using JavaScript](TBD)
-* [How to work with change feed using Java](TBD)
-* [How to work with change feed using Spark](TBD)
-* [Concurrency Control](TBD)
+* [Using change feed with Azure Functions](change-feed-functions.md)
+* [Using change feed processor library](change-feed-processor.md)
diff --git a/articles/cosmos-db/database-transactions-optimistic-concurrency.md b/articles/cosmos-db/database-transactions-optimistic-concurrency.md
@@ -49,17 +49,14 @@ The previous section gave an overview of how concurrent operations within a logi
 
 The concurrent updates of an item are subjected to the OCC by Azure Cosmos DB’s communication protocol layer. Azure Cosmos database ensures that the client-side version of the item that you are updating (or deleting) is the same as the version of the item in the Azure Cosmos container. This guarantees that your writes are protected from being overwritten accidentally by the writes of others and vice versa. In a multi-user environment, the optimistic concurrency control protects you from accidentally deleting or updating wrong version of an item. As such, items are protected against the infamous “lost update” or “lost delete” problems.
 
-Every item stored in an Azure Cosmos container has a system defined `__etag` property. The value of the `__etag` is automatically generated and updated by the server every time the item is updated. `__etag` can be used with the client supplied if-match request header to allow the server to decide whether an item can be conditionally updated. The value of the if-match header matches the value of the `__etag` at the server, the item is then updated. If the value of the if-match request header is no longer current, the server rejects the operation with an "HTTP 412 Precondition failure" response message. The client then can refetch the item to acquire the current version of the item on the server or override the version of item in the server with its own `__etag` value for the item. In addition, `__etag` can be used with the if-none-match header to determine whether a refetch of a resource is needed. To learn more, see [how to use optimistic concurrency control](tbd.md).
+Every item stored in an Azure Cosmos container has a system defined `__etag` property. The value of the `__etag` is automatically generated and updated by the server every time the item is updated. `__etag` can be used with the client supplied if-match request header to allow the server to decide whether an item can be conditionally updated. The value of the if-match header matches the value of the `__etag` at the server, the item is then updated. If the value of the if-match request header is no longer current, the server rejects the operation with an "HTTP 412 Precondition failure" response message. The client then can refetch the item to acquire the current version of the item on the server or override the version of item in the server with its own `__etag` value for the item. In addition, `__etag` can be used with the if-none-match header to determine whether a refetch of a resource is needed. 
 
 The item’s __etag value changes every time the item is updated. For replace item operations, if-match must be explicitly expressed as a part of the request options. For an example, see the sample code in [GitHub](https://github.com/Azure/azure-documentdb-dotnet/blob/master/samples/code-samples/DocumentManagement/Program.cs#L398-L446). `__etag` values are implicitly checked for all written items touched by a stored procedure. If any conflict is detected, the stored procedure will roll back the transaction and throws an exception. With this method, either all or no writes within the stored procedure are applied atomically. This is a signal to the application to reapply updates and retry the original client request.
 
 ## Next steps
 
 Learn more about database transactions and optimistic concurrency control in the following articles:
 
-- [Working with Azure Cosmos databases, containers and items](tbd.md)
-- [Stored-procedures, triggers, UDFs, and merge procedures](tbd.md)
-- [Optimistic concurrency control](tbd.md)
-- [How to register and execute stored procedures, triggers, user-defined-functions (UDFs) and merge procedures](tbd.md)
+- [Working with Azure Cosmos databases, containers and items](databases-containers-items.md)
 - [Consistency levels](consistency-levels.md)
 - [Conflict types and resolution policies](conflict-resolution-policies.md)
diff --git a/articles/cosmos-db/databases-containers-items.md b/articles/cosmos-db/databases-containers-items.md
diff --git a/articles/cosmos-db/index-paths.md b/articles/cosmos-db/index-paths.md
diff --git a/articles/cosmos-db/index-types.md b/articles/cosmos-db/index-types.md
