anchor.diff:  <tr>
     <td>service_id*</td>
     <td>string</td>
  -  <td>A broker-generated identifier that represents the resource, and will be passed to the broker for future bind/deprovision requests</td>
  +  <td>A broker-generated identifier that represents the resource, and will be
  +	passed to the broker for future bind/deprovision requests</td>
   </tr>
   <tr>
     <td>configuration*</td>
     <td>object</td>
  -  <td>The configuration used to provision this service, usually a copy of the request attributes</td>
  +  <td>The configuration used to provision this service, usually a copy of the
  +	request attributes</td>
   </tr>
   <tr>
     <td>credentials*</td>
     <td>object</td>
  -  <td>Any credentials that were generated as a result of provisioning, that the broker would like to be stored in the Cloud Controller.</td>
  +  <td>Any credentials that were generated as a result of provisioning, that the
  +	broker would like to be stored in the Cloud Controller.</td>
   </tr>
   <tr>
     <td>dashboard_url</td>
     <td>string</td>
  -  <td>If applicable, the URL that an end-user can visit to monitor/manage the provisioned instances</td>
  +  <td>If applicable, the URL that an end-user can visit to monitor/manage the
  +	provisioned instances</td>
   </tr>
   </tbody>
   </table>
   
   ## <a id="bind"></a>Binding ##
   
  -Binding is a developer-initiated intention (using `cf bind-service`) to make a service instance available to a specific application,
  -and it usually has side effects (such as creating new credentials for an application to access a database).
  -Like provisioning, the developer makes an API call to the Cloud Controller including the instance ID and app ID to be bound,
  -and the Cloud Controller makes an API call to the broker including just the service instance ID (brokers don’t know about apps).
  -
  -The broker must then create a binding, if possible, and respond with both a GWID and credentials.
  +Binding is a developer-initiated intention (using `cf bind-service`) to make a
  +service instance available to a specific application, and it usually has side
  +effects (such as creating new credentials for an application to access a
  +database).
  +Like provisioning, the developer makes an API call to the Cloud Controller
  +including the instance ID and app ID to be bound, and the Cloud Controller makes
  +an API call to the broker including just the service instance ID (brokers don’t
  +know about apps).
  +
  +The broker must then create a binding, if possible, and respond with both a GWID
  +and credentials.
   For services where there is only 1 set of credentials to a logical resource,
   binding can simply return the same credentials to each application,
  -though it will be impossible to properly revoke access to an application during unbind.
  +though it will be impossible to properly revoke access to an application during
  +unbind.
   
   To bind, the Cloud Controller sends a bind request to the broker.
  -The full request URL is determined by concatenating the URL in the catalog + the path below.
  -For legacy reasons, a binding is known as a “handle” on the broker side.
  +The full request URL is determined by concatenating the URL in the catalog + the
  +path below.
  +For legacy reasons, a binding is known as a "handle" on the broker side.
   
   `POST /gateway/v1/configurations/:service_id/handles`
   
  
positive.code: <tr>
    <td>free*</td>
    <td>bool</td>
    <td>Displayed by frontends, used by quota_definitions to determine whether an org can provision a service</td>
  </tr>
  <tr>
    <td>description*</td>
  
negative.code: <tr>
    <td>metadata</td>
    <td>object</td>
    <td>Contains guid and the Cloud Controller URL for manipulating the newly
  	created resource</td>
  </tr>
  <tr>
    <td>entity</td>
  