Polishing the reference manual.

git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@2150 50f2f4bb-b051-0410-bef5-90022cba6387

spring-framework-reference/src/new-in-3.xml

@@ -390,7 +390,7 @@ public class AppConfig {
 
       <para>A general purpose <link linkend="core.convert">type conversion
       system</link> has been introduced. The system is currently used by SpEL
-      for type coersion, and may also be used by a Spring Container when
+      for type conversion, and may also be used by a Spring Container when
       binding bean property values.</para>
 
       <para>In addition, a <link linkend="ui.format">ui.format</link> system
@@ -428,14 +428,14 @@ public class AppConfig {
         <classname>JmsTemplate</classname>. Both server and client side REST
         functionality make use of
         <interfacename>HttpConverter</interfacename>s to facilitate the
-        conversion between objects and their representation in HTTP request
-        and replies.</para>
+        conversion between objects and their representation in HTTP requests
+        and responses.</para>
 
         <para>The <classname>MarshallingHttpMessageConverter</classname> uses
         the <emphasis>Object to XML mapping</emphasis> functionality mentioned
         earlier.</para>
 
-        <para>Refer to the section on <link linkend="mvc">MVC</link> and <link
+        <para>Refer to the sections on <link linkend="mvc">MVC</link> and <link
         linkend="rest-resttemplate">the RestTemplate</link> for more
         information.</para>
       </section>

spring-framework-reference/src/overview.xml

@@ -46,7 +46,7 @@
 
       <para><quote><emphasis>The question is, what aspect of control are
       [they] inverting?</emphasis></quote> Martin Fowler posed this question
-      about Inversion of Control on his site in 2004. Fowler suggested
+      about Inversion of Control (IoC) on his site in 2004. Fowler suggested
       renaming the principle to make it more self-explanatory and came up with
       <firstterm>Dependency Injection</firstterm>.</para>
 
@@ -73,7 +73,8 @@
     Patterns are formalized best practices that <emphasis>you must implement
     yourself</emphasis> in your application.</para>
 
-    <para>The Spring Framework IoC component addresses this concern by
+    <para>The Spring Framework <emphasis>Inversion of Control</emphasis> (IoC)
+    component addresses this concern by
     providing a formalized means of composing disparate components into a
     fully working application ready for use. <!--Preceding sentence sounds like a description of what patterns do (and Spring uses patterns). Distinguish from patterns.-->The
     Spring Framework codifies formalized design patterns as first-class
@@ -140,11 +141,11 @@ TR: This section doesn't read well and I think we should try to rewrite it.-->Nu
       a powerful expression language for querying and manipulating an object
       graph at runtime. It is an extension of the unified expression language
       (unified EL) as specified in the JSP 2.1 specification. The language
-      supports setting and getting of property values, property assignment,
+      supports setting and getting property values, property assignment,
       method invocation, accessing the context of arrays, collections and
       indexers, logical and arithmetic operators, named variables, and
       retrieval of objects by name from Spring's IoC container. It also
-      supports list projection and selection, as well as common list
+      supports list projection and selection as well as common list
       aggregations.</para>
     </section>
 
@@ -165,15 +166,15 @@ TR: This section doesn't read well and I think we should try to rewrite it.-->Nu
       linkend="orm-jdo">JDO</link>, <link
       linkend="orm-hibernate">Hibernate</link>, and <link
       linkend="orm-ibatis">iBatis</link>. Using the ORM package you can use
-      all those O/R-mappers in combination with all the other features Spring
-      offers, such as the simple declarative transaction management feature
-      mentioned previously.</para>
+      all of these O/R-mapping frameworks in combination with all of the other
+      features Spring offers, such as the simple declarative transaction
+      management feature mentioned previously.</para>
 
       <para>The <link linkend="oxm">OXM</link> module provides an abstraction
       layer that supports Object/XML mapping implementations for JAXB, Castor,
       XMLBeans, JiBX and XStream.</para>
 
-      <para>The Java Messaging Service (<link linkend="jms">JMS</link> )module
+      <para>The Java Messaging Service (<link linkend="jms">JMS</link>) module
       contains features for producing and consuming messages.</para>
 
       <para>The <link linkend="transaction">Transaction</link> module supports
@@ -198,7 +199,7 @@ TR: This section doesn't read well and I think we should try to rewrite it.-->Nu
       model-view-controller (<link
       linkend="mvc-introduction"><emphasis>MVC</emphasis></link>)
       implementation for web applications. Spring's MVC framework provides a
-      <emphasis>clean</emphasis> separation between domain model code and web
+      clean separation between domain model code and web
       forms, and integrates with all the other features of the Spring
       Framework.<!--MVC allows you to use *all other features*? (Or just all other features in Web layer?) How do you mean? Does this need elaboration? 
 It sounds important.--><!--TR: REVISED, PLS REVIEW.--></para>
@@ -266,7 +267,7 @@ TR: OK. Added to diagram.--></para>
 
     <para>Spring's <link linkend="transaction-declarative">declarative
     transaction management features</link> make the web application fully
-    transactional, just as it would be if you use EJB container-managed
+    transactional, just as it would be if you used EJB container-managed
     transactions. All your custom business logic can be implemented with
     simple POJOs and managed by Spring's IoC container. Additional services
     include support for sending email and validation that is independent of
@@ -339,9 +340,9 @@ TR: OK. Added to diagram.--></para>
         <caption><para>EJBs - Wrapping existing POJOs</para></caption>
       </mediaobject></para>
 
-    <para>The Spring Framework also provides an <link linkend="ejb">access-
-    and abstraction- layer</link> for Enterprise JavaBeans, enabling you to
-    reuse your existing POJOs and wrap them in stateless session beans, for
+    <para>The Spring Framework also provides an <link linkend="ejb">access
+    and abstraction layer</link> for Enterprise JavaBeans, enabling you to
+    reuse your existing POJOs and wrap them in stateless session beans for
     use in scalable, fail-safe web applications that might need declarative
     security.</para>
   </section>

spring-framework-reference/src/spring-framework-reference.xml

@@ -197,7 +197,7 @@
 			    use of IoC certainly does make both unit and integration
 			    testing easier (in that the presence of setter methods and
 			    appropriate constructors on classes makes them
-			    easier to wire together on a test without having to set up
+			    easier to wire together in a test without having to set up
 			    service locator registries and suchlike)... the chapter
 			    dedicated solely to testing will hopefully convince you of
 			    this as well.