From a7e9d3f37d5e9fba4b9acaa43e7c12b6d9a669ae Mon Sep 17 00:00:00 2001 From: Mike Hommey Date: Thu, 8 Jun 2006 10:59:26 +0200 Subject: Load /tmp/libxml2-2.6.26 into libxml2/branches/upstream/current. --- doc/interface.html | 35 +++++++++++++++++------------------ 1 file changed, 17 insertions(+), 18 deletions(-) (limited to 'doc/interface.html') diff --git a/doc/interface.html b/doc/interface.html index 8163c41..88ec0d8 100644 --- a/doc/interface.html +++ b/doc/interface.html @@ -7,19 +7,18 @@ H1 {font-family: Verdana,Arial,Helvetica} H2 {font-family: Verdana,Arial,Helvetica} H3 {font-family: Verdana,Arial,Helvetica} A:link, A:visited, A:active { text-decoration: underline } -The SAX interface
Action against software patentsGnome2 LogoW3C LogoRed Hat Logo
Made with Libxml2 Logo

The XML C parser and toolkit of Gnome

The SAX interface

Developer Menu
API Indexes
Related links

Sometimes the DOM tree output is just too large to fit reasonably into -memory. In that case (and if you don't expect to save back the XML document -loaded using libxml), it's better to use the SAX interface of libxml. SAX is -a callback-based interface to the parser. Before parsing, -the application layer registers a customized set of callbacks which are -called by the library as it progresses through the XML input.

To get more detailed step-by-step guidance on using the SAX interface of -libxml, see the nice -documentation.written by James -Henstridge.

You can debug the SAX behaviour by using the testSAX -program located in the gnome-xml module (it's usually not shipped in the -binary packages of libxml, but you can find it in the tar source -distribution). Here is the sequence of callbacks that would be reported by -testSAX when parsing the example XML document shown earlier:

SAX.setDocumentLocator()
+The SAX interface
Action against software patentsGnome2 LogoW3C LogoRed Hat Logo
Made with Libxml2 Logo
The XML C parser and toolkit of Gnome
The SAX interface
Developer Menu
API Indexes
Related links
Sometimes the DOM tree output is just too large to fit
+reasonablyintomemory. In that case (and if you don't expect to save back the
+XMLdocumentloaded using libxml), it's better to use the SAX interface of
+libxml.SAX isa callback-based interfaceto the parser.
+Beforeparsing,the application layer registers a customized set of callbacks
+whicharecalled by the library as it progresses through the XML input.
To get more detailed step-by-step guidance on using the SAX
+interfaceoflibxml, see the nicedocumentation.writtenby
+JamesHenstridge.
You can debug the SAX behaviour by using
+thetestSAXprogram located in the gnome-xml module (it's
+usuallynot shipped in thebinary packages of libxml, but you can find it in
+the tarsourcedistribution). Here is the sequence of callbacks that would be
+reportedbytestSAX when parsing the example XML document shown earlier:
SAX.setDocumentLocator()
 SAX.startDocument()
 SAX.getEntity(amp)
 SAX.startElement(EXAMPLE, prop1='gnome is great', prop2='& linux too')
@@ -52,8 +51,8 @@ SAX.characters(   , 3)
 SAX.endElement(chapter)
 SAX.characters( , 1)
 SAX.endElement(EXAMPLE)
-SAX.endDocument()
Most of the other interfaces of libxml2 are based on the DOM tree-building
-facility, so nearly everything up to the end of this document presupposes the
-use of the standard DOM tree build. Note that the DOM tree itself is built by
-a set of registered default callbacks, without internal specific
-interface.
Daniel Veillard

+SAX.endDocument()

Most of the other interfaces of libxml2 are based on the +DOMtree-buildingfacility, so nearly everything up to the end of this +documentpresupposes theuse of the standard DOM tree build. Note that the DOM +treeitself is built bya set of registered default callbacks, without +internalspecificinterface.

Daniel Veillard

-- cgit v1.2.3