anchor.diff:  
   The `service key` is usually the name of the service, for example the name of the datasource, or the name of the `mongo` client. When this value is not available, the datasource type, such as `postgresql`, `mysql`, `mongo`, is used instead.
   
  -To avoid naming conflicts between different types of services, the `service key` can  be prefixed with the specific type, such as `postgresql-__<person>__`.
  -
  -The example below shows how to customize the `apiVersion` property of the `PostgresCluster` resource:
  +To avoid naming conflicts between different types of services, prefix the `service key` with a specific datasource type, such as `postgresql-__<person>__`.
  +
  +The following example shows how to customize the `apiVersion` property of the `PostgresCluster` resource:
   
   [source,properties]
   ----
  
positive.code: ----
  
  
  ==== Customizing automatic bindings
  
  Even though automatic binding was developed to eliminate as much manual configuration as possible, there are cases where modifying the generated `ServiceBinding` resource might  still be needed. The generation process exclusively relies on information extracted from the application and the knowledge of the supported Operators, which may not reflect what is deployed in the cluster. The generated resource is based purely on the knowledge of the supported bindable Operators for popular service kinds and a set of conventions that were developed to prevent possible mismatches, such as:
  
  * The target resource name does not match the datasource name
  * A non-default operator needs to be used
  * Version conflicts
  
  .Convetions
  
  * The target resource coordinates are determined based on the type of Operator and the kind of service.
  * The target resource name is set by default to match the service kind, such as `postgresql`, `mysql`, `mongo`.
  * For named datasources, the name of the datasource will be used.
  * For named `mongo` clients, the name of the client will be used.
  
  
  ====
  .Example 1 - Name mismatch
  
negative.code: 
  === Automatic service binding
  
  The `quarkus-kubernetes-service-binding` extension can generate the `ServiceBinding` resource automatically after detecting that an application requires access to the external services that are provided by available bindable Operators.
  
  NOTE: Automatic service binding can be generated for a limited number of service types. To be consistent with established terminology for Kubernetes and Quarkus services, this chapter refers to these service types as kinds.
  
  .Operators that support the service auto-binding
  [%autowidth,%noheader,stripes=even]
  