diff --git a/spring-integration-reference/src/configuration.xml b/spring-integration-reference/src/configuration.xml
index 00ea716995..c12aface1a 100644
--- a/spring-integration-reference/src/configuration.xml
+++ b/spring-integration-reference/src/configuration.xml
@@ -176,10 +176,12 @@
 </handler-endpoint>]]></programlisting>
       </para>
       <note>
-        Individual endpoint schedules only apply for "Point-to-Point" channels, since in that case only a single
-        subscriber needs to receive the message. On the other hand, when a Spring Integration channel is configured as
-        a "Publish-Subscribe" channel, then the dispatcher will drive all endpoint notifications according to its own
-        default schedule, and any 'schedule' element configured for those endpoints will be ignored.
+        <para>
+          Individual endpoint schedules only apply for "Point-to-Point" channels, since in that case only a single
+          subscriber needs to receive the message. On the other hand, when a Spring Integration channel is configured as
+          a "Publish-Subscribe" channel, then the dispatcher will drive all endpoint notifications according to its own
+          default schedule, and any 'schedule' element configured for those endpoints will be ignored.
+        </para>
       </note>
       <para>
         One of the most important configuration options for endpoints is the concurrency policy. Each endpoint is
@@ -197,13 +199,16 @@
         <classname>ConcurrencyPolicy</classname>), the endpoint's handler will be invoked in the caller's thread.
       </para>
       <tip>
-        The default queue capacity of 0 triggers the creation of a <classname>SynchronousQueue</classname>. In many
-        cases, this is preferable since the direct handoff eliminates the chance of a message handling task being
-        "stuck" in the queue (thread pool executors will favor adding to the queue rather than increasing the pool
-        size). Specifically, whenever a dispatcher for a Point-to-Point channel has more than one subscribed endpoint,
-        a task that is rejected due to an exhausted thread pool can be handled immediately by another endpoint whose
-        pool has one or more threads available. On the other hand, when a particular channel/endpoint may be expecting
-        bursts of activity, setting a queue capacity value might be the best way to accommodate the volume.
+        <para>
+          The default queue capacity of 0 triggers the creation of a <classname>SynchronousQueue</classname>. In many
+          cases, this is preferable since the direct handoff eliminates the chance of a message handling task being
+          "stuck" in the queue (thread pool executors will favor adding to the queue rather than increasing the pool
+          size). Specifically, whenever a dispatcher for a Point-to-Point channel has more than one subscribed
+          endpoint, a task that is rejected due to an exhausted thread pool can be handled immediately by another
+          endpoint whose pool has one or more threads available. On the other hand, when a particular channel/endpoint
+          may be expecting bursts of activity, setting a queue capacity value might be the best way to accommodate the
+          volume.
+        </para>
       </tip>
     </section>
 
diff --git a/spring-integration-reference/src/overview.xml b/spring-integration-reference/src/overview.xml
index d2cc243d83..8e9bee4923 100644
--- a/spring-integration-reference/src/overview.xml
+++ b/spring-integration-reference/src/overview.xml
@@ -48,28 +48,28 @@
     <para>Spring Integration is motivated by the following goals:
       <itemizedlist>
         <listitem>
-          Provide a simple model for implementing complex enterprise integration solutions.
+          <para>Provide a simple model for implementing complex enterprise integration solutions.</para>
         </listitem>
         <listitem>
-          Facilitate asynchronous, message-driven behavior within a Spring-based application.
+          <para>Facilitate asynchronous, message-driven behavior within a Spring-based application.</para>
         </listitem>
         <listitem>
-          Promote intuitive, incremental adoption for existing Spring users.
+          <para>Promote intuitive, incremental adoption for existing Spring users.</para>
         </listitem>
       </itemizedlist>
     </para>
     <para>Spring Integration is guided by the following principles:
       <itemizedlist>
         <listitem>
-          Components should be <emphasis>loosely coupled</emphasis> for modularity and testability.
+          <para>Components should be <emphasis>loosely coupled</emphasis> for modularity and testability.</para>
         </listitem>
         <listitem>
-          The framework should enforce <emphasis>separation of concerns</emphasis> between business logic and
-          integration logic.
+          <para>The framework should enforce <emphasis>separation of concerns</emphasis> between business logic and
+          integration logic.</para>
         </listitem>
         <listitem>
-          Extension points should be abstract in nature but within well-defined boundaries to promote
-	      <emphasis>reuse</emphasis> and <emphasis>portability</emphasis>.
+          <para>Extension points should be abstract in nature but within well-defined boundaries to promote
+	      <emphasis>reuse</emphasis> and <emphasis>portability</emphasis>.</para>
         </listitem>
       </itemizedlist>
     </para>