Index: java.html
===================================================================
RCS file: /data/cvs/libvirt/docs/java.html,v
retrieving revision 1.1
diff -u -r1.1 java.html
--- java.html	22 Jul 2008 17:49:53 -0000	1.1
+++ java.html	7 Aug 2008 06:41:10 -0000
@@ -105,7 +105,7 @@
         <h2>Presentation</h2>
         <p>The Java bindings are currently a work in progress based mostly
 on the work of Toth Istvan. The first usable release is 0.2.0, where
-most of the naming conventions were defined. Futher release will try
+most of the naming conventions were defined. Further release will try
 as much as possible to stay compatible</p>
         <h2>Getting it</h2>
         <p>
Index: java.html.in
===================================================================
RCS file: /data/cvs/libvirt/docs/java.html.in,v
retrieving revision 1.1
diff -u -r1.1 java.html.in
--- java.html.in	22 Jul 2008 17:49:53 -0000	1.1
+++ java.html.in	7 Aug 2008 06:41:10 -0000
@@ -6,7 +6,7 @@
 <h2>Presentation</h2>
     <p>The Java bindings are currently a work in progress based mostly
 on the work of Toth Istvan. The first usable release is 0.2.0, where
-most of the naming conventions were defined. Futher release will try
+most of the naming conventions were defined. Further release will try
 as much as possible to stay compatible</p>
 
 <h2>Getting it</h2>
Index: formatdomain.html.in
===================================================================
RCS file: /data/cvs/libvirt/docs/formatdomain.html.in,v
retrieving revision 1.5
diff -u -r1.5 formatdomain.html.in
--- formatdomain.html.in	6 Aug 2008 11:37:54 -0000	1.5
+++ formatdomain.html.in	7 Aug 2008 06:41:11 -0000
@@ -84,12 +84,12 @@
 	(badly named!) refers to an OS that supports the Xen 3 hypervisor
 	guest ABI. There are also two optional attributes, <code>arch</code>
 	specifying the CPU architecture to virtualization, and <code>machine</code>
-	refering to the machine type. The <a href="formatcaps.html">Capabilities XML</a>
+	referring to the machine type. The <a href="formatcaps.html">Capabilities XML</a>
 	provides details on allowed values for these. <span class="since">Since 0.0.1</span></dd>
       <dt><code>loader</code></dt>
       <dd>The optional <code>loader</code> tag refers to a firmware blob
 	used to assist the domain creation process. At this time, it is
-	only needed by Xen fullyvirtualized domains. <span class="since">Since 0.1.0</span></dd>
+	only needed by Xen fully virtualized domains. <span class="since">Since 0.1.0</span></dd>
       <dt><code>boot</code></dt>
       <dd>The <code>dev</code> attribute takes one of the values "fd", "hd",
 	"cdrom" or "network" and is used to specify the next boot device
@@ -104,7 +104,7 @@
     <p>
       Hypervisors employing paravirtualization do not usually emulate
       a BIOS, and instead the host is responsible to kicking off the
-      operating system boot. This may use a pseduo-bootloader in the
+      operating system boot. This may use a pseudo-bootloader in the
       host to provide an interface to choose a kernel for the guest.
       An example is <code>pygrub</code> with Xen.
     </p>
@@ -118,9 +118,9 @@
     <dl>
       <dt><code>bootloader</code></dt>
       <dd>The content of the <code>bootloader</code> element provides
-	a fullyqualified path to the bootloader executable in the
+	a fully qualified path to the bootloader executable in the
 	host OS. This bootloader will be run to choose which kernel
-	to boot. The required output of the bootloader is dependant
+	to boot. The required output of the bootloader is dependent
 	on the hypervisor in use. <span class="since">Since 0.1.0</span></dd>
       <dt><code>bootloader_args</code></dt>
       <dd>The optional <code>bootloader_args</code> element allows
@@ -196,7 +196,7 @@
     <h3><a name="elementsLifecycle">Lifecycle control</a></h3>
 
     <p>
-      It is sometimes neccessary to override the default actions taken
+      It is sometimes necessary to override the default actions taken
       when a guest OS triggers a lifecycle operation. The following
       collections of elements allow the actions to be specified. A
       common use case is to force a reboot to be treated as a poweroff
@@ -301,7 +301,7 @@
     <h3><a name="elementsDevices">Devices</a></h3>
 
     <p>
-      The final set of XML elements are all used to descibe devices
+      The final set of XML elements are all used to describe devices
       provided to the guest domain. All devices occur as children
       of the main <code>devices</code> element.
       <span class="since">Since 0.1.3</span>
@@ -358,7 +358,7 @@
       <dt><code>target</code></dt>
       <dd>The <code>target</code> element controls the bus / device under which the
 	disk is exposed to the guest OS. The <code>dev</code> attribute indicates
-	the "logical" device name. The actual device name specified is not guarenteed to map to
+	the "logical" device name. The actual device name specified is not guaranteed to map to
 	the device name in the guest OS. Treat it as a device ordering hint.
 	The optional <code>bus</code> attribute specifies the type of disk device
 	to emulate; possible values are driver specific, with typical values being
@@ -557,7 +557,7 @@
 
     <dl>
       <dt><code>input</code></dt>
-      <dd>The <code>input</code> element has one madatory attribute, the <code>type</code>
+      <dd>The <code>input</code> element has one mandatory attribute, the <code>type</code>
 	whose value can be either 'mouse' or 'tablet'. The latter provides absolute
 	cursor movement, while the former uses relative movement. The optional
 	<code>bus</code> attribute can be used to refine the exact device type.
@@ -716,7 +716,7 @@
 
     <p>
       NB special case if &lt;console type='pty'&gt;, then the TTY
-      path is also duplicated as an attribute tty='/dv/pts/3'
+      path is also duplicated as an attribute tty='/dev/pts/3'
       on the top level &lt;console&gt; tag. This provides compat
       with existing syntax for &lt;console&gt; tags.
     </p>
@@ -727,7 +727,7 @@
       The character device is passed through to the underlying
       physical character device. The device types must match,
       eg the emulated serial port should only be connected to
-      a host serial port - dont connect a serial port to a parallel
+      a host serial port - don't connect a serial port to a parallel
       port.
     </p>
 
Index: formatdomain.html
===================================================================
RCS file: /data/cvs/libvirt/docs/formatdomain.html,v
retrieving revision 1.10
diff -u -r1.10 formatdomain.html
--- formatdomain.html	6 Aug 2008 11:37:54 -0000	1.10
+++ formatdomain.html	7 Aug 2008 06:41:11 -0000
@@ -252,10 +252,10 @@
 	(badly named!) refers to an OS that supports the Xen 3 hypervisor
 	guest ABI. There are also two optional attributes, <code>arch</code>
 	specifying the CPU architecture to virtualization, and <code>machine</code>
-	refering to the machine type. The <a href="formatcaps.html">Capabilities XML</a>
+	referring to the machine type. The <a href="formatcaps.html">Capabilities XML</a>
 	provides details on allowed values for these. <span class="since">Since 0.0.1</span></dd><dt><code>loader</code></dt><dd>The optional <code>loader</code> tag refers to a firmware blob
 	used to assist the domain creation process. At this time, it is
-	only needed by Xen fullyvirtualized domains. <span class="since">Since 0.1.0</span></dd><dt><code>boot</code></dt><dd>The <code>dev</code> attribute takes one of the values "fd", "hd",
+	only needed by Xen fully virtualized domains. <span class="since">Since 0.1.0</span></dd><dt><code>boot</code></dt><dd>The <code>dev</code> attribute takes one of the values "fd", "hd",
 	"cdrom" or "network" and is used to specify the next boot device
 	to consider. The <code>boot</code> element can be repeated multiple
 	times to setup a priority list of boot devices to try in turn.
@@ -267,7 +267,7 @@
         <p>
       Hypervisors employing paravirtualization do not usually emulate
       a BIOS, and instead the host is responsible to kicking off the
-      operating system boot. This may use a pseduo-bootloader in the
+      operating system boot. This may use a pseudo-bootloader in the
       host to provide an interface to choose a kernel for the guest.
       An example is <code>pygrub</code> with Xen.
     </p>
@@ -277,9 +277,9 @@
 	&lt;bootloader_args&gt;--append single&lt;/bootloader_args&gt;
         ...</pre>
         <dl><dt><code>bootloader</code></dt><dd>The content of the <code>bootloader</code> element provides
-	a fullyqualified path to the bootloader executable in the
+	a fully qualified path to the bootloader executable in the
 	host OS. This bootloader will be run to choose which kernel
-	to boot. The required output of the bootloader is dependant
+	to boot. The required output of the bootloader is dependent
 	on the hypervisor in use. <span class="since">Since 0.1.0</span></dd><dt><code>bootloader_args</code></dt><dd>The optional <code>bootloader_args</code> element allows
 	command line arguments to be passed to the bootloader.
 	<span class="since">Since 0.2.3</span>
@@ -330,7 +330,7 @@
           <a name="elementsLifecycle" id="elementsLifecycle">Lifecycle control</a>
         </h3>
         <p>
-      It is sometimes neccessary to override the default actions taken
+      It is sometimes necessary to override the default actions taken
       when a guest OS triggers a lifecycle operation. The following
       collections of elements allow the actions to be specified. A
       common use case is to force a reboot to be treated as a poweroff
@@ -402,7 +402,7 @@
           <a name="elementsDevices" id="elementsDevices">Devices</a>
         </h3>
         <p>
-      The final set of XML elements are all used to descibe devices
+      The final set of XML elements are all used to describe devices
       provided to the guest domain. All devices occur as children
       of the main <code>devices</code> element.
       <span class="since">Since 0.1.3</span>
@@ -446,7 +446,7 @@
 	<code>type</code> is "block", then the <code>dev</code> attribute specifies
 	the path to the host device to serve as the disk. <span class="since">Since 0.0.3</span></dd><dt><code>target</code></dt><dd>The <code>target</code> element controls the bus / device under which the
 	disk is exposed to the guest OS. The <code>dev</code> attribute indicates
-	the "logical" device name. The actual device name specified is not guarenteed to map to
+	the "logical" device name. The actual device name specified is not guaranteed to map to
 	the device name in the guest OS. Treat it as a device ordering hint.
 	The optional <code>bus</code> attribute specifies the type of disk device
 	to emulate; possible values are driver specific, with typical values being
@@ -628,7 +628,7 @@
           ...
 	  &lt;input type='mouse' bus='usb'/&gt;
 	  ...</pre>
-        <dl><dt><code>input</code></dt><dd>The <code>input</code> element has one madatory attribute, the <code>type</code>
+        <dl><dt><code>input</code></dt><dd>The <code>input</code> element has one mandatory attribute, the <code>type</code>
 	whose value can be either 'mouse' or 'tablet'. The latter provides absolute
 	cursor movement, while the former uses relative movement. The optional
 	<code>bus</code> attribute can be used to refine the exact device type.
@@ -760,7 +760,7 @@
       ...</pre>
         <p>
       NB special case if &lt;console type='pty'&gt;, then the TTY
-      path is also duplicated as an attribute tty='/dv/pts/3'
+      path is also duplicated as an attribute tty='/dev/pts/3'
       on the top level &lt;console&gt; tag. This provides compat
       with existing syntax for &lt;console&gt; tags.
     </p>
@@ -771,7 +771,7 @@
       The character device is passed through to the underlying
       physical character device. The device types must match,
       eg the emulated serial port should only be connected to
-      a host serial port - dont connect a serial port to a parallel
+      a host serial port - don't connect a serial port to a parallel
       port.
     </p>
         <pre>