fix validation

Original commit message from CVS:
fix validation

diff --git a/common b/common
index 773e3a6..79e6940 160000 (submodule)
--- a/common
+++ b/common
@@ -1 +1 @@
-Subproject commit 773e3a64961084c37477faa464f12add3dfcd6dc
+Subproject commit 79e6940e7ff1a6cbf959a1f7a0a3d1ed3f90d3ee

diff --git a/docs/faq/Makefile.am b/docs/faq/Makefile.am
index ea06c14..0af304a 100644 (file)
--- a/docs/faq/Makefile.am
+++ b/docs/faq/Makefile.am
@@ -35,3 +35,7 @@ www-faq: gstreamer-faq
                perl -i -p -e's@href="index\.html@href="index.php@' $$a; \
                perl -i -p -e's@href="(ar.*)\.html@href="$$1.php@' $$a; \
        done
+
+check:
+       xmllint -noout -valid $(MAIN)
+

diff --git a/docs/faq/cvs.xml b/docs/faq/cvs.xml
index 87e713f..15dee4c 100644 (file)
--- a/docs/faq/cvs.xml
+++ b/docs/faq/cvs.xml
@@ -30,15 +30,16 @@ prefix both aclocal and libtool are installed.
         <para>
 You can do three things to fix this :
 <orderedlist>
-<listitem>install automake in the same prefix as libtool</listitem>
-<listitem>force use of the automake installed in the same prefix as libtool
-by using the --with-automake option</listitem>
-<listitem>figure out what prefix libtool has been installed to and point
-aclocal to the right location by running</listitem>
+<listitem><para>install automake in the same prefix as libtool</para></listitem>
+<listitem><para>force use of the automake installed in the same prefix as libtool
+by using the --with-automake option</para></listitem>
+<listitem><para>figure out what prefix libtool has been installed to and point
+aclocal to the right location by running
 <programlisting>
 export ACLOCAL_FLAGS="-I $(prefix)/share/aclocal"
 </programlisting>
 where you replace prefix with the prefix where libtool was installed.
+</para></listitem>
 </orderedlist>
        </para>
       </answer>

diff --git a/docs/faq/developing.xml b/docs/faq/developing.xml
index e3b4c29..459c613 100644 (file)
--- a/docs/faq/developing.xml
+++ b/docs/faq/developing.xml
@@ -1,7 +1,7 @@
 <sect1 id="chapter-developing">
   <title id="title-developing">Developing applications with GStreamer</title>
 
-  <qandaset defaultlabel="qandaset-developing">
+  <qandaset>
 
     <qandaentry>
       <question id="developing-compile-programs">

diff --git a/docs/faq/general.xml b/docs/faq/general.xml
index 4b832a3..eec5e6b 100644 (file)
--- a/docs/faq/general.xml
+++ b/docs/faq/general.xml
@@ -30,17 +30,17 @@ Why is GStreamer written in C ? Why not C++/Objective-C/... ?
 We like C. Aside from "personal preference", there are a number of technical 
 reasons why C is nice in this project:
 <itemizedlist>
-<listitem>C is extremely portable.</listitem>
-<listitem>C is fast.</listitem>
-<listitem>It is easy to make language bindings for libraries written in C.
-</listitem>
-<listitem>The GObject object system provided by GLib implements objects in C, 
+<listitem><para>C is extremely portable.</para></listitem>
+<listitem><para>C is fast.</para></listitem>
+<listitem><para>It is easy to make language bindings for libraries written in C.
+</para></listitem>
+<listitem><para>The GObject object system provided by GLib implements objects in C, 
 in a portable, powerful way. This library provides for introspection and 
 runtime dynamic typing. It is a full OO system, but without the syntactic 
 sugar. If you want sugar, take a look at 
-<ulink url="http://www.5z.com/jirka/gob.html">GOB</ulink>.</listitem>
-<listitem>Use of C integrates nicely with Gtk+ and GNOME. Some people like 
-this a lot, but neither Gtk+ nor GNOME are required by GStreamer.</listitem>
+<ulink url="http://www.5z.com/jirka/gob.html">GOB</ulink>.</para></listitem>
+<listitem><para>Use of C integrates nicely with Gtk+ and GNOME. Some people like 
+this a lot, but neither Gtk+ nor GNOME are required by GStreamer.</para></listitem>
 </itemizedlist>
 </para>
 <para>
@@ -88,10 +88,10 @@ terms of the libraries we use. As a general rule, GStreamer aims at using
 only LGPL or BSD licensed libraries if available and only use GPL or 
 proprietary libraries where no good LGPL or BSD alternatives are available.
         </para>
+        <para>
 From GStreamer 0.4.2 on, we implemented a license field for all of the plugins,
 and in the future we might have the application enforce a stricter policy
 (much like tainting in the kernel).
-        <para>
         </para>
       </answer>
     </qandaentry>

diff --git a/docs/faq/getting.xml b/docs/faq/getting.xml
index 1ece463..ca2cfbd 100644 (file)
--- a/docs/faq/getting.xml
+++ b/docs/faq/getting.xml
@@ -11,12 +11,12 @@
         <para>
 Generally speaking, you have three options, ranging from easy to hard :
 <itemizedlist>
-<item><link linkend="getting-gstreamer-packages">
-distribution-specific packages</link></item>
-<item><link linkend="getting-gstreamer-source">
-source tarballs</link></item>
-<item><link linkend="getting-gstreamer-packages">
-CVS</link></item>
+<listitem><para><link linkend="getting-gstreamer-packages">
+distribution-specific packages</link></para></listitem>
+<listitem><para><link linkend="getting-gstreamer-source">
+source tarballs</link></para></listitem>
+<listitem><para><link linkend="getting-gstreamer-packages">
+CVS</link></para></listitem>
 </itemizedlist>
         </para>
       </answer>

diff --git a/docs/faq/start.xml b/docs/faq/start.xml
index 74a97b6..fa1d82c 100644 (file)
--- a/docs/faq/start.xml
+++ b/docs/faq/start.xml
@@ -3,18 +3,25 @@
   <para>
 So you're eager to get started learning about GStreamer.
 There's a few ways you can get started.
-<itemizedlist>
-<listitem>If you want to learn by reading about it, start with
-<xref linkend="title-general" endterm="title-general"/></listitem>
-<listitem>
+    <itemizedlist>
+      <listitem>
+        <para>
+If you want to learn by reading about it, start with
+          <xref linkend="title-general" endterm="title-general"/>
+        </para>
+      </listitem>
+      <listitem>
+        <para>
 If you'd rather learn by trying it out, start with
 <xref linkend="title-getting" endterm="title-getting"/>
-</listitem>
-<listitem>
+        </para>
+      </listitem>
+      <listitem>
+        <para>
 If you want to live on the bleeding edge and develop and use CVS, see
 <xref linkend="title-cvs" endterm="title-cvs"/>
-</listitem>
-</itemizedlist>
+        </para>
+      </listitem>
+    </itemizedlist>
   </para>
 </sect1>
-

diff --git a/docs/faq/troubleshooting.xml b/docs/faq/troubleshooting.xml
index b2fbcdd..d23df84 100644 (file)
--- a/docs/faq/troubleshooting.xml
+++ b/docs/faq/troubleshooting.xml
@@ -24,11 +24,11 @@ If you're not sure either way, then chances are good that you don't have
 it.  You should get the plug-in and run gst-register to register it.
 How to get the plug-in depends on your distribution.
 <itemizedlist>
-<listitem>if you run GStreamer using packages for your distribution, you
+<listitem><para>if you run GStreamer using packages for your distribution, you
 should check what packages are available for your distribution and see
 if any of the available packages contains the plug-in.
-</listitem>
-<listitem>if you run GStreamer from a source install, there's a good chance
+</para></listitem>
+<listitem><para>if you run GStreamer from a source install, there's a good chance
 the plug-in didn't get built because you are missing an external library.
 When you ran configure, you should have gotten output of what plug-ins are
 going to be built.  You can re-run configure to see if it's there.
@@ -37,13 +37,13 @@ The most likely is that you're missing the library you need for it.
 Check the README file in gst-plugins to see what library you need.
 Make sure to remember to re-run configure after installing the supporting
 library !
-</listitem>
-<listitem>
+</para></listitem>
+<listitem><para>
 if you run GStreamer from CVS, the same logic applies as for a source install.
 Go over the reasons why the plug-in didn't get configured for build.
 Check output of config.log for a clue as to why it doesn't get built if
 you're sure you have the library needed installed in a sane place.
-</listitem>
+</para></listitem>
 </itemizedlist>
 
         </para>
@@ -87,31 +87,31 @@ The second thing you can do is look at the backtrace to get an idea of where
 things are going wrong, or give us an idea of what is going wrong.
 To provide a backtrace, you should
 <orderedlist>
-<listitem>
+<listitem><para>
   run the application in gdb by starting it with
   <programlisting>
     gdb (gst-application)
   </programlisting>
   (If the application is in a source tree instead of installed on the system,
   you might want to put "libtool" before "gdb")
-</listitem>
-<listitem>
+</para></listitem>
+<listitem><para>
   Pass on the command line arguments to the application by typing
   <programlisting>
     set args (the arguments to the application)
   </programlisting>
   at the (gdb) prompt
-</listitem>
-<listitem>
+</para></listitem>
+<listitem><para>
   Type "run" at the (gdb) prompt and wait for the application to
   segfault.  The application will run a lot slower, however.
-</listitem>
-<listitem>
+</para></listitem>
+<listitem><para>
   After the segfault, type "bt" to get a backtrace.  This is a stack of
   function calls detailing the path from main () to where the code is
   currently at.
-</listitem>
-<listitem>
+</para></listitem>
+<listitem><para>
   If the application you're trying to debug contains threads, it is also
   useful to do
   <programlisting>
@@ -120,14 +120,12 @@ To provide a backtrace, you should
   and get backtraces of all of the threads involved, by switching to
   a different thread using "thread (number)" and then again requesting
   a backtrace using "bt".
-</listitem>
-<listitem>
-  <para>
+</para></listitem>
+<listitem><para>
   If you can't or don't want to work out the problem yourself, a copy and paste
   of all this information should be included in your 
   <link linkend="using-bugs-where">bug report</link>.
-  </para>
-</listitem>
+</para></listitem>
 </orderedlist>
         </para>
       </answer>

diff --git a/docs/faq/using.xml b/docs/faq/using.xml
index b04971e..7abb18c 100644 (file)
--- a/docs/faq/using.xml
+++ b/docs/faq/using.xml
@@ -56,11 +56,11 @@ You can test this by trying to play a sine tone.  For this, you need to
 connect the sinesrc plug-in to an output plug-in that matches your hardware.
 A (non-complete) list of output plug-ins for audio is
 <itemizedlist>
-<listitem>osssink for OSS output</listitem>
-<listitem>esdsink for ESound output</listitem>
-<listitem>artssink for aRTs output</listitem>
-<listitem>alsasink for ALSA output</listitem>
-<listitem>jacksink for JACK output</listitem>
+<listitem><para>osssink for OSS output</para></listitem>
+<listitem><para>esdsink for ESound output</para></listitem>
+<listitem><para>artssink for aRTs output</para></listitem>
+<listitem><para>alsasink for ALSA output</para></listitem>
+<listitem><para>jacksink for JACK output</para></listitem>
 </itemizedlist>
 First of all, run gst-inspect on the output plug-in you want to use to
 make sure you have it installed.  For example, if you use OSS, run
@@ -136,10 +136,10 @@ information, as we will most likely have to.
         <para>
 When doing a bug report, you should at least describe
 <itemizedlist>
-<listitem>your distribution</listitem>
-<listitem>
-how you installed GStreamer (from cvs, source, packages, which ?)</listitem>
-<listitem>if you installed GStreamer before</listitem>
+<listitem><para>your distribution</para></listitem>
+<listitem><para>
+how you installed GStreamer (from cvs, source, packages, which ?)</para></listitem>
+<listitem><para>if you installed GStreamer before</para></listitem>
 </itemizedlist>
         </para>
         <para>