diff --git a/documentation/src/main/docbook/en-US/modules/bootstrapping.xml b/documentation/src/main/docbook/en-US/modules/bootstrapping.xml
index db7fe83c54..4850b0a3cb 100644
--- a/documentation/src/main/docbook/en-US/modules/bootstrapping.xml
+++ b/documentation/src/main/docbook/en-US/modules/bootstrapping.xml
@@ -23,7 +23,7 @@
 <chapter id="validator-bootstrapping">
   <title>Bootstrapping</title>
 
-  <para>We already seen in <xref linkend="section-validator-instance" /> the
+  <para>We already seen in <xref linkend="section-validator-instance"/> the
   easiest way to create a <classname>Validator</classname> instance -
   <methodname>Validation.buildDefaultValidatorFactory</methodname>. In this
   chapter we have a look at the other methods in
@@ -33,7 +33,7 @@
   <para>The different bootstrapping options allow, amongst other things, to
   bootstrap any Bean Validation implementation on the classpath. Generally, an
   available provider is discovered by the <ulink
-  url="http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service%20Provider">Java
+  url="http://docs.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Service%20Provider">Java
   Service Provider</ulink> mechanism. A Bean Validation implementation
   includes the file
   <filename>javax.validation.spi.ValidationProvider</filename> in
@@ -57,7 +57,7 @@
 
     <para>There are three different methods in the Validation class to create
     a Validator instance. The easiest in shown in <xref
-    linkend="example-build-default-validator-factory" />.</para>
+    linkend="example-build-default-validator-factory"/>.</para>
 
     <example id="example-build-default-validator-factory">
       <title>Validation.buildDefaultValidatorFactory()</title>
@@ -120,7 +120,7 @@ Validator validator = factory.getValidator();</programlisting>
     in your environment or you have a special classloader setup, you are able
     to provide a custom <classname>ValidationProviderResolver</classname>. An
     example in an OSGi environment you could plug your custom provider
-    resolver like seen in <xref linkend="example-provider-resolver" />.</para>
+    resolver like seen in <xref linkend="example-provider-resolver"/>.</para>
 
     <example id="example-provider-resolver">
       <title>Providing a custom ValidationProviderResolver</title>
@@ -156,7 +156,7 @@ Validator validator = factory.getValidator();
   <section id="section-message-interpolator">
     <title><classname>MessageInterpolator</classname></title>
 
-    <para><xref linkend="section-message-interpolation" /> already discussed
+    <para><xref linkend="section-message-interpolation"/> already discussed
     the default message interpolation algorithm. If you have special
     requirements for your message interpolation you can provide a custom
     interpolator using
@@ -164,7 +164,7 @@ Validator validator = factory.getValidator();
     interpolator will be shared by all validators generated by the
     <classname>ValidatorFactory</classname> created from this
     <classname>Configuration</classname>. <xref
-    linkend="example-message-interpolator" /> shows an interpolator (available
+    linkend="example-message-interpolator"/> shows an interpolator (available
     in Hibernate Validator) which can interpolate the value being validated in
     the constraint message. To refer to this value in the constraint message
     you can use: <itemizedlist>
@@ -217,7 +217,7 @@ Validator validator = factory.getValidator();
       to specify a custom implementation of
       <classname>ResourceBundleLocator</classname> allowing you to provide
       your own resource bundles. <xref
-      linkend="example-resource-bundle-locator" /> shows an example. In the
+      linkend="example-resource-bundle-locator"/> shows an example. In the
       example<methodname>
       HibernateValidatorConfiguration.getDefaultResourceBundleLocator</methodname>
       is used to retrieve the default
@@ -257,7 +257,7 @@ configure.messageInterpolator(new ResourceBundleMessageInterpolator(myResourceBu
     would have to be accessed triggering a load from the database. Bean
     Validation controls which property can and cannot be accessed via the
     <classname>TraversableResolver</classname> interface (see <xref
-    linkend="example-traversable-resolver" />). In the example
+    linkend="example-traversable-resolver"/>). In the example
     HibernateValidatorConfiguration.</para>
 
     <example id="example-traversable-resolver">
@@ -330,7 +330,7 @@ public interface TraversableResolver {
     Hibernate Validator gets used in combination with JPA 2. In case you have
     to provide your own resolver you can do so again using the
     <classname>Configuration</classname> object as seen in <xref
-    linkend="example-traversable-resolver-config" />.</para>
+    linkend="example-traversable-resolver-config"/>.</para>
 
     <example id="example-traversable-resolver-config">
       <title>Providing a custom TraversableResolver</title>
@@ -353,12 +353,12 @@ Validator validator = factory.getValidator();
     default <classname>ConstraintValidatorFactory</classname> provided by
     Hibernate Validator requires a public no-arg constructor to instantiate
     <classname>ConstraintValidator</classname> instances (see <xref
-    linkend="section-constraint-validator" />). Using a custom
+    linkend="section-constraint-validator"/>). Using a custom
     <classname>ConstraintValidatorFactory</classname> offers for example the
     possibility to use dependency injection in constraint implementations. The
     configuration of the custom factory is once more via the
     <classname>Configuration</classname> (<xref
-    linkend="example-constraint-validator-factory" />).</para>
+    linkend="example-constraint-validator-factory"/>).</para>
 
     <example id="example-constraint-validator-factory">
       <title>Providing a custom ConstraintValidatorFactory</title>