mirror of
https://gitlab.gnome.org/GNOME/libxml2.git
synced 2025-02-20 13:57:22 +03:00
498 lines
16 KiB
HTML
498 lines
16 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 V1.3b">
|
|
</head>
|
|
<body bgcolor="#ffffff">
|
|
|
|
<h1 align="center">The XML library for Gnome</h1>
|
|
<p>
|
|
This document describes the <a href="http://www.w3.org/XML/">XML</a> library
|
|
provideed in the <a href="http://www.gnome.org/">Gnome</a> framework. XML is a
|
|
standard to build tag based structured documents. The internal document
|
|
repesentation is as close as possible to the <a
|
|
href="http://www.w3.org/DOM/">DOM</a> interfaces.</p>
|
|
|
|
<h2>xml</h2>
|
|
<p>
|
|
XML is a standard for markup based structured documents, here is <a
|
|
name="example">an example</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 specify that it's an XML document and gives useful informations
|
|
about it's encoding. Then the document is a text format whose structure is
|
|
specified by tags between brackets. <strong>Each tag opened have to be
|
|
closed</strong> XML is pedantic about this, not that for example the image
|
|
tag has no content (just an attribute) and is closed by ending up the tag
|
|
with <code>/></code>.</p>
|
|
|
|
<h2>The tree output</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 informations like
|
|
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 w.r.t. 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 to detect 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= 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 to learn the internal representation model.</p>
|
|
|
|
<h2>The XML library interfaces</h2>
|
|
<p>
|
|
This section is directly intended to help programmers getting bootstrapped
|
|
using the XML library from the C language. It doesn't intent to be extensive,
|
|
I hope the automatically generated docs will provide the completeness
|
|
required, but as a separated set of documents. The interfaces of the XML
|
|
library are by principle low level, there is nearly zero abstration. Those
|
|
interested in a higher level API should <a href="#DOM">look at DOM</a>
|
|
(unfortunately not completed).</p>
|
|
|
|
<h3>Invoking the parser</h3>
|
|
<p>
|
|
Usually, the first thing to do is to read an XML input, the parser accepts to
|
|
parse both memory mapped documents or direct files. The functions are defined
|
|
in "parser.h":</p>
|
|
<dl>
|
|
<dt><code>xmlDocPtr xmlParseMemory(char *buffer, int size);</code></dt>
|
|
<dd><p>
|
|
parse a zero 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 file (possibly compressed)</p>
|
|
</dd>
|
|
</dl>
|
|
<p>
|
|
This returns a pointer to the document structure (or NULL in case of
|
|
failure).</p>
|
|
<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 will be possible in the future by
|
|
pluggin the code to the SAX interface (see SAX.c).</p>
|
|
|
|
<h3>Building a tree from scratch</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, those are also
|
|
described in "tree.h", here is for example the piece of code producing the
|
|
example used before:</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>Traversing the tree</h3>
|
|
<p>
|
|
Basically by including "tree.h" your code has access to the internal structure
|
|
of all the element 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 titlle "The Linux adventure"
|
|
and</p>
|
|
<pre>doc->root->properties->next->val</pre>
|
|
<p>
|
|
points to the entity reference containing the value of "&linux" at the
|
|
beginning of the second attribute of the root element "EXAMPLE".</p>
|
|
|
|
<h3>Modifying the tree</h3>
|
|
<p>
|
|
functions are provided to read and write the document content:</p>
|
|
<dl>
|
|
<dt><code>xmlAttrPtr xmlSetProp(xmlNodePtr node, const CHAR *name, const CHAR
|
|
*value);</code></dt>
|
|
<dd><p>
|
|
This set (or change) an attribute carried by an ELEMENT node the value can be
|
|
NULL</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>const CHAR *xmlGetProp(xmlNodePtr node, const CHAR
|
|
*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 must be used to read an write the text associated to
|
|
elements:</p>
|
|
<dl>
|
|
<dt><code>xmlNodePtr xmlStringGetNodeList(xmlDocPtr doc, const CHAR
|
|
*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 an entity node, hence
|
|
the result of the function may not be a single node.</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>CHAR *xmlNodeListGetString(xmlDocPtr doc, xmlNodePtr list, int
|
|
inLine);</code></dt>
|
|
<dd><p>
|
|
this is the dual function, which generate a new string containing the content
|
|
of the text and entity nodes. Note the extra argument inLine, if set to 1
|
|
instead of returning the &Gnome; XML encoding in the string it will
|
|
substitute it with it's value say "GNU Network Object Model Environment". Set
|
|
it if you want to use the string for non XML usage like User Interface.</p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<h3>Saving a tree</h3>
|
|
<p>
|
|
Basically 3 options are possible:</p>
|
|
<dl>
|
|
<dt><code>void xmlDocDumpMemory(xmlDocPtr cur, CHAR**mem, int
|
|
*size);</code></dt>
|
|
<dd><p>
|
|
returns a buffer where the document has been saved</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>extern void xmlDocDump(FILE *f, xmlDocPtr doc);</code></dt>
|
|
<dd><p>
|
|
dumps a buffer to an open file descriptor</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>int xmlSaveFile(const char *filename, xmlDocPtr cur);</code></dt>
|
|
<dd><p>
|
|
save the document ot a file. In that case the compression interface is
|
|
triggered if turned on</p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<h3>Compression</h3>
|
|
<p>
|
|
The library handle transparently compression when doing file based accesses,
|
|
the level of compression on saves can be tuned either globally or individually
|
|
for one file:</p>
|
|
<dl>
|
|
<dt><code>int xmlGetDocCompressMode (xmlDocPtr doc);</code></dt>
|
|
<dd><p>
|
|
Get the document compression ratio (0-9)</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>void xmlSetDocCompressMode (xmlDocPtr doc, int mode);</code></dt>
|
|
<dd><p>
|
|
Set the document compression ratio</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>int xmlGetCompressMode(void);</code></dt>
|
|
<dd><p>
|
|
Get the default compression ratio</p>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>void xmlSetCompressMode(int mode);</code></dt>
|
|
<dd><p>
|
|
set the default compression ratio</p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<h2><a name="DOM">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 defiles 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>
|
|
|
|
<h3><a name="Example">A real example</a></h3>
|
|
<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>:
|
|
<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 dependant 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> 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> 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.
|
|
</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,
|
|
|
|
<a href="mailto:Daniel.Veillard@w3.org">Daniel Veillard</a>
|
|
</body>
|
|
</html>
|