diff --git a/docs/manual/mod/mod_authn_socache.xml b/docs/manual/mod/mod_authn_socache.xml
index d47cdc1..76043fe 100644
--- a/docs/manual/mod/mod_authn_socache.xml
+++ b/docs/manual/mod/mod_authn_socache.xml
@@ -35,7 +35,7 @@
     lookup is not required for every authenticated request.</p>
 </summary>
 
-<section id="intro"><title>Authentication Cacheing</title>
+<section id="intro"><title>Authentication Caching</title>
     <p>Some users of more heavyweight authentication such as SQL database
     lookups (<module>mod_authn_dbd</module>) have reported it putting an
     unacceptable load on their authentication provider.  A typical case
@@ -43,7 +43,7 @@
     (images, scripts, stylesheets, media, etc), and a request to the page
     generates hundreds of effectively-immediate requests for authenticated
     additional contents.</p>
-    <p>mod_authn_socache provides a solution to this problem by
+    <p><module>mod_authn_socache</module> provides a solution to this problem by
     maintaining a cache of authentication credentials.</p>
 </section>
 
@@ -53,17 +53,18 @@
     network.  Authentication by file (<module>mod_authn_file</module>)
     or dbm (<module>mod_authn_dbm</module>) are unlikely to benefit,
     as these are fast and lightweight in their own right (though in some
-    cases, such as a network-mounted file, cacheing may be worthwhile).
+    cases, such as a network-mounted file, caching may be worthwhile).
     Other providers such as SQL or LDAP based authentication are more
     likely to benefit, particularly where there is an observed
     performance issue.  Amongst the standard modules, <module
     >mod_authnz_ldap</module> manages its own cache, so only
     <module>mod_authn_dbd</module> will usually benefit from this cache.</p>
     <p>The basic rules to cache for a provider are:</p>
-    <ol><li>Include the provider you're cacheing for in an
-            <directive>AuthnCacheProvideFor</directive> directive.</li>
+    <ol><li>Include the provider you're caching for in an
+            <directive module="mod_authn_socache"
+            >AuthnCacheProvideFor</directive> directive.</li>
         <li>List <var>socache</var> ahead of the provider you're
-            cacheing for in your <directive module="mod_auth_basic"
+            caching for in your <directive module="mod_auth_basic"
             >AuthBasicProvider</directive> or <directive module=
             "mod_auth_digest">AuthDigestProvider</directive> directive.</li>
     </ol>
@@ -85,14 +86,14 @@
     </highlight>
 </section>
 
-<section id="dev"><title>Cacheing with custom modules</title>
+<section id="dev"><title>Caching with custom modules</title>
     <p>Module developers should note that their modules must be enabled
-    for cacheing with mod_authn_socache.  A single optional API function
+    for caching with <module>mod_authn_socache</module>.  A single optional API function
     <var>ap_authn_cache_store</var> is provided to cache credentials
     a provider has just looked up or generated.  Usage examples are
     available in <a
     href="http://svn.eu.apache.org/viewvc?view=revision&amp;revision=957072"
-    >r957072</a>, in which three authn providers are enabled for cacheing.</p>
+    >r957072</a>, in which three authn providers are enabled for caching.</p>
 </section>
 
 <directivesynopsis>
@@ -103,7 +104,7 @@
 
 <usage>
     <p>This directive is not normally necessary: it is implied if
-    authentication cacheing is enabled anywhere in <var>httpd.conf</var>.
+    authentication caching is enabled anywhere in <var>httpd.conf</var>.
     However, if it is not enabled anywhere in <var>httpd.conf</var>
     it will by default not be initialised, and is therefore not
     available in a <var>.htaccess</var> context.  This directive
@@ -140,7 +141,7 @@
 <usage>
     <p>This directive specifies an authentication provider or providers
     to cache for.  Credentials found by a provider not listed in an
-    AuthnCacheProvideFor directive will not be cached.</p>
+    <directive>AuthnCacheProvideFor</directive> directive will not be cached.</p>
 
     <p>For example, to cache credentials found by <module>mod_authn_dbd</module>
     or by a custom provider <var>myprovider</var>, but leave those looked
@@ -155,13 +156,13 @@
 <name>AuthnCacheTimeout</name>
 <description>Set a timeout for cache entries</description>
 <syntax>AuthnCacheTimeout <var>timeout</var> (seconds)</syntax>
-<default>300 (5 minutes)</default>
+<default>AuthnCacheTimeout 300 (5 minutes)</default>
 <contextlist><context>directory</context><context>.htaccess</context></contextlist>
 <override>AuthConfig</override>
 
 <usage>
-    <p>Cacheing authentication data can be a security issue, though short-term
-    cacheing is unlikely to be a problem.  Typically a good solution is to
+    <p>Caching authentication data can be a security issue, though short-term
+    caching is unlikely to be a problem.  Typically a good solution is to
     cache credentials for as long as it takes to relieve the load on a
     backend, but no longer, though if changes to your users and passwords
     are infrequent then a longer timeout may suit you.  The default 300
@@ -178,8 +179,8 @@
 <directivesynopsis>
 <name>AuthnCacheContext</name>
 <description>Specify a context string for use in the cache key</description>
-<syntax>AuthnCacheContext <var>directory|server|custom-string</var></syntax>
-<default>directory</default>
+<syntax>AuthnCacheContext directory|server|<var>custom-string</var></syntax>
+<default>AuthnCacheContext directory</default>
 <contextlist><context>directory</context></contextlist>
 
 <usage>
@@ -187,10 +188,10 @@
     username (and realm in the case of Digest Authentication) in constructing
     a cache key.  This serves to disambiguate identical usernames serving
     different authentication areas on the server.</p>
-    <p>Two special values for this are <var>directory</var>, which uses
-    the directory context of the request as a string, and <var>server</var>
+    <p>Two special values for this are <code>directory</code>, which uses
+    the directory context of the request as a string, and <code>server</code>
     which uses the virtual host name.</p>
-    <p>The default is <var>directory</var>, which is also the most
+    <p>The default is <code>directory</code>, which is also the most
     conservative setting.  This is likely to be less than optimal, as it
     (for example) causes <var>$app-base</var>, <var>$app-base/images</var>,
     <var>$app-base/scripts</var> and <var>$app-base/media</var> each to