mirror of
https://gitlab.gnome.org/GNOME/libxml2.git
synced 2025-01-28 17:47:00 +03:00
1053 lines
42 KiB
HTML
1053 lines
42 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
|
|
"http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<title>The XML library for Gnome</title>
|
|
<meta name="GENERATOR" content="amaya V2.4">
|
|
<meta http-equiv="Content-Type" content="text/html">
|
|
</head>
|
|
|
|
<body bgcolor="#ffffff">
|
|
<h1 align="center">The XML library for Gnome</h1>
|
|
|
|
<h2 style="text-align: center">libxml, a.k.a. gnome-xml</h2>
|
|
|
|
<p></p>
|
|
<ul>
|
|
<li><a href="#Introducti">Introduction</a></li>
|
|
<li><a href="#Documentat">Documentation</a></li>
|
|
<li><a href="#Downloads">Downloads</a></li>
|
|
<li><a href="#News">News</a></li>
|
|
<li><a href="#XML">XML</a></li>
|
|
<li><a href="#tree">The tree output</a></li>
|
|
<li><a href="#interface">The SAX interface</a></li>
|
|
<li><a href="#library">The XML library interfaces</a>
|
|
<ul>
|
|
<li><a href="#Invoking">Invoking the parser: the pull way</a></li>
|
|
<li><a href="#Invoking">Invoking the parser: the push way</a></li>
|
|
<li><a href="#Invoking2">Invoking the parser: the SAX interface</a></li>
|
|
<li><a href="#Building">Building a tree from scratch</a></li>
|
|
<li><a href="#Traversing">Traversing the tree</a></li>
|
|
<li><a href="#Modifying">Modifying the tree</a></li>
|
|
<li><a href="#Saving">Saving the tree</a></li>
|
|
<li><a href="#Compressio">Compression</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#Entities">Entities or no entities</a></li>
|
|
<li><a href="#Namespaces">Namespaces</a></li>
|
|
<li><a href="#Validation">Validation</a></li>
|
|
<li><a href="#Principles">DOM principles</a></li>
|
|
<li><a href="#real">A real example</a></li>
|
|
</ul>
|
|
|
|
<h2><a name="Introducti">Introduction</a></h2>
|
|
|
|
<p>This document describes libxml, the <a href="http://www.w3.org/XML/">XML</a>
|
|
library provided in the <a href="http://www.gnome.org/">Gnome</a> framework.
|
|
XML is a standard for building tag-based structured documents/data.</p>
|
|
|
|
<p>Here are some key points about libxml:</p>
|
|
<ul>
|
|
<li>The internal document repesentation is as close as possible to the <a
|
|
href="http://www.w3.org/DOM/">DOM</a> interfaces.</li>
|
|
<li>Libxml also has a <a href="http://www.megginson.com/SAX/index.html">SAX
|
|
like interface</a>; the interface is designed to be compatible with <a
|
|
href="http://www.jclark.com/xml/expat.html">Expat</a>.</li>
|
|
<li>Libxml now includes a nearly complete <a
|
|
href="http://www.w3.org/TR/xpath">XPath</a> implementation.</li>
|
|
<li>Libxml exports Push and Pull type parser interfaces for both XML and
|
|
HTML.</li>
|
|
<li>This library is released both under the W3C Copyright and the GNU LGPL.
|
|
Basically, everybody should be happy; if not, drop me a mail.</li>
|
|
</ul>
|
|
|
|
<h2><a name="Documentat">Documentation</a></h2>
|
|
|
|
<p>There are some on-line resources about using libxml:</p>
|
|
<ol>
|
|
<li>The code is commented in a way which allows <a
|
|
href="http://xmlsoft.org/libxml.html">extensive documentation</a> to be
|
|
automatically extracted.</li>
|
|
<li>This page provides a global overview and <a href="#real">some
|
|
examples</a> on how to use libxml.</li>
|
|
<li><a href="mailto:james@daa.com.au">James Henstridge</a> wrote <a
|
|
href="http://www.daa.com.au/~james/gnome/xml-sax/xml-sax.html">some nice
|
|
documentation</a> explaining how to use the libxml SAX interface.</li>
|
|
<li>George Lebl wrote <a
|
|
href="http://www-4.ibm.com/software/developer/library/gnome3/">an article
|
|
for IBM developerWorks</a> about using libxml.</li>
|
|
<li>It is also a good idea to check to <a href="mailto:raph@levien.com">Raph
|
|
Levien</a> <a href="http://levien.com/gnome/">web site</a> since he is
|
|
building the <a href="http://levien.com/gnome/gdome.html">DOM interface
|
|
gdome</a> on top of libxml result tree and an implementation of <a
|
|
href="http://www.w3.org/Graphics/SVG/">SVG</a> called <a
|
|
href="http://www.levien.com/svg/">gill</a>. Check his <a
|
|
href="http://www.levien.com/gnome/domination.html">DOMination
|
|
paper</a>.</li>
|
|
<li>And don't forget to look at the <a href="/messages/">mailing-list
|
|
archive</a>, too.</li>
|
|
</ol>
|
|
|
|
<h3>Reporting bugs and getting help</h3>
|
|
|
|
<p>Well, bugs or missing features are always possible, and I will make a point
|
|
of fixing them in a timely fashion. The best way to report a bug is to <a
|
|
href="http://bugs.gnome.org/db/pa/lgnome-xml.html">use the Gnome bug tracking
|
|
database</a>. I look at reports there regularly and it's good to have a
|
|
reminder when a bug is still open. Check the <a
|
|
href="http://bugs.gnome.org/Reporting.html">instructions on reporting bugs</a>
|
|
and be sure to specify that the bug is for the package gnome-xml.</p>
|
|
|
|
<p>There is also a mailing-list <a
|
|
href="mailto:xml@rufus.w3.org">xml@rufus.w3.org</a> for libxml, with an <a
|
|
href="http://xmlsoft.org/messages">on-line archive</a>. To subscribe to this
|
|
majordomo based list, send a mail message to <a
|
|
href="mailto:majordomo@rufus.w3.org">majordomo@rufus.w3.org</a> with
|
|
"subscribe xml" in the <strong>content</strong> of the message.</p>
|
|
|
|
<p>Alternatively, you can just send the bug to the <a
|
|
href="mailto:xml@rufus.w3.org">xml@rufus.w3.org</a> list.</p>
|
|
|
|
<h2><a name="Downloads">Downloads</a></h2>
|
|
|
|
<p>The latest versions of libxml can be found on <a
|
|
href="ftp://rpmfind.net/pub/libxml/">rpmfind.net</a> or on the <a
|
|
href="ftp://ftp.gnome.org/pub/GNOME/MIRRORS.html">Gnome FTP server</a> either
|
|
as a <a href="ftp://ftp.gnome.org/pub/GNOME/stable/sources/libxml/">source
|
|
archive</a> or <a href="ftp://ftp.gnome.org/pub/GNOME/contrib/rpms/">RPMs
|
|
packages</a>. (NOTE that you need both the <a
|
|
href="http://rpmfind.net/linux/RPM/libxml.html">libxml</a> and <a
|
|
href="http://rpmfind.net/linux/RPM/libxml-devel.html">libxml-devel</a>
|
|
packages installed to compile applications using libxml.)</p>
|
|
|
|
<p><a name="Snapshot">Snapshot:</a></p>
|
|
<ul>
|
|
<li>Code from the W3C cvs base libxml <a
|
|
href="ftp://rpmfind.net/pub/libxml/cvs-snapshot.tar.gz">cvs-snapshot.tar.gz</a></li>
|
|
<li>Docs, content of the web site, the list archive included <a
|
|
href="ftp://rpmfind.net/pub/libxml/libxml-docs.tar.gz">libxml-docs.tar.gz</a></li>
|
|
</ul>
|
|
|
|
<p><a name="Contribs">Contribs:</a></p>
|
|
|
|
<p>I do accept external contributions, especially if compiling on another
|
|
platform, get in touch with me to upload the package. I will keep them in the
|
|
<a href="ftp://rpmfind.net/pub/libxml/contribs/">contrib directory</a></p>
|
|
|
|
<p>Libxml is also available from 2 CVs bases:</p>
|
|
<ul>
|
|
<li><p>The <a href="http://dev.w3.org/cvsweb/XML/">W3C CVS base</a>,
|
|
available read-only using the CVS pserver authentification (I tend to use
|
|
this base for my own development, so it's updated more regularly, but
|
|
the content may not be as stable):</p>
|
|
<pre>CVSROOT=:pserver:anonymous@dev.w3.org:/sources/public
|
|
password: anonymous
|
|
module: XML</pre>
|
|
</li>
|
|
<li><p>The <a
|
|
href="http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=gnome-xml">Gnome
|
|
CVS base</a>. Check the <a
|
|
href="http://developer.gnome.org/tools/cvs.html">Gnome CVS Tools</a> page;
|
|
the CVS module is <b>gnome-xml</b>.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h2><a name="News">News</a></h2>
|
|
|
|
<h3>CVS only : check the <a
|
|
href="http://cvs.gnome.org/lxr/source/gnome-xml/ChangeLog">Changelog</a> file
|
|
for really accurate description</h3>
|
|
<ul>
|
|
<li>working on HTML and XML links recognition layers, get in touch with me
|
|
if you want to test those.</li>
|
|
<li>huge work toward libxml-2.0: This work is available only in W3C CVs base
|
|
for the moment. You get the <a
|
|
href="ftp://rpmfind.net/pub/libxml/cvs-snapshot.tar.gz">snapshot</a> for
|
|
the updated version:
|
|
<ul>
|
|
<li>fix I18N support. ISO-Latin-x/UTF-8/UTF-16 seems correctly handled
|
|
now</li>
|
|
<li>Better handling of entities</li>
|
|
<li>DTD conditional sections</li>
|
|
<li><a href="http://rpmfind.net/tools/gdome/messages/0039.html">change
|
|
structures to accomodate DOM</a></li>
|
|
<li>Lot of work toward a better compliance. I'm now running and
|
|
debugging regression tests agains the <a
|
|
href="http://www.oasis-open.org/committees/xmlconf-pub.html">OASIS
|
|
testsuite</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<h3>1.8.6: Jan 31 2000</h3>
|
|
<ul>
|
|
<li>added a nanoFTP transport module, debugged until the new version of <a
|
|
href="http://rpmfind.net/linux/rpm2html/rpmfind.html">rpmfind</a> can use
|
|
it without troubles</li>
|
|
</ul>
|
|
|
|
<h3>1.8.5: Jan 21 2000</h3>
|
|
<ul>
|
|
<li>adding APIs to parse a well balanced chunk of XML (production <a
|
|
href="http://www.w3.org/TR/REC-xml#NT-content">[43] content</a> of the XML
|
|
spec)</li>
|
|
<li>fixed a hideous bug in xmlGetProp pointed by Rune.Djurhuus@fast.no</li>
|
|
<li>Jody Goldberg <jgoldberg@home.com> provided another patch trying to
|
|
solve the zlib checks problems</li>
|
|
<li>The current state in gnome CVS base is expected to ship as 1.8.5 with
|
|
gnumeric soon</li>
|
|
</ul>
|
|
|
|
<h3>1.8.4: Jan 13 2000</h3>
|
|
<ul>
|
|
<li>bug fixes, reintroduced xmlNewGlobalNs(), fixed xmlNewNs()</li>
|
|
<li>all exit() call should have been removed from libxml</li>
|
|
<li>fixed a problem with INCLUDE_WINSOCK on WIN32 platform</li>
|
|
<li>added newDocFragment()</li>
|
|
</ul>
|
|
|
|
<h3>1.8.3: Jan 5 2000</h3>
|
|
<ul>
|
|
<li>a Push interface for the XML and HTML parsers</li>
|
|
<li>a shell-like interface to the document tree (try tester --shell
|
|
:-)</li>
|
|
<li>lots of bug fixes and improvement added over XMas hollidays</li>
|
|
<li>fixed the DTD parsing code to work with the xhtml DTD</li>
|
|
<li>added xmlRemoveProp(), xmlRemoveID() and xmlRemoveRef()</li>
|
|
<li>Fixed bugs in xmlNewNs()</li>
|
|
<li>External entity loading code has been revamped, now it uses
|
|
xmlLoadExternalEntity(), some fix on entities processing were added</li>
|
|
<li>cleaned up WIN32 includes of socket stuff</li>
|
|
</ul>
|
|
|
|
<h3>1.8.2: Dec 21 1999</h3>
|
|
<ul>
|
|
<li>I got another problem with includes and C++, I hope this issue is fixed
|
|
for good this time</li>
|
|
<li>Added a few tree modification functions: xmlReplaceNode,
|
|
xmlAddPrevSibling, xmlAddNextSibling, xmlNodeSetName and
|
|
xmlDocSetRootElement</li>
|
|
<li>Tried to improve the HTML output with help from <a
|
|
href="mailto:clahey@umich.edu">Chris Lahey</a></li>
|
|
</ul>
|
|
|
|
<h3>1.8.1: Dec 18 1999</h3>
|
|
<ul>
|
|
<li>various patches to avoid troubles when using libxml with C++ compilers
|
|
the "namespace" keyword and C escaping in include files</li>
|
|
<li>a problem in one of the core macros IS_CHAR was corrected</li>
|
|
<li>fixed a bug introduced in 1.8.0 breaking default namespace processing,
|
|
and more specifically the Dia application</li>
|
|
<li>fixed a posteriori validation (validation after parsing, or by using a
|
|
Dtd not specified in the original document)</li>
|
|
<li>fixed a bug in</li>
|
|
</ul>
|
|
|
|
<h3>1.8.0: Dec 12 1999</h3>
|
|
<ul>
|
|
<li>cleanup, especially memory wise</li>
|
|
<li>the parser should be more reliable, especially the HTML one, it should
|
|
not crash, whatever the input !</li>
|
|
<li>Integrated various patches, especially a speedup improvement for large
|
|
dataset from <a href="mailto:cnygard@bellatlantic.net">Carl Nygard</a>,
|
|
configure with --with-buffers to enable them.</li>
|
|
<li>attribute normalization, oops should have been added long ago !</li>
|
|
<li>attributes defaulted from Dtds should be available, xmlSetProp() now
|
|
does entities escapting by default.</li>
|
|
</ul>
|
|
|
|
<h3>1.7.4: Oct 25 1999</h3>
|
|
<ul>
|
|
<li>Lots of HTML improvement</li>
|
|
<li>Fixed some errors when saving both XML and HTML</li>
|
|
<li>More examples, the regression tests should now look clean</li>
|
|
<li>Fixed a bug with contiguous charref</li>
|
|
</ul>
|
|
|
|
<h3>1.7.3: Sep 29 1999</h3>
|
|
<ul>
|
|
<li>portability problems fixed</li>
|
|
<li>snprintf was used unconditionnally, leading to link problems on system
|
|
were it's not available, fixed</li>
|
|
</ul>
|
|
|
|
<h3>1.7.1: Sep 24 1999</h3>
|
|
<ul>
|
|
<li>The basic type for strings manipulated by libxml has been renamed in
|
|
1.7.1 from <strong>CHAR</strong> to <strong>xmlChar</strong>. The reason
|
|
is that CHAR was conflicting with a predefined type on Windows. However on
|
|
non WIN32 environment, compatibility is provided by the way of a
|
|
<strong>#define </strong>.</li>
|
|
<li>Changed another error : the use of a structure field called errno, and
|
|
leading to troubles on platforms where it's a macro</li>
|
|
</ul>
|
|
|
|
<h3>1.7.0: sep 23 1999</h3>
|
|
<ul>
|
|
<li>Added the ability to fetch remote DTD or parsed entities, see the <a
|
|
href="gnome-xml-nanohttp.html">nanohttp</a> module.</li>
|
|
<li>Added an errno to report errors by another mean than a simple printf
|
|
like callback</li>
|
|
<li>Finished ID/IDREF support and checking when validation</li>
|
|
<li>Serious memory leaks fixed (there is now a <a
|
|
href="gnome-xml-xmlmemory.html">memory wrapper</a> module)</li>
|
|
<li>Improvement of <a href="http://www.w3.org/TR/xpath">XPath</a>
|
|
implementation</li>
|
|
<li>Added an HTML parser front-end</li>
|
|
</ul>
|
|
|
|
<h2><a name="XML">XML</a></h2>
|
|
|
|
<p><a href="http://www.w3.org/TR/REC-xml">XML is a standard</a> for
|
|
markup-based structured documents. Here is <a name="example">an example
|
|
XML document</a>:</p>
|
|
<pre><?xml version="1.0"?>
|
|
<EXAMPLE prop1="gnome is great" prop2="&amp; linux too">
|
|
<head>
|
|
<title>Welcome to Gnome</title>
|
|
</head>
|
|
<chapter>
|
|
<title>The Linux adventure</title>
|
|
<p>bla bla bla ...</p>
|
|
<image href="linus.gif"/>
|
|
<p>...</p>
|
|
</chapter>
|
|
</EXAMPLE></pre>
|
|
|
|
<p>The first line specifies that it's an XML document and gives useful
|
|
information about its encoding. Then the document is a text format whose
|
|
structure is specified by tags between brackets. <strong>Each tag opened has
|
|
to be closed</strong>. XML is pedantic about this. However, if a tag is
|
|
empty (no content), a single tag can serve as both the opening and closing
|
|
tag if it ends with <code>/></code> rather than with <code>></code>.
|
|
Note that, for example, the
|
|
image tag has no content (just an attribute) and is closed by ending the
|
|
tag with <code>/></code>.</p>
|
|
|
|
<p>XML can be applied sucessfully to a wide range of uses, from long term
|
|
structured document maintenance (where it follows the steps of SGML) to simple
|
|
data encoding mechanisms like configuration file formatting (glade), spreadsheets
|
|
(gnumeric), or even shorter lived documents such as WebDAV where it is used to
|
|
encode remote calls between a client and a server.</p>
|
|
|
|
<h2><a name="tree">The tree output</a></h2>
|
|
|
|
<p>The parser returns a tree built during the document analysis. The value
|
|
returned is an <strong>xmlDocPtr</strong> (i.e., a pointer to an
|
|
<strong>xmlDoc</strong> structure). This structure contains information such as
|
|
the file name, the document type, and a <strong>root</strong> pointer which
|
|
is the root of the document (or more exactly the first child under the root
|
|
which is the document). The tree is made of <strong>xmlNode</strong>s, chained
|
|
in double-linked lists of siblings and with childs<->parent relationship.
|
|
An xmlNode can also carry properties (a chain of xmlAttr structures). An
|
|
attribute may have a value which is a list of TEXT or ENTITY_REF nodes.</p>
|
|
|
|
<p>Here is an example (erroneous with respect to the XML spec since there
|
|
should be only one ELEMENT under the root):</p>
|
|
|
|
<p><img src="structure.gif" alt=" structure.gif "></p>
|
|
|
|
<p>In the source package there is a small program (not installed by default)
|
|
called <strong>tester</strong> which parses XML files given as argument and
|
|
prints them back as parsed. This is useful for detecting errors both in XML code
|
|
and in the XML parser itself. It has an option <strong>--debug</strong> which
|
|
prints the actual in-memory structure of the document, here is the result with
|
|
the <a href="#example">example</a> given before:</p>
|
|
<pre>DOCUMENT
|
|
version=1.0
|
|
standalone=true
|
|
ELEMENT EXAMPLE
|
|
ATTRIBUTE prop1
|
|
TEXT
|
|
content=gnome is great
|
|
ATTRIBUTE prop2
|
|
ENTITY_REF
|
|
TEXT
|
|
content= linux too
|
|
ELEMENT head
|
|
ELEMENT title
|
|
TEXT
|
|
content=Welcome to Gnome
|
|
ELEMENT chapter
|
|
ELEMENT title
|
|
TEXT
|
|
content=The Linux adventure
|
|
ELEMENT p
|
|
TEXT
|
|
content=bla bla bla ...
|
|
ELEMENT image
|
|
ATTRIBUTE href
|
|
TEXT
|
|
content=linus.gif
|
|
ELEMENT p
|
|
TEXT
|
|
content=...</pre>
|
|
|
|
<p>This should be useful for learning the internal representation model.</p>
|
|
|
|
<h2><a name="interface">The SAX interface</a></h2>
|
|
|
|
<p>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
|
|
<strong>callback-based interface</strong> 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.</p>
|
|
|
|
<p>To get more detailed step-by-step guidance on using the SAX interface of
|
|
libxml, see the
|
|
href="http://www.daa.com.au/~james/gnome/xml-sax/xml-sax.html">nice
|
|
documentation.</a> written by <a href="mailto:james@daa.com.au">James
|
|
Henstridge</a>.</p>
|
|
|
|
<p>You can debug the SAX behaviour by using the <strong>testSAX</strong>
|
|
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:</p>
|
|
<pre>SAX.setDocumentLocator()
|
|
SAX.startDocument()
|
|
SAX.getEntity(amp)
|
|
SAX.startElement(EXAMPLE, prop1='gnome is great', prop2='&amp; linux too')
|
|
SAX.characters( , 3)
|
|
SAX.startElement(head)
|
|
SAX.characters( , 4)
|
|
SAX.startElement(title)
|
|
SAX.characters(Welcome to Gnome, 16)
|
|
SAX.endElement(title)
|
|
SAX.characters( , 3)
|
|
SAX.endElement(head)
|
|
SAX.characters( , 3)
|
|
SAX.startElement(chapter)
|
|
SAX.characters( , 4)
|
|
SAX.startElement(title)
|
|
SAX.characters(The Linux adventure, 19)
|
|
SAX.endElement(title)
|
|
SAX.characters( , 4)
|
|
SAX.startElement(p)
|
|
SAX.characters(bla bla bla ..., 15)
|
|
SAX.endElement(p)
|
|
SAX.characters( , 4)
|
|
SAX.startElement(image, href='linus.gif')
|
|
SAX.endElement(image)
|
|
SAX.characters( , 4)
|
|
SAX.startElement(p)
|
|
SAX.characters(..., 3)
|
|
SAX.endElement(p)
|
|
SAX.characters( , 3)
|
|
SAX.endElement(chapter)
|
|
SAX.characters( , 1)
|
|
SAX.endElement(EXAMPLE)
|
|
SAX.endDocument()</pre>
|
|
|
|
<p>Most of the other functionalities of libxml 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.</p>
|
|
|
|
<h2><a name="library">The XML library interfaces</a></h2>
|
|
|
|
<p>This section is directly intended to help programmers getting bootstrapped
|
|
using the XML library from the C language. It is not intended to be extensive.
|
|
I hope the automatically generated documents will provide the completeness
|
|
required, but as a separate set of documents. The interfaces of the XML
|
|
library are by principle low level, there is nearly zero abstraction. Those
|
|
interested in a higher level API should <a href="#DOM">look at DOM</a>.</p>
|
|
|
|
<p>The <a href="gnome-xml-parser.html">parser interfaces for XML</a> are
|
|
separated from the <a href="gnome-xml-htmlparser.html">HTML parser
|
|
interfaces</a>. Let's have a look at how the XML parser can be called:</p>
|
|
|
|
<h3><a name="Invoking">Invoking the parser : the pull method</a></h3>
|
|
|
|
<p>Usually, the first thing to do is to read an XML input. The parser accepts
|
|
documents either from in-memory strings or from files. The functions are
|
|
defined in "parser.h":</p>
|
|
<dl>
|
|
<dt><code>xmlDocPtr xmlParseMemory(char *buffer, int size);</code></dt>
|
|
<dd><p>Parse a null-terminated string containing the document.</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>xmlDocPtr xmlParseFile(const char *filename);</code></dt>
|
|
<dd><p>Parse an XML document contained in a (possibly compressed) file.</p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<p>The parser returns a pointer to the document structure (or NULL in case of
|
|
failure).</p>
|
|
|
|
<h3 id="Invoking1">Invoking the parser: the push method</h3>
|
|
|
|
<p>In order for the application to keep the control when the document is been
|
|
fetched (which is common for GUI based programs) libxml provides a push
|
|
interface, too, as of version 1.8.3. Here are the interface functions:</p>
|
|
<pre>xmlParserCtxtPtr xmlCreatePushParserCtxt(xmlSAXHandlerPtr sax,
|
|
void *user_data,
|
|
const char *chunk,
|
|
int size,
|
|
const char *filename);
|
|
int xmlParseChunk (xmlParserCtxtPtr ctxt,
|
|
const char *chunk,
|
|
int size,
|
|
int terminate);</pre>
|
|
|
|
<p>and here is a simple example showing how to use the interface:</p>
|
|
<pre> FILE *f;
|
|
|
|
f = fopen(filename, "r");
|
|
if (f != NULL) {
|
|
int res, size = 1024;
|
|
char chars[1024];
|
|
xmlParserCtxtPtr ctxt;
|
|
|
|
res = fread(chars, 1, 4, f);
|
|
if (res > 0) {
|
|
ctxt = xmlCreatePushParserCtxt(NULL, NULL,
|
|
chars, res, filename);
|
|
while ((res = fread(chars, 1, size, f)) > 0) {
|
|
xmlParseChunk(ctxt, chars, res, 0);
|
|
}
|
|
xmlParseChunk(ctxt, chars, 0, 1);
|
|
doc = ctxt->myDoc;
|
|
xmlFreeParserCtxt(ctxt);
|
|
}
|
|
}</pre>
|
|
|
|
<p>Also note that the HTML parser embedded into libxml also has a push
|
|
interface; the functions are just prefixed by "html" rather than "xml"</p>
|
|
|
|
<h3 id="Invoking2">Invoking the parser: the SAX interface</h3>
|
|
|
|
<p>A couple of comments can be made, first this mean that the parser is
|
|
memory-hungry, first to load the document in memory, second to build the tree.
|
|
Reading a document without building the tree is possible using the SAX
|
|
interfaces (see SAX.h and <a
|
|
href="http://www.daa.com.au/~james/gnome/xml-sax/xml-sax.html">James
|
|
Henstridge's documentation</a>). Note also that the push interface can be
|
|
limited to SAX. Just use the two first arguments of
|
|
<code>xmlCreatePushParserCtxt()</code>.</p>
|
|
|
|
<h3><a name="Building">Building a tree from scratch</a></h3>
|
|
|
|
<p>The other way to get an XML tree in memory is by building it. Basically
|
|
there is a set of functions dedicated to building new elements. (These are also
|
|
described in "tree.h".) For example, here is a piece of code that produces the
|
|
XML document used in the previous examples:</p>
|
|
<pre> xmlDocPtr doc;
|
|
xmlNodePtr tree, subtree;
|
|
|
|
doc = xmlNewDoc("1.0");
|
|
doc->root = xmlNewDocNode(doc, NULL, "EXAMPLE", NULL);
|
|
xmlSetProp(doc->root, "prop1", "gnome is great");
|
|
xmlSetProp(doc->root, "prop2", "& linux too");
|
|
tree = xmlNewChild(doc->root, NULL, "head", NULL);
|
|
subtree = xmlNewChild(tree, NULL, "title", "Welcome to Gnome");
|
|
tree = xmlNewChild(doc->root, NULL, "chapter", NULL);
|
|
subtree = xmlNewChild(tree, NULL, "title", "The Linux adventure");
|
|
subtree = xmlNewChild(tree, NULL, "p", "bla bla bla ...");
|
|
subtree = xmlNewChild(tree, NULL, "image", NULL);
|
|
xmlSetProp(subtree, "href", "linus.gif");</pre>
|
|
|
|
<p>Not really rocket science ...</p>
|
|
|
|
<h3><a name="Traversing">Traversing the tree</a></h3>
|
|
|
|
<p>Basically by <a href="gnome-xml-tree.html">including "tree.h"</a> your code
|
|
has access to the internal structure of all the elements of the tree. The names
|
|
should be somewhat simple like <strong>parent</strong>,
|
|
<strong>childs</strong>, <strong>next</strong>, <strong>prev</strong>,
|
|
<strong>properties</strong>, etc... For example, still with the previous
|
|
example:</p>
|
|
<pre><code>doc->root->childs->childs</code></pre>
|
|
|
|
<p>points to the title element,</p>
|
|
<pre>doc->root->childs->next->child->child</pre>
|
|
|
|
<p>points to the text node containing the chapter title "The Linux adventure".
|
|
</p>
|
|
|
|
<p><strong>NOTE</strong>: XML allows <em>PI</em>s and <em>comments</em> to be
|
|
present before the document root, so <code>doc->root</code> may point to an
|
|
element which is not the document Root Element, a function
|
|
<code>xmlDocGetRootElement()</code> was added for this purpose.</p>
|
|
|
|
<h3><a name="Modifying">Modifying the tree</a></h3>
|
|
|
|
<p>Functions are provided for reading and writing the document content. Here
|
|
is an excerpt from the <a href="gnome-xml-tree.html">tree API</a>:</p>
|
|
<dl>
|
|
<dt><code>xmlAttrPtr xmlSetProp(xmlNodePtr node, const xmlChar *name, const
|
|
xmlChar *value);</code></dt>
|
|
<dd><p>This sets (or changes) an attribute carried by an ELEMENT node. The
|
|
value can be NULL.</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>const xmlChar *xmlGetProp(xmlNodePtr node, const xmlChar
|
|
*name);</code></dt>
|
|
<dd><p>This function returns a pointer to the property content. Note that
|
|
no extra copy is made.</p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<p>Two functions are provided for reading and writing the text associated with
|
|
elements:</p>
|
|
<dl>
|
|
<dt><code>xmlNodePtr xmlStringGetNodeList(xmlDocPtr doc, const xmlChar
|
|
*value);</code></dt>
|
|
<dd><p>This function takes an "external" string and convert it to one text
|
|
node or possibly to a list of entity and text nodes. All non-predefined
|
|
entity references like &Gnome; will be stored internally as
|
|
entity nodes, hence the result of the function may not be a single
|
|
node.</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>xmlChar *xmlNodeListGetString(xmlDocPtr doc, xmlNodePtr list, int
|
|
inLine);</code></dt>
|
|
<dd><p>This function is the inverse of <code>xmlStringGetNodeList()</code>.
|
|
It generates a new string containing
|
|
the content of the text and entity nodes. Note the extra argument
|
|
inLine. If this argument is set to 1, the function will expand entity
|
|
references. For example, instead of returning the &Gnome; XML
|
|
encoding in the string, it will substitute it with its value (say,
|
|
"GNU Network Object Model Environment"). Set this argument if you want
|
|
to use the string for non-XML usage like User Interface.</p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<h3><a name="Saving">Saving a tree</a></h3>
|
|
|
|
<p>Basically 3 options are possible:</p>
|
|
<dl>
|
|
<dt><code>void xmlDocDumpMemory(xmlDocPtr cur, xmlChar**mem, int
|
|
*size);</code></dt>
|
|
<dd><p>Returns a buffer into which the document has been saved.</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>extern void xmlDocDump(FILE *f, xmlDocPtr doc);</code></dt>
|
|
<dd><p>Dumps a document to an open file descriptor.</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>int xmlSaveFile(const char *filename, xmlDocPtr cur);</code></dt>
|
|
<dd><p>Saves the document to a file. In this case, the compression interface
|
|
is triggered if it has been turned on.</p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<h3><a name="Compressio">Compression</a></h3>
|
|
|
|
<p>The library transparently handles compression when doing file-based
|
|
accesses. The level of compression on saves can be turned on either globally or
|
|
individually for one file:</p>
|
|
<dl>
|
|
<dt><code>int xmlGetDocCompressMode (xmlDocPtr doc);</code></dt>
|
|
<dd><p>Gets the document compression ratio (0-9).</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>void xmlSetDocCompressMode (xmlDocPtr doc, int mode);</code></dt>
|
|
<dd><p>Sets the document compression ratio.</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>int xmlGetCompressMode(void);</code></dt>
|
|
<dd><p>Gets the default compression ratio.</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>void xmlSetCompressMode(int mode);</code></dt>
|
|
<dd><p>Sets the default compression ratio.</p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<h2><a name="Entities">Entities or no entities</a></h2>
|
|
|
|
<p>Entities in principle are similar to simple C macros. An entity defines an
|
|
abbreviation for a given string that you can reuse many times throughout the
|
|
content of your document. Entities are especially useful when a given string
|
|
may occur frequently within a document, or to confine the change needed
|
|
to a document to a restricted area in the internal subset of the document (at
|
|
the beginning). Example:</p>
|
|
<pre>1 <?xml version="1.0"?>
|
|
2 <!DOCTYPE EXAMPLE SYSTEM "example.dtd" [
|
|
3 <!ENTITY xml "Extensible Markup Language">
|
|
4 ]>
|
|
5 <EXAMPLE>
|
|
6 &xml;
|
|
7 </EXAMPLE></pre>
|
|
|
|
<p>Line 3 declares the xml entity. Line 6 uses the xml entity, by prefixing
|
|
it's name with '&' and following it by ';' without any spaces added. There
|
|
are 5 predefined entities in libxml allowing you to escape charaters with
|
|
predefined meaning in some parts of the xml document content:
|
|
<strong>&lt;</strong> for the character '<', <strong>&gt;</strong>
|
|
for the character '>', <strong>&apos;</strong> for the character ''',
|
|
<strong>&quot;</strong> for the character '"', and
|
|
<strong>&amp;</strong> for the character '&'.</p>
|
|
|
|
<p>One of the problems related to entities is that you may want the parser to
|
|
substitute an entity's content so that you can see the replacement text in your
|
|
application.
|
|
Or you may prefer to keep entity references as such in the content to be
|
|
able to save the document back without losing this usually precious
|
|
information (if the user went through the pain of explicitly defining
|
|
entities, he may have a a rather negative attitude if you blindly susbtitute
|
|
them as saving time). The <a
|
|
href="gnome-xml-parser.html#XMLSUBSTITUTEENTITIESDEFAULT">xmlSubstituteEntitiesDefault()</a>
|
|
function allows you to check and change the behaviour, which is to not
|
|
substitute entities by default.</p>
|
|
|
|
<p>Here is the DOM tree built by libxml for the previous document in the
|
|
default case:</p>
|
|
<pre>/gnome/src/gnome-xml -> ./tester --debug test/ent1
|
|
DOCUMENT
|
|
version=1.0
|
|
ELEMENT EXAMPLE
|
|
TEXT
|
|
content=
|
|
ENTITY_REF
|
|
INTERNAL_GENERAL_ENTITY xml
|
|
content=Extensible Markup Language
|
|
TEXT
|
|
content=</pre>
|
|
|
|
<p>And here is the result when substituting entities:</p>
|
|
<pre>/gnome/src/gnome-xml -> ./tester --debug --noent test/ent1
|
|
DOCUMENT
|
|
version=1.0
|
|
ELEMENT EXAMPLE
|
|
TEXT
|
|
content= Extensible Markup Language</pre>
|
|
|
|
<p>So, entities or no entities? Basically, it depends on your use case. I
|
|
suggest that you keep the non-substituting default behaviour and avoid using
|
|
entities in your XML document or data if you are not willing to handle the
|
|
entity references elements in the DOM tree.</p>
|
|
|
|
<p>Note that at save time libxml enforce the conversion of the predefined
|
|
entities where necessary to prevent well-formedness problems, and will also
|
|
transparently replace those with chars (i.e., it will not generate entity
|
|
reference elements in the DOM tree or call the reference() SAX callback when
|
|
finding them in the input).</p>
|
|
|
|
<h2><a name="Namespaces">Namespaces</a></h2>
|
|
|
|
<p>The libxml library implements namespace @@ support by recognizing namespace
|
|
contructs in the input, and does namespace lookup automatically when building
|
|
the DOM tree. A namespace declaration is associated with an in-memory
|
|
structure and all elements or attributes within that namespace point to it.
|
|
Hence testing the namespace is a simple and fast equality operation at the
|
|
user level.</p>
|
|
|
|
<p>I suggest that people using libxml use a namespace, and declare it in
|
|
the root element of their document as the default namespace. Then they don't
|
|
need to use the prefix in the content but we will have a basis for future
|
|
semantic refinement and merging of data from different sources. This doesn't
|
|
augment significantly the size of the XML output, but significantly increase
|
|
its value in the long-term.</p>
|
|
|
|
<p>Concerning the namespace value, this has to be an URL, but the URL doesn't
|
|
have to point to any existing resource on the Web. I suggest that it makes
|
|
sense to use an URL within a domain you control, and that the URL
|
|
should contain some kind of version information if possible. For example,
|
|
<code>"http://www.gnome.org/gnumeric/1.0"</code> is a good namespace scheme.
|
|
Then when you load a file, make sure that a namespace carrying the
|
|
version-independent prefix is installed on the root element of your document,
|
|
and if the version information don't match something you know, warn the user
|
|
and be liberal in what you accept as the input. Also do *not* try to base
|
|
namespace checking on the prefix value. <foo:text> may be exactly the same
|
|
as <bar:text> in another document. What really matter is the URI
|
|
associated with the element or the attribute, not the prefix string (which is
|
|
just a shortcut for the full URI).</p>
|
|
|
|
<p>@@Interfaces@@</p>
|
|
|
|
<p>@@Examples@@</p>
|
|
|
|
<p>Usually people object using namespace in the case of validation, I object
|
|
this and will make sure that using namespaces won't break validity checking,
|
|
so even is you plan to use or currently are using validation I strongly suggest
|
|
adding namespaces to your document. A default namespace scheme
|
|
<code>xmlns="http://...."</code> should not break validity even on less
|
|
flexible parsers. Now using namespace to mix and differentiate content coming
|
|
from multiple DTDs will certainly break current validation schemes. I will try
|
|
to provide ways to do this, but this may not be portable or standardized.</p>
|
|
|
|
<h2><a name="Validation">Validation, or are you afraid of DTDs ?</a></h2>
|
|
|
|
<p>Well what is validation and what is a DTD ?</p>
|
|
|
|
<p>Validation is the process of checking a document against a set of
|
|
construction rules, a <strong>DTD</strong> (Document Type Definition) is such
|
|
a set of rules.</p>
|
|
|
|
<p>The validation process and building DTDs are the two most difficult parts
|
|
of XML life cycle. Briefly a DTD defines all the possibles element to be
|
|
found within your document, what is the formal shape of your document tree (by
|
|
defining the allowed content of an element, either text, a regular expression
|
|
for the allowed list of children, or mixed content i.e. both text and childs).
|
|
The DTD also defines the allowed attributes for all elements and the types of
|
|
the attributes. For more detailed informations, I suggest to read the related
|
|
parts of the XML specification, the examples found under
|
|
gnome-xml/test/valid/dtd and the large amount of books available on XML. The
|
|
dia example in gnome-xml/test/valid should be both simple and complete enough
|
|
to allow you to build your own.</p>
|
|
|
|
<p>A word of warning, building a good DTD which will fit your needs of your
|
|
application in the long-term is far from trivial, however the extra level of
|
|
quality it can insure is well worth the price for some sets of applications or
|
|
if you already have already a DTD defined for your application field.</p>
|
|
|
|
<p>The validation is not completely finished but in a (very IMHO) usable
|
|
state. Until a real validation interface is defined the way to do it is to
|
|
define and set the <strong>xmlDoValidityCheckingDefaultValue</strong> external
|
|
variable to 1, this will of course be changed at some point:</p>
|
|
|
|
<p>extern int xmlDoValidityCheckingDefaultValue;</p>
|
|
|
|
<p>...</p>
|
|
|
|
<p>xmlDoValidityCheckingDefaultValue = 1;</p>
|
|
|
|
<p></p>
|
|
|
|
<p>To handle external entities, use the function
|
|
<strong>xmlSetExternalEntityLoader</strong>(xmlExternalEntityLoader f); to
|
|
link in you HTTP/FTP/Entities database library to the standard libxml
|
|
core.</p>
|
|
|
|
<p>@@interfaces@@</p>
|
|
|
|
<h2><a name="DOM"></a><a name="Principles">DOM Principles</a></h2>
|
|
|
|
<p><a href="http://www.w3.org/DOM/">DOM</a> stands for the <em>Document Object
|
|
Model</em> this is an API for accessing XML or HTML structured documents.
|
|
Native support for DOM in Gnome is on the way (module gnome-dom), and it will
|
|
be based on gnome-xml. This will be a far cleaner interface to manipulate XML
|
|
files within Gnome since it won't expose the internal structure. DOM defines a
|
|
set of IDL (or Java) interfaces allowing to traverse and manipulate a
|
|
document. The DOM library will allow accessing and modifying "live" documents
|
|
presents on other programs like this:</p>
|
|
|
|
<p><img src="DOM.gif" alt=" DOM.gif "></p>
|
|
|
|
<p>This should help greatly doing things like modifying a gnumeric spreadsheet
|
|
embedded in a GWP document for example.</p>
|
|
|
|
<p>The current DOM implementation on top of libxml is the <a
|
|
href="http://cvs.gnome.org/lxr/source/gdome/">gdome Gnome module</a>, this is
|
|
a full DOM interface, thanks to <a href="mailto:raph@levien.com">Raph
|
|
Levien</a>.</p>
|
|
|
|
<p>The gnome-dom module in the Gnome CVS base is obsolete</p>
|
|
|
|
<h2><a name="Example"></a><a name="real">A real example</a></h2>
|
|
|
|
<p>Here is a real size example, where the actual content of the application
|
|
data is not kept in the DOM tree but uses internal structures. It is based on
|
|
a proposal to keep a database of jobs related to Gnome, with an XML based
|
|
storage structure. Here is an <a href="gjobs.xml">XML encoded jobs
|
|
base</a>:</p>
|
|
<pre><?xml version="1.0"?>
|
|
<gjob:Helping xmlns:gjob="http://www.gnome.org/some-location">
|
|
<gjob:Jobs>
|
|
|
|
<gjob:Job>
|
|
<gjob:Project ID="3"/>
|
|
<gjob:Application>GBackup</gjob:Application>
|
|
<gjob:Category>Development</gjob:Category>
|
|
|
|
<gjob:Update>
|
|
<gjob:Status>Open</gjob:Status>
|
|
<gjob:Modified>Mon, 07 Jun 1999 20:27:45 -0400 MET DST</gjob:Modified>
|
|
<gjob:Salary>USD 0.00</gjob:Salary>
|
|
</gjob:Update>
|
|
|
|
<gjob:Developers>
|
|
<gjob:Developer>
|
|
</gjob:Developer>
|
|
</gjob:Developers>
|
|
|
|
<gjob:Contact>
|
|
<gjob:Person>Nathan Clemons</gjob:Person>
|
|
<gjob:Email>nathan@windsofstorm.net</gjob:Email>
|
|
<gjob:Company>
|
|
</gjob:Company>
|
|
<gjob:Organisation>
|
|
</gjob:Organisation>
|
|
<gjob:Webpage>
|
|
</gjob:Webpage>
|
|
<gjob:Snailmail>
|
|
</gjob:Snailmail>
|
|
<gjob:Phone>
|
|
</gjob:Phone>
|
|
</gjob:Contact>
|
|
|
|
<gjob:Requirements>
|
|
The program should be released as free software, under the GPL.
|
|
</gjob:Requirements>
|
|
|
|
<gjob:Skills>
|
|
</gjob:Skills>
|
|
|
|
<gjob:Details>
|
|
A GNOME based system that will allow a superuser to configure
|
|
compressed and uncompressed files and/or file systems to be backed
|
|
up with a supported media in the system. This should be able to
|
|
perform via find commands generating a list of files that are passed
|
|
to tar, dd, cpio, cp, gzip, etc., to be directed to the tape machine
|
|
or via operations performed on the filesystem itself. Email
|
|
notification and GUI status display very important.
|
|
</gjob:Details>
|
|
|
|
</gjob:Job>
|
|
|
|
</gjob:Jobs>
|
|
</gjob:Helping></pre>
|
|
|
|
<p>While loading the XML file into an internal DOM tree is a matter of calling
|
|
only a couple of functions, browsing the tree to gather the informations and
|
|
generate the internals structures is harder, and more error prone.</p>
|
|
|
|
<p>The suggested principle is to be tolerant with respect to the input
|
|
structure. For example, the ordering of the attributes is not significant, Cthe
|
|
XML specification is clear about it. It's also usually a good idea to not be
|
|
dependent of the orders of the childs of a given node, unless it really makes
|
|
things harder. Here is some code to parse the informations for a person:</p>
|
|
<pre>/*
|
|
* A person record
|
|
*/
|
|
typedef struct person {
|
|
char *name;
|
|
char *email;
|
|
char *company;
|
|
char *organisation;
|
|
char *smail;
|
|
char *webPage;
|
|
char *phone;
|
|
} person, *personPtr;
|
|
|
|
/*
|
|
* And the code needed to parse it
|
|
*/
|
|
personPtr parsePerson(xmlDocPtr doc, xmlNsPtr ns, xmlNodePtr cur) {
|
|
personPtr ret = NULL;
|
|
|
|
DEBUG("parsePerson\n");
|
|
/*
|
|
* allocate the struct
|
|
*/
|
|
ret = (personPtr) malloc(sizeof(person));
|
|
if (ret == NULL) {
|
|
fprintf(stderr,"out of memory\n");
|
|
return(NULL);
|
|
}
|
|
memset(ret, 0, sizeof(person));
|
|
|
|
/* We don't care what the top level element name is */
|
|
cur = cur->childs;
|
|
while (cur != NULL) {
|
|
if ((!strcmp(cur->name, "Person")) && (cur->ns == ns))
|
|
ret->name = xmlNodeListGetString(doc, cur->childs, 1);
|
|
if ((!strcmp(cur->name, "Email")) && (cur->ns == ns))
|
|
ret->email = xmlNodeListGetString(doc, cur->childs, 1);
|
|
cur = cur->next;
|
|
}
|
|
|
|
return(ret);
|
|
}</pre>
|
|
|
|
<p>Here is a couple of things to notice:</p>
|
|
<ul>
|
|
<li>Usually a recursive parsing style is the more convenient one, XML data
|
|
being by nature subject to repetitive constructs and usualy exibit highly
|
|
stuctured patterns.</li>
|
|
<li>The two arguments of type <em>xmlDocPtr</em> and <em>xmlNsPtr</em>, i.e.
|
|
the pointer to the global XML document and the namespace reserved to the
|
|
application. Document wide information are needed for example to decode
|
|
entities and it's a good coding practice to define a namespace for your
|
|
application set of data and test that the element and attributes you're
|
|
analyzing actually pertains to your application space. This is done by a
|
|
simple equality test (cur->ns == ns).</li>
|
|
<li>To retrieve text and attributes value, it is suggested to use the
|
|
function <em>xmlNodeListGetString</em> to gather all the text and entity
|
|
reference nodes generated by the DOM output and produce an single text
|
|
string.</li>
|
|
</ul>
|
|
|
|
<p>Here is another piece of code used to parse another level of the
|
|
structure:</p>
|
|
<pre>/*
|
|
* a Description for a Job
|
|
*/
|
|
typedef struct job {
|
|
char *projectID;
|
|
char *application;
|
|
char *category;
|
|
personPtr contact;
|
|
int nbDevelopers;
|
|
personPtr developers[100]; /* using dynamic alloc is left as an exercise */
|
|
} job, *jobPtr;
|
|
|
|
/*
|
|
* And the code needed to parse it
|
|
*/
|
|
jobPtr parseJob(xmlDocPtr doc, xmlNsPtr ns, xmlNodePtr cur) {
|
|
jobPtr ret = NULL;
|
|
|
|
DEBUG("parseJob\n");
|
|
/*
|
|
* allocate the struct
|
|
*/
|
|
ret = (jobPtr) malloc(sizeof(job));
|
|
if (ret == NULL) {
|
|
fprintf(stderr,"out of memory\n");
|
|
return(NULL);
|
|
}
|
|
memset(ret, 0, sizeof(job));
|
|
|
|
/* We don't care what the top level element name is */
|
|
cur = cur->childs;
|
|
while (cur != NULL) {
|
|
|
|
if ((!strcmp(cur->name, "Project")) && (cur->ns == ns)) {
|
|
ret->projectID = xmlGetProp(cur, "ID");
|
|
if (ret->projectID == NULL) {
|
|
fprintf(stderr, "Project has no ID\n");
|
|
}
|
|
}
|
|
if ((!strcmp(cur->name, "Application")) && (cur->ns == ns))
|
|
ret->application = xmlNodeListGetString(doc, cur->childs, 1);
|
|
if ((!strcmp(cur->name, "Category")) && (cur->ns == ns))
|
|
ret->category = xmlNodeListGetString(doc, cur->childs, 1);
|
|
if ((!strcmp(cur->name, "Contact")) && (cur->ns == ns))
|
|
ret->contact = parsePerson(doc, ns, cur);
|
|
cur = cur->next;
|
|
}
|
|
|
|
return(ret);
|
|
}</pre>
|
|
|
|
<p>One can notice that once used to it, writing this kind of code is quite
|
|
simple, but boring. Ultimately, it could be possble to write stubbers taking
|
|
either C data structure definitions, a set of XML examples or an XML DTD and
|
|
produce the code needed to import and export the content between C data and
|
|
XML storage. This is left as an exercise to the reader :-)</p>
|
|
|
|
<p>Feel free to use <a href="gjobread.c">the code for the full C parsing
|
|
example</a> as a template, it is also available with Makefile in the Gnome CVS
|
|
base under gnome-xml/example</p>
|
|
|
|
<p></p>
|
|
|
|
<p><a href="mailto:Daniel.Veillard@w3.org">Daniel Veillard</a></p>
|
|
|
|
<p>$Id: xml.html,v 1.26 2000/03/01 00:40:41 veillard Exp $</p>
|
|
</body>
|
|
</html>
|