diff --git a/spring-integration-reference/src/core-api.xml b/spring-integration-reference/src/core-api.xml
index e809339f97..e316444796 100644
--- a/spring-integration-reference/src/core-api.xml
+++ b/spring-integration-reference/src/core-api.xml
@@ -31,7 +31,7 @@
           <tbody>
             <row>
               <entry>ID</entry>
-              <entry>java.lang.Object</entry>
+              <entry>java.util.UUID</entry>
             </row>
             <row>
               <entry>TIMESTAMP</entry>
@@ -39,19 +39,15 @@
             </row>
             <row>
               <entry>EXPIRATION_DATE</entry>
-              <entry>java.util.Date</entry>
+              <entry>java.lang.Long</entry>
             </row>
             <row>
               <entry>CORRELATION_ID</entry>
               <entry>java.lang.Object</entry>
             </row>
-            <row>
-              <entry>NEXT_TARGET</entry>
-              <entry>java.lang.Object (can be a String or MessageTarget)</entry>
-            </row>
             <row>
               <entry>RETURN_ADDRESS</entry>
-              <entry>java.lang.Object (can be a String or MessageTarget)</entry>
+              <entry>java.lang.Object (can be a String or MessageChannel)</entry>
             </row>
             <row>
               <entry>SEQUENCE_NUMBER</entry>
@@ -70,7 +66,7 @@
       </table>
     </para>
     <para>
-      Many source and target adapter implementations will also provide and/or expect certain headers, and additional
+      Many inbound/outbound adapter implementations will also provide and/or expect certain headers, and additional
       user-defined headers can also be configured.
     </para>
     <para>
@@ -79,13 +75,13 @@
       <programlisting language="java">new GenericMessage&lt;T&gt;(T payload);
 new GenericMessage&lt;T&gt;(T payload, Map&lt;String, Object&gt; headers)</programlisting>
       When a Message is created, a random unique id will be generated. The constructor that accepts a Map of headers
-      will copy the provided headers to the newly created Message. There are also two convenient subclasses available
-      currently: <classname>StringMessage</classname> and <classname>ErrorMessage</classname>. The latter accepts any
+      will copy the provided headers to the newly created Message. There are also two convenient subclasses available:
+      <classname>StringMessage</classname> and <classname>ErrorMessage</classname>. The latter accepts any
       <classname>Throwable</classname> object as its payload.
     </para>
     <para>
       You may notice that the Message interface defines retrieval methods for its payload and headers but no setters.
-      This is fully intentional so that each Message is unmodifiable after creation. Therefore, when a Message
+      The reason for this is that a Message cannot be modified after its initial creation. Therefore, when a Message
       instance is sent to multiple consumers (e.g. through a Publish Subscribe Channel), if one of those consumers
       needs to send a reply with a different payload type, it will need to create a new Message. As a result, the
       other consumers are not affected by those changes. Keep in mind, that multiple consumers may access the same
@@ -156,10 +152,10 @@ assertEquals(MessagePriority.HIGHEST, anotherMessage.getHeaders().getPriority())
     <para>
       The <interfacename>Message</interfacename> is obviously a very important part of the API. By encapsulating the
       data in a generic wrapper, the messaging system can pass it around without any knowledge of the data's type. As
-      the system evolves to support new types, or when the types themselves are modified and/or extended, the messaging
-      system will not be affected by such changes. On the other hand, when some component in the messaging system
-      <emphasis>does</emphasis> require access to information about the <interfacename>Message</interfacename>, such
-      metadata can typically be stored to and retrieved from the metadata in the Message Headers.
+      an application evolves to support new types, or when the types themselves are modified and/or extended, the
+      messaging system will not be affected by such changes. On the other hand, when some component in the messaging
+      system <emphasis>does</emphasis> require access to information about the <interfacename>Message</interfacename>,
+      such metadata can typically be stored to and retrieved from the metadata in the Message Headers.
     </para>
   </section>
 
@@ -221,8 +217,10 @@ target.send(new StringMessage("test"));</programlisting>
       While the <interfacename>Message</interfacename> plays the crucial role of encapsulating data, it is the
       <interfacename>MessageChannel</interfacename> that decouples message producers from message consumers.
       Spring Integration's top-level <interfacename>MessageChannel</interfacename> interface is defined as follows.
-      <programlisting language="java"><![CDATA[public interface MessageChannel extends MessageSource, BlockingTarget {
+      <programlisting language="java"><![CDATA[public interface MessageChannel {
     String getName();
+
+    boolean send(Message message);
 }]]></programlisting>
       Because it extends <interfacename>BlockingTarget</interfacename>, it inherits the following methods:
       <programlisting language="java">boolean send(Message message);