anchor.diff:    }
   }
   ----
  -<1> The `schema` describes what is in the `payload`.
  -<2> The `mysql-server-1.inventory.customers.Key` is the name of the schema which defines the structure where `mysql-server-1` is the connector name, `inventory` is the database, and `customers` is the table.
  -<3> Denotes that the `payload` is not optional.
  -<4> Specifies the type of fields expected in the `payload`.
  -<5> The payload itself, which in this case only contains a single `id` field.
  -
  -This key describes the row in the `inventory.customers` table which is out from the connector entitled `mysql-server-1` whose `id` primary key column has a value of `1001`.
  -=====
  -
  -== Change event value
  -
  -The change event value contains a schema and a payload section. There are three types of change event values which have an envelope structure. The fields in this structure are explained below and marked on each of the change event value examples.
  -
  -* <<Create change event value>>
  -* <<Update change event value>>
  -* <<Delete change event value>>
  -
  -[cols="1,2,7"]
  +
  +.Description of change event key
  +[cols="1,2,7",options="header"]
   |===
   |Item |Field name |Description
   
   |1
  -| `name`
  -| `mysql-server-1.inventory.customers.Key` is the name of the schema which defines the structure where `mysql-server-1` is the connector name, `inventory` is the database and `customers` is the table
  +|`schema`
  +|The schema portion of the key specifies a Kafka Connect schema that describes what is in the key's `payload` portion. 
   
   |2
  -|`op`
  -a| A *mandatory* string that describes the type of operation.
  -
  -.values
  -* `c` = create
  -* `u` = update
  -* `d` = delete
  -* `r` = read (_initial snapshot_ only)
  +|`mysql-server-1.inventory.customers.Key`
  +a|Name of the schema that defines the structure of the key's payload. This schema describes the structure of the primary key for the table that was changed. Key schema names have the format _connector-name_._database-name_._table-name_.`Key`. In this example: + 
  +
  +* `mysql-server-1` is the name of the connector that generated this event. + 
  +* `inventory` is the database that contains the table that was changed. +
  +* `customers` is the table that was updated.
   
   |3
  -|`before`
  -| An optional field that specifies the state of the row before the event occurred.
  +|`optional`
  +|Indicates whether the event key must contain a value in its `payload` field. In this example, a value in the key's payload is required. A value in the key's payload field is optional when a table does not have a primary key.
   
   |4
  -|`after`
  -| An optional field that specifies the state of the row after the event occurred.
  +|`fields` 
  +|Specifies each field that is expected in the `payload`, including each field's name, type, and whether it is required.
   
   |5
  -|`source`
  -a| A *mandatory* field that describes the source metadata for the event including:
  -
  -* the {prodname} version
  -* the connector name
  -* the binlog name where the event was recorded
  -* the binlog position
  -* the row within the event
  -* if the event was part of a snapshot
  -* the name of the affected database and table
  -* the id of the MySQL thread creating the event (non-snapshot only)
  -* the MySQL server ID (if available)
  -* timestamp
  -
  -NOTE: If the {link-prefix}:{link-mysql-connector}#enable-query-log-events-for-cdc_{context}[binlog_rows_query_log_events] option is enabled and the connector has the `include.query` option enabled, a `query` field is displayed which contains the original SQL statement that generated the event.
  -
  -|6
  -|`ts_ms`
  -a| An optional field that displays the time at which the connector processed the event.
  -
  -NOTE: The time is based on the system clock in the JVM running the Kafka Connect task.
  -
  -|===
  -
  -Let us look at an example table and then how the schema and payload would appear for the table.
  -
  -.example table
  +|`payload`
  +|Contains the key for the row for which this change event was generated. In this example, the key, contains a single `id` field whose value is `1001`.
  +
  +|===
  +
  +== Change event values
  +
  +The value in a change event is a bit more complicated than the key. Like the key, the value has a `schema` section and a `payload` section. The `schema` section contains the schema that describes the `Envelope` structure of the `payload` section, including its nested fields. Change events for operations that create, update or delete data all have a value payload with an envelope structure. 
  +
  +Consider the same sample table that was used to show an example of a change event key: 
  +
   [source,sql]
   ----
   CREATE TABLE customers (
  
positive.code:   }
  }
  ----
  <1> The `schema` portion of this event’s _value_ shows the schema for the envelope, the schema for the source structure (which is specific to the MySQL connector and reused across all events), and the table-specific schemas for the `before` and `after` fields.
  ifdef::community[]
  +
  [TIP]
  ====
  The names of the schemas for the `before` and `after` fields are of the form `<logicalName>.<tableName>.Value`, and thus are entirely independent from all other schemas for all other tables. This means that when using the {link-prefix}:{link-avro-serialization}[Avro Converter], the resulting Avro schemas for each table in each logical source have their own evolution and history.
  ====
  endif::community[]
  
  <2> The `payload` portion of this event’s _value_ shows the information in the event, namely that it is describing that the row was created (because `op=c`), and that the `after` field value contains the values of the new inserted row's `id`, `first_name`, `last_name`, and `email` columns.
  ifdef::community[]
  +
  [TIP]
  ====
  It may appear that the JSON representations of the events are much larger than the rows they describe. This is because the JSON representation must include the schema and the payload portions of the message.
  However, by using the {link-prefix}:{link-avro-serialization}[Avro Converter], you can dramatically decrease the size of the actual messages written to the Kafka topics.
  ====
  endif::community[]
  
  === Update change event value
  
  The value of an _update_ change event on the `customers` table has the exact same schema as a _create_ event. The payload is structured the same, but holds different values. Here is an example (formatted for readability):
  
  [source,json,options="nowrap",subs="+attributes"]
  ----
  
negative.code: [id="mysql-connector-events_{context}"]
  = MySQL connector events
  
  The {prodname} MySQL connector generates a data change event for each row-level `INSERT`, `UPDATE`, and `DELETE` operation. Each event contains a key and a value. The structure of the key and the value depends on the table that was changed. 
  
  {prodname} and Kafka Connect are designed around _continuous streams of event messages_. However, the structure of these events may change over time, which can be difficult for consumers to handle. To address this, each event contains the schema for its content, which makes each event self-contained. The following skeleton JSON shows the basic structure of a change event: 
  
  [source,json,index=0]
  ----
  {
   "schema": { //<1>
     ...
    },
   "payload": { //<2>
     ...
   },
   "schema": { //<3> 
     ...
   },
   "payload": { //<4>
     ...
   },
  }
  ----
  
  .Overview of change event basic content
  [cols="1,2,7",options="header"]
  |===
  |Item |Field name |Description
  
  |1
  |`schema`
  |The first `schema` field is part of the event key. It specifies a Kafka Connect schema that describes what is in the event key's `payload` portion. In other words, the first `schema` field describes the structure of the primary key for the table that was changed.
  
  |2
  |`payload`
  |The first `payload` field is part of the event key. It has the structure described by the previous `schema` field and it contains the key for the row that was changed. 
  
  |3
  |`schema`
  |The second `schema` field is part of the event value. It specifies the Kafka Connect schema that describes what is in the event value's `payload` portion. In other words, the second `schema` describes the structure of the row that was changed. Typically, this schema contains nested schemas. 
  
  |4
  |`payload`
  |The second `payload` field is part of the event value. It has the structure described by the previous `schema` field and it contains the actual data for the row that was changed.
  
  |===
  
  By default, the connector streams change event records to topics with names that are the same as the event's originating table. See {link-prefix}:{link-mysql-connector}#the-mysql-connector-and-kafka-topics_{context}[MySQL connector and Kafka topics].
  
  [WARNING]
  ====
  The MySQL connector ensures that all Kafka Connect schema names adhere to the link:http://avro.apache.org/docs/current/spec.html#names[Avro schema name format]. This means that the logical server name must start with a Latin letter or an underscore, that is, a-z, A-Z, or \_. Each remaining character in the logical server name and each character in the database and table names must be a Latin letter, a digit, or an underscore, that is, a-z, A-Z, 0-9, or \_. If there is an invalid character it is replaced with an underscore character.
  
  This can lead to unexpected conflicts if the logical server name, a database name, or a table name contains invalid characters, and the only characters that distinguish names from one another are invalid and thus replaced with underscores.
  ====
  
  == Change event keys
  
  A change event's key contains the schema for the changed table's key and the changed row's actual key. Both the schema and its corresponding payload contain a field for each column in the changed table's `PRIMARY KEY` (or unique constraint) at the time the connector created the event.
  
  Consider the following `customers` table, which is followed by an example of a change event key for this table. 
  
  .Example table
  [source,sql]
  ----
  CREATE TABLE customers (
  