reviewed XML files and removed extra spaces

Author: markingmyname

docs/database-engine/service-broker/broker-system-messages.md

@@ -18,16 +18,12 @@ Service Broker uses three system message types to communicate status and error i
 
 ## Handling System Messages
 
-
-
 Most of the messages in a Service Broker conversation are the application-defined messages used to communicate between services. Each message must comply with a message type format that was defined by a CREATE MESSAGE TYPE statement. The set of message types allowed for a conversation is defined by the contract specified in the BEGIN DIALOG CONVERSATION statement.
 
 In addition to the application-defined message types specified in the contract, any conversation can also receive messages that use one of three system-defined message types. These message types are used by Service Broker to report errors and the status of dialogs. Every application must contain logic to handle Error messages and End Dialog messages. If the application sets a conversation timer on a dialog conversation, the application must contain logic to handle Dialog Timer messages. Service Broker provides these message types to every service, whether they appear in the contract for the service or not. For more information, see [Handling Service Broker Error Messages](handling-service-broker-error-messages.md).
 
 ## Error Messages
 
-
-
 When a remote service ends a dialog with an error or the local broker detects an unrecoverable error in a dialog, the local broker creates an Error Message. Error messages are of message type **https://schemas.microsoft.com/SQL/ServiceBroker/Error**. Error messages are validated as well-formed XML.
 
 The XML document that is contained in an error message uses the namespace **https://schemas.microsoft.com/SQL/ServiceBroker**. The root element of the document has the local name **Error**, and contains an element named **Code** and an element named **Message**. The **Code** element holds an integer value. The **Message** element holds the human-readable text of the message.
@@ -51,39 +47,22 @@ When an error message arrives for a dialog, the broker raises an error if an app
 
 ## End Dialog Messages
 
-
-
 When an application ends a dialog without specifying an error, the local broker sends an End Dialog message to the remote broker. End Dialog messages are of message type **https://schemas.microsoft.com/SQL/ServiceBroker/EndDialog**.
 
 End Dialog messages are empty messages. A receive operation receives an End Dialog message in the order in which the message arrived on the queue.
 
 ## Dialog Timer Messages
 
-
-
 Dialog timer messages indicate that the conversation timer on a dialog has expired. These messages are of message type **https://schemas.microsoft.com/SQL/ServiceBroker/DialogTimer**. A conversation timer is specific to one side of the conversation; Service Broker never sends a dialog timer message to the other side of the conversation.
 
 Dialog timer messages are empty messages. A receive operation receives the dialog timer message before any other message for that dialog, regardless of the order in which the time-out message arrived on the queue.
 
 ## See Also
 
-
-
-#### Tasks
-
-[How to: Retrieve Information from a Service Broker Error Message (Transact SQL)](how-to-retrieve-information-from-a-service-broker-error-message-transact-sql.md)
-
-#### Reference
-
-[BEGIN CONVERSATION TIMER (Transact-SQL)](../../t-sql/statements/begin-conversation-timer-transact-sql.md)
-
-[BEGIN DIALOG CONVERSATION (Transact-SQL)](../../t-sql/statements/begin-dialog-conversation-transact-sql.md)
-
-[CREATE CONTRACT (Transact-SQL)](../../t-sql/statements/create-contract-transact-sql.md)
-
-[CREATE MESSAGE TYPE (Transact-SQL)](../../t-sql/statements/create-message-type-transact-sql.md)
-
-[END CONVERSATION (Transact-SQL)](../../t-sql/statements/end-conversation-transact-sql.md)
-
-[RECEIVE (Transact-SQL)](../../t-sql/statements/receive-transact-sql.md)
-
+- [How to: Retrieve Information from a Service Broker Error Message (Transact SQL)](how-to-retrieve-information-from-a-service-broker-error-message-transact-sql.md)
+- [BEGIN CONVERSATION TIMER (Transact-SQL)](../../t-sql/statements/begin-conversation-timer-transact-sql.md)
+- [BEGIN DIALOG CONVERSATION (Transact-SQL)](../../t-sql/statements/begin-dialog-conversation-transact-sql.md)
+- [CREATE CONTRACT (Transact-SQL)](../../t-sql/statements/create-contract-transact-sql.md)
+- [CREATE MESSAGE TYPE (Transact-SQL)](../../t-sql/statements/create-message-type-transact-sql.md)
+- - [END CONVERSATION (Transact-SQL)](../../t-sql/statements/end-conversation-transact-sql.md)
+- [RECEIVE (Transact-SQL)](../../t-sql/statements/receive-transact-sql.md)

docs/database-engine/service-broker/creating-a-remote-service-binding.md

@@ -21,11 +21,8 @@ When a conversation is initiated, Service Broker checks to see whether a remote
 > [!NOTE]
 > The behavior is comparable to [Service Broker Dynamic Routing](service-broker-dynamic-routing.md).
 
-
 ## Requesting Remote Service Binding
 
-
-
 Requests for remote service bindings use the message type **https://schemas.microsoft.com/SQL/ServiceBroker/BrokerConfigurationNotice/MissingRemoteServiceBinding**. The message is in XML format, and contains the name of the service for which remote service binding information should be available.
 
 For example, the following message is a request for a remote service binding to the service **http://Adventure-Works.com/Elsewhere**:
@@ -44,11 +41,5 @@ In either case, the application ends the conversation. Service Broker sends one
 
 ## See Also
 
-### Reference
-
-[CREATE REMOTE SERVICE BINDING (Transact-SQL)](../../t-sql/statements/create-remote-service-binding-transact-sql.md)
-
-### Concepts
-
-[Service Broker Configuration Notice Service](service-broker-configuration-notice-service.md)
-
+- [CREATE REMOTE SERVICE BINDING (Transact-SQL)](../../t-sql/statements/create-remote-service-binding-transact-sql.md)
+- [Service Broker Configuration Notice Service](service-broker-configuration-notice-service.md)

docs/database-engine/service-broker/creating-service-broker-contracts.md

@@ -26,14 +26,6 @@ The network format for a message includes the name of the contract. Therefore, c
 
 ## See Also
 
-### Reference
-
-[CREATE CONTRACT (Transact-SQL)](../../t-sql/statements/create-contract-transact-sql.md)
-
-
-### Concepts
-
-[Conversation Architecture](conversation-architecture.md)
-
-[Contracts](contracts.md)
-
+- [CREATE CONTRACT (Transact-SQL)](../../t-sql/statements/create-contract-transact-sql.md)
+- [Conversation Architecture](conversation-architecture.md)
+- [Contracts](contracts.md)

docs/database-engine/service-broker/creating-service-broker-message-types.md

@@ -22,16 +22,12 @@ The Service Broker communications protocols are designed to work with this messa
 
 ## Choosing a Validation Type
 
-
-
 The validation specified for the message depends on the content of the message. A common practice is to use the most restrictive validation available during testing, and then to choose less-restrictive validation to improve performance when the application is deployed. For example, it is possible to exchange a typed XML document as the body of a message that specifies a validation of NONE. In this case, your application validates the message when processing the XML.
 
 The network format for a message includes the name of the message type. Therefore, message type names are often chosen to avoid collation issues and naming conflicts. For more information on naming, see [Naming Service Broker Objects](naming-service-broker-objects.md).
 
 ## Indicating Success and Failure
 
-
-
 An application typically does not define new message types to indicate success or failure. Instead, use the END CONVERSATION statement to indicate that the conversation is complete and that the task succeeded. If the task failed, include the WITH ERROR option to return an error message on the conversation.
 
 In general, only one of the participants in the conversation should end the conversation when the task is complete. The other participant only issues an END CONVERSATION in response to an End Dialog or Error message. The documentation for a service generally specifies which participant ends the conversation if the conversation completes successfully. Providing this documentation helps to avoid problems where neither participant ends the conversation, or where one participant ends the conversation while the other participant is still performing tasks. Both endpoints must be able to process error messages because internal Service Broker messages are delivered to both endpoints. For example, if the dialog lifetime expires before the dialog is closed, both endpoints receive a Service Broker error message.
@@ -40,11 +36,5 @@ Either participant can end a conversation with an error at any time. For a discu
 
 ## See Also
 
-### Reference
-
-[CREATE MESSAGE TYPE (Transact-SQL)](../../t-sql/statements/create-message-type-transact-sql.md)
-
-### Concepts
-
-[Service Broker Communication Protocols](service-broker-communication-protocols.md)
-
+- [CREATE MESSAGE TYPE (Transact-SQL)](../../t-sql/statements/create-message-type-transact-sql.md)
+- [Service Broker Communication Protocols](service-broker-communication-protocols.md)

docs/database-engine/service-broker/developer-responsibilities-for-service-broker.md

@@ -18,23 +18,23 @@ The application developer is responsible for designing the Service Broker applic
 
 The tasks involved in creating an individual application depend on the needs of the application. The following is a common sequence of tasks for developing a Service Broker application:
 
-1.  Plan the application. Create an outline of the tasks that the application must accomplish. Describe the conversations that take place during each task. Which endpoint needs to provide what information, in what order? What processing must take place? What priorities should be assigned to the conversations? All subsequent information depends on this outline.
+1. Plan the application. Create an outline of the tasks that the application must accomplish. Describe the conversations that take place during each task. Which endpoint needs to provide what information, in what order? What processing must take place? What priorities should be assigned to the conversations? All subsequent information depends on this outline.
 
-2.  Determine the format and structure of each message in each conversation. Plan the expected sequence of exchange for the messages, and how each participant in the conversation should respond to errors and messages that are sent in an unexpected order.
+2. Determine the format and structure of each message in each conversation. Plan the expected sequence of exchange for the messages, and how each participant in the conversation should respond to errors and messages that are sent in an unexpected order.
 
-3.  If the conversation uses XML messages, create a schema for each XML message. You use schemas during development, testing, and troubleshooting. When your service is in production, you may decide to remove schema validation from your message types, to improve performance.
+3. If the conversation uses XML messages, create a schema for each XML message. You use schemas during development, testing, and troubleshooting. When your service is in production, you may decide to remove schema validation from your message types, to improve performance.
 
-4.  Create a message type for each message in each conversation.
+4. Create a message type for each message in each conversation.
 
-5.  Create a contract for each conversation. The contract identifies the message types that can be used by each endpoint in the conversation.
+5. Create a contract for each conversation. The contract identifies the message types that can be used by each endpoint in the conversation.
 
-6.  Create a queue to store the messages that will be received by the application.
+6. Create a queue to store the messages that will be received by the application.
 
-7.  Create a service to expose the functionality defined by the contract, and implemented by the stored procedure, that you created. When creating a service, you associate it with the queue you created in the previous step. By doing this, you tell Service Broker that all messages that arrive addressed to that service are to be placed in the identified queue.
+7. Create a service to expose the functionality defined by the contract, and implemented by the stored procedure, that you created. When creating a service, you associate it with the queue you created in the previous step. By doing this, you tell Service Broker that all messages that arrive addressed to that service are to be placed in the identified queue.
 
-8.  Review the priority plans that you established in step 1. Create conversation priorities that cover all conversation endpoints that are designed to use priority levels other than the default. If the priority levels should be used when messages are transmitted from a database, ensure that the HONOR_BROKER_PRIORITY option in that database is set to ON.
+8. Review the priority plans that you established in step 1. Create conversation priorities that cover all conversation endpoints that are designed to use priority levels other than the default. If the priority levels should be used when messages are transmitted from a database, ensure that the HONOR_BROKER_PRIORITY option in that database is set to ON.
 
-9.  Create an application that implements the expected message exchange pattern and processing requirements identified in step 1. If your application uses internal activation, the application is a stored procedure.
+9. Create an application that implements the expected message exchange pattern and processing requirements identified in step 1. If your application uses internal activation, the application is a stored procedure.
 
 10. If your application uses internal activation, alter the queue to enable activation. Specify the stored procedure created in step 8 as the activation stored procedure.
 
@@ -46,4 +46,4 @@ The tasks involved in creating an individual application depend on the needs of
 
 ## See Also
 
-[Planning for Service Broker Development](planning-for-service-broker-development.md)
+- [Planning for Service Broker Development](planning-for-service-broker-development.md)

docs/database-engine/service-broker/handling-service-broker-error-messages.md

@@ -18,8 +18,6 @@ Service Broker applications must handle two types of error messages received fro
 
 ## Reporting Application Error Conditions
 
-
-
 Service Broker applications are typically systems that consist of code running asynchronously on different computers. The parts of the application communicate with each other by using messages sent on Service Broker conversations. The part of the application on one side of a Service Broker conversation can report application errors to the other side by sending error messages. The receiving part of the application must have code to detect an error message and correctly handle the error condition.
 
 Service Broker applications can communicate errors by using either system-defined or application-defined message types.
@@ -61,8 +59,6 @@ The remote part of the application that receives the error message must have cod
 
 ## Handling Error Messages
 
-
-
 Application code receiving messages from Service Broker conversations must have logic to process error messages received from the conversation. The code must detect and handle the following:
 
   - Error messages generated by an application that uses an application-defined error message type.
@@ -83,17 +79,8 @@ Error handling routines should be coded in such a way as to prevent poison messa
 
 ## See Also
 
-### Reference
-
-[BEGIN DIALOG CONVERSATION (Transact-SQL)](../../t-sql/statements/begin-dialog-conversation-transact-sql.md)
-
-[CREATE MESSAGE TYPE (Transact-SQL)](../../t-sql/statements/create-message-type-transact-sql.md)
-
-[END CONVERSATION (Transact-SQL)](../../t-sql/statements/end-conversation-transact-sql.md)
-
-[RECEIVE (Transact-SQL)](../../t-sql/statements/receive-transact-sql.md)
-
-### Concepts
-
-[Broker System Messages](broker-system-messages.md)
-
+- [BEGIN DIALOG CONVERSATION (Transact-SQL)](../../t-sql/statements/begin-dialog-conversation-transact-sql.md)
+- [CREATE MESSAGE TYPE (Transact-SQL)](../../t-sql/statements/create-message-type-transact-sql.md)
+- [END CONVERSATION (Transact-SQL)](../../t-sql/statements/end-conversation-transact-sql.md)
+- [RECEIVE (Transact-SQL)](../../t-sql/statements/receive-transact-sql.md)
+- [Broker System Messages](broker-system-messages.md)

docs/database-engine/service-broker/how-to-configure-target-services-for-anonymous-dialog-security-transact-sql.md

@@ -41,7 +41,7 @@ SQL Server uses dialog security for any conversation to a service for which a re
 [!INCLUDE [SQL Server Service Broker AdventureWorks2008R2](../../includes/service-broker-adventureworks-2008-r2.md)]
 
 ```sql
-    USE AdventureWorks2008R2 ;
+    USE AdventureWorks2008R2;
     GO
 
     --------------------------------------------------------------------