anchor.diff:  </tr>
   <tr>
     <td>409 Conflict</td>
  -  <td>Should be returned if the requested binding already exists. The expected response body is `{}`, though the description field can be used to return a user-facing error message, as described in <a href="#broker-errors">Broker Errors</a>.</td>
  +  <td>Should be returned if the requested binding already exists. The expected response body is <code>{}</code>, though the description field can be used to return a user-facing error message, as described in <a href="#broker-errors">Broker Errors</a>.</td>
   </tr>
   <tr>
     <td>422 Unprocessable Entity</td>
  
positive.code: 
  ## <a id='binding'></a>Binding ##
  
  <p class="note"><strong>Note</strong>: Not all services must be bindable --- some deliver value just from being provisioned. Brokers that offer services that are not bindable should declare them as such using `bindable: false` in the [Catalog](#catalog-mgmt). Brokers that do not offer any bindable services do not need to implement the endpoint for bind requests.</p>
  
  When the broker receives a bind request from the Cloud Controller, it should return information which helps an application to utilize the provisioned resource. This information is generically referred to as `credentials`. Applications should be issued unique credentials whenever possible, so one application's access can be revoked without affecting other bound applications. For more information on credentials, see [Binding Credentials](binding-credentials.html).
  
  
negative.code: <tbody>
  <tr>
    <td>200 OK</td>
    <td>Binding was deleted. The expected response body is <code>{}</code>.</td>
  </tr>
  <tr>
    <td>410 Gone</td>
    <td>Should be returned if the binding does not exist. The expected response body is <code>{}</code>.</td>
  </tr>
  </tbody>
  </table>
  