[Lxml-checkins] r42888 - lxml/trunk/doc

[scoder at codespeak.net]

Author: scoder
Date: Wed May  9 00:39:36 2007
New Revision: 42888

Modified:
   lxml/trunk/doc/FAQ.txt
   lxml/trunk/doc/objectify.txt
   lxml/trunk/doc/performance.txt
Log:
annotations and links

Modified: lxml/trunk/doc/FAQ.txt
==============================================================================
--- lxml/trunk/doc/FAQ.txt	(original)
+++ lxml/trunk/doc/FAQ.txt	Wed May  9 00:39:36 2007
@@ -2,6 +2,11 @@
 Frequently Asked Questions (FAQ)
 ================================
 
+.. meta::
+  :description: Frequently Asked Questions about lxml (FAQ)
+  :keywords: lxml, lxml.etree, FAQ, frequently asked questions
+
+
 See also the notes on compatibility_ to ElementTree_.
 
 .. _compatibility: compatibility.html

Modified: lxml/trunk/doc/objectify.txt
==============================================================================
--- lxml/trunk/doc/objectify.txt	(original)
+++ lxml/trunk/doc/objectify.txt	Wed May  9 00:39:36 2007
@@ -2,6 +2,9 @@
 lxml.objectify
 ==============
 
+:Author:
+  Stefan Behnel
+
 lxml supports an alternative API similar to the Amara_ bindery or
 gnosis.xml.objectify_ through a custom Element implementation.  The main idea
 is to hide the usage of XML behind normal Python objects, sometimes referred

Modified: lxml/trunk/doc/performance.txt
==============================================================================
--- lxml/trunk/doc/performance.txt	(original)
+++ lxml/trunk/doc/performance.txt	Wed May  9 00:39:36 2007
@@ -2,6 +2,14 @@
 Benchmarks and Speed
 ====================
 
+:Author:
+  Stefan Behnel
+
+.. meta::
+  :description: Performance evaluation of lxml and ElementTree 
+  :keywords: lxml performance, lxml.etree, lxml.objectify, benchmarks, ElementTree
+
+
 As an XML library, lxml.etree is very fast.  It is also slow.  As with all
 software, it depends on what you do with it.  Rest assured that lxml is fast
 enough for most applications, so lxml is probably somewhere between 'fast
@@ -410,16 +418,17 @@
 A bigger example
 ================
 
-A while ago, Uche Ogbuji posted a benchmark proposal at `xml.org`_ that would
-read in a 3 MB XML version of the Old Testament of the Bible and look for the
-text "begat" in all verses.  Apparently, it is contained in 120 of them.  This
-is easy to implement in ElementTree using ``findall()``.  However, the fastest
+A while ago, Uche Ogbuji posted a `benchmark proposal`_ that would read in a
+3MB XML version of the `Old Testament`_ of the Bible and look for the word
+*begat* in all verses.  Apparently, it is contained in 120 of them.  This is
+easy to implement in ElementTree using ``findall()``.  However, the fastest
 way to do this is obviously ``iterparse()``, as most of the data is not of any
 interest.
 
-.. _`xml.org`: http://xml.org/...
+.. _`benchmark proposal`: http://www.onlamp.com/pub/wlg/6291
+.. _`Old Testament`: http://www.ibiblio.org/bosak/xml/eg/religion.2.00.xml.zip
 
-Now, Uche's original proposal was::
+Now, Uche's original proposal was more or less the following::
 
   def bench_ET():
       tree = ElementTree.parse("ot.xml")