blob: 03abc15578e61bc07fd1b0e53ab6dbb09ee977a7 [file] [log] [blame]
Daniel Veillardccb09631998-10-27 06:21:04 +00001<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
2 "http://www.w3.org/TR/REC-html40/loose.dtd">
3<html>
4<head>
Daniel Veillard25940b71998-10-29 05:51:30 +00005<title>The XML library for Gnome</title>
Daniel Veillardccb09631998-10-27 06:21:04 +00006<meta name="GENERATOR" content="amaya V1.3b">
7</head>
8<body bgcolor="#ffffff">
9
10<h1 align="center">The XML library for Gnome</h1>
11<p>
12This document describes the <a href="http://www.w3.org/XML/">XML</a> library
13provideed in the <a href="http://www.gnome.org/">Gnome</a> framework. XML is a
14standard to build tag based structured documents. The internal document
15repesentation is as close as possible to the <a
16href="http://www.w3.org/DOM/">DOM</a> interfaces.</p>
17
18<h2>xml</h2>
19<p>
Daniel Veillard10c6a8f1998-10-28 01:00:12 +000020XML is a standard for markup based structured documents, here is <a
21name="example">an example</a>:</p>
Daniel Veillardccb09631998-10-27 06:21:04 +000022<pre>&lt;?xml version="1.0"?>
Daniel Veillard14fff061999-06-22 21:49:07 +000023&lt;EXAMPLE prop1="gnome is great" prop2="&amp;amp; linux too">
Daniel Veillardccb09631998-10-27 06:21:04 +000024 &lt;head>
25 &lt;title>Welcome to Gnome&lt;/title>
26 &lt;/head>
27 &lt;chapter>
28 &lt;title>The Linux adventure&lt;/title>
29 &lt;p>bla bla bla ...&lt;/p>
30 &lt;image href="linus.gif"/>
31 &lt;p>...&lt;/p>
32 &lt;/chapter>
33&lt;/EXAMPLE></pre>
34<p>
Daniel Veillard10c6a8f1998-10-28 01:00:12 +000035The first line specify that it's an XML document and gives useful informations
36about it's encoding. Then the document is a text format whose structure is
37specified by tags between brackets. <strong>Each tag opened have to be
38closed</strong> XML is pedantic about this, not that for example the image
Daniel Veillard14fff061999-06-22 21:49:07 +000039tag has no content (just an attribute) and is closed by ending up the tag
Daniel Veillard10c6a8f1998-10-28 01:00:12 +000040with <code>/></code>.</p>
Daniel Veillardccb09631998-10-27 06:21:04 +000041
42<h2>The tree output</h2>
43<p>
44The parser returns a tree built during the document analysis. The value
45returned is an <strong>xmlDocPtr</strong> (i.e. a pointer to an
46<strong>xmlDoc</strong> structure). This structure contains informations like
47the file name, the document type, and a <strong>root</strong> pointer which
48is the root of the document (or more exactly the first child under the root
49which is the document). The tree is made of <strong>xmlNode</strong>s, chained
50in double linked lists of siblings and with childs&lt;->parent relationship.
51An xmlNode can also carry properties (a chain of xmlAttr structures). An
52attribute may have a value which is a list of TEXT or ENTITY_REF nodes.</p>
53<p>
54Here is an example (erroneous w.r.t. the XML spec since there should be only
55one ELEMENT under the root):</p>
56<p>
57<img src="structure.gif" alt=" structure.gif "></p>
58<p>
Daniel Veillard10c6a8f1998-10-28 01:00:12 +000059In the source package there is a small program (not installed by default)
60called <strong>tester</strong> which parses XML files given as argument and
61prints them back as parsed, this is useful to detect errors both in XML code
62and in the XML parser itself. It has an option <strong>--debug</strong> which
63prints the actual in-memory structure of the document, here is the result with
64the <a href="#example">example</a> given before:</p>
65<pre>DOCUMENT
66version=1.0
67standalone=true
68 ELEMENT EXAMPLE
69 ATTRIBUTE prop1
70 TEXT
71 content=gnome is great
72 ATTRIBUTE prop2
73 ENTITY_REF
74 TEXT
75 content= too
76 ELEMENT head
77 ELEMENT title
Daniel Veillard25940b71998-10-29 05:51:30 +000078 TEXT
79 content=Welcome to Gnome
Daniel Veillard10c6a8f1998-10-28 01:00:12 +000080 ELEMENT chapter
81 ELEMENT title
Daniel Veillard25940b71998-10-29 05:51:30 +000082 TEXT
83 content=The Linux adventure
Daniel Veillard10c6a8f1998-10-28 01:00:12 +000084 ELEMENT p
Daniel Veillard25940b71998-10-29 05:51:30 +000085 TEXT
86 content=bla bla bla ...
Daniel Veillard10c6a8f1998-10-28 01:00:12 +000087 ELEMENT image
88 ATTRIBUTE href
89 TEXT
90 content=linus.gif
91 ELEMENT p
Daniel Veillard25940b71998-10-29 05:51:30 +000092 TEXT
93 content=...</pre>
Daniel Veillard10c6a8f1998-10-28 01:00:12 +000094<p>
95This should be useful to learn the internal representation model.</p>
Daniel Veillardccb09631998-10-27 06:21:04 +000096
Daniel Veillard10c6a8f1998-10-28 01:00:12 +000097<h2>The XML library interfaces</h2>
98<p>
99This section is directly intended to help programmers getting bootstrapped
100using the XML library from the C language. It doesn't intent to be extensive,
101I hope the automatically generated docs will provide the completeness
102required, but as a separated set of documents. The interfaces of the XML
103library are by principle low level, there is nearly zero abstration. Those
104interested in a higher level API should <a href="#DOM">look at DOM</a>
105(unfortunately not completed).</p>
Daniel Veillardccb09631998-10-27 06:21:04 +0000106
Daniel Veillard10c6a8f1998-10-28 01:00:12 +0000107<h3>Invoking the parser</h3>
108<p>
109Usually, the first thing to do is to read an XML input, the parser accepts to
110parse both memory mapped documents or direct files. The functions are defined
111in "parser.h":</p>
112<dl>
Daniel Veillard25940b71998-10-29 05:51:30 +0000113<dt><code>xmlDocPtr xmlParseMemory(char *buffer, int size);</code></dt>
Daniel Veillard10c6a8f1998-10-28 01:00:12 +0000114<dd><p>
115parse a zero terminated string containing the document</p>
116</dd>
117</dl>
118<dl>
Daniel Veillard25940b71998-10-29 05:51:30 +0000119<dt><code>xmlDocPtr xmlParseFile(const char *filename);</code></dt>
Daniel Veillard10c6a8f1998-10-28 01:00:12 +0000120<dd><p>
121parse an XML document contained in a file (possibly compressed)</p>
122</dd>
123</dl>
124<p>
Daniel Veillard25940b71998-10-29 05:51:30 +0000125This returns a pointer to the document structure (or NULL in case of
Daniel Veillard10c6a8f1998-10-28 01:00:12 +0000126failure).</p>
127<p>
128A couple of comments can be made, first this mean that the parser is
129memory-hungry, first to load the document in memory, second to build the tree.
130Reading a document without building the tree will be possible in the future by
131pluggin the code to the SAX interface (see SAX.c).</p>
Daniel Veillardccb09631998-10-27 06:21:04 +0000132
Daniel Veillard25940b71998-10-29 05:51:30 +0000133<h3>Building a tree from scratch</h3>
134<p>
135The other way to get an XML tree in memory is by building it. Basically there
136is a set of functions dedicated to building new elements, those are also
137described in "tree.h", here is for example the piece of code producing the
138example used before:</p>
139<pre> xmlDocPtr doc;
140 xmlNodePtr tree, subtree;
141
142 doc = xmlNewDoc("1.0");
143 doc->root = xmlNewDocNode(doc, NULL, "EXAMPLE", NULL);
144 xmlSetProp(doc->root, "prop1", "gnome is great");
145 xmlSetProp(doc->root, "prop2", "&amp;linux; too");
146 tree = xmlNewChild(doc->root, NULL, "head", NULL);
147 subtree = xmlNewChild(tree, NULL, "title", "Welcome to Gnome");
148 tree = xmlNewChild(doc->root, NULL, "chapter", NULL);
149 subtree = xmlNewChild(tree, NULL, "title", "The Linux adventure");
150 subtree = xmlNewChild(tree, NULL, "p", "bla bla bla ...");
151 subtree = xmlNewChild(tree, NULL, "image", NULL);
152 xmlSetProp(subtree, "href", "linus.gif");</pre>
153<p>
154Not really rocket science ...</p>
155
Daniel Veillard10c6a8f1998-10-28 01:00:12 +0000156<h3>Traversing the tree</h3>
157<p>
158Basically by including "tree.h" your code has access to the internal structure
159of all the element of the tree. The names should be somewhat simple like
160<strong>parent</strong>, <strong>childs</strong>, <strong>next</strong>,
Daniel Veillard25940b71998-10-29 05:51:30 +0000161<strong>prev</strong>, <strong>properties</strong>, etc... For example still
162with the previous example:</p>
163<pre><code>doc->root->childs->childs</code></pre>
164<p>
165points to the title element,</p>
166<pre>doc->root->childs->next->child->child</pre>
167<p>
168points to the text node containing the chapter titlle "The Linux adventure"
169and</p>
170<pre>doc->root->properties->next->val</pre>
171<p>
172points to the entity reference containing the value of "&amp;linux" at the
173beginning of the second attribute of the root element "EXAMPLE".</p>
Daniel Veillard10c6a8f1998-10-28 01:00:12 +0000174
175<h3>Modifying the tree</h3>
Daniel Veillard25940b71998-10-29 05:51:30 +0000176<p>
177functions are provided to read and write the document content:</p>
178<dl>
179<dt><code>xmlAttrPtr xmlSetProp(xmlNodePtr node, const CHAR *name, const CHAR
180*value);</code></dt>
181<dd><p>
182This set (or change) an attribute carried by an ELEMENT node the value can be
183NULL</p>
184</dd>
185</dl>
186<dl>
187<dt><code>const CHAR *xmlGetProp(xmlNodePtr node, const CHAR
188*name);</code></dt>
189<dd><p>
190This function returns a pointer to the property content, note that no extra
191copy is made</p>
192</dd>
193</dl>
194<p>
195Two functions must be used to read an write the text associated to
196elements:</p>
197<dl>
198<dt><code>xmlNodePtr xmlStringGetNodeList(xmlDocPtr doc, const CHAR
199*value);</code></dt>
200<dd><p>
201This function takes an "external" string and convert it to one text node or
202possibly to a list of entity and text nodes. All non-predefined entity
203references like &amp;Gnome; will be stored internally as an entity node, hence
204the result of the function may not be a single node.</p>
205</dd>
206</dl>
207<dl>
208<dt><code>CHAR *xmlNodeListGetString(xmlDocPtr doc, xmlNodePtr list, int
209inLine);</code></dt>
210<dd><p>
211this is the dual function, which generate a new string containing the content
212of the text and entity nodes. Note the extra argument inLine, if set to 1
213instead of returning the &amp;Gnome; XML encoding in the string it will
214substitute it with it's value say "GNU Network Object Model Environment". Set
215it if you want to use the string for non XML usage like User Interface.</p>
216</dd>
217</dl>
Daniel Veillard10c6a8f1998-10-28 01:00:12 +0000218
219<h3>Saving a tree</h3>
Daniel Veillard25940b71998-10-29 05:51:30 +0000220<p>
221Basically 3 options are possible:</p>
222<dl>
223<dt><code>void xmlDocDumpMemory(xmlDocPtr cur, CHAR**mem, int
224*size);</code></dt>
225<dd><p>
226returns a buffer where the document has been saved</p>
227</dd>
228</dl>
229<dl>
230<dt><code>extern void xmlDocDump(FILE *f, xmlDocPtr doc);</code></dt>
231<dd><p>
232dumps a buffer to an open file descriptor</p>
233</dd>
234</dl>
235<dl>
236<dt><code>int xmlSaveFile(const char *filename, xmlDocPtr cur);</code></dt>
237<dd><p>
238save the document ot a file. In that case the compression interface is
239triggered if turned on</p>
240</dd>
241</dl>
Daniel Veillard10c6a8f1998-10-28 01:00:12 +0000242
Daniel Veillard25940b71998-10-29 05:51:30 +0000243<h3>Compression</h3>
244<p>
245The library handle transparently compression when doing file based accesses,
246the level of compression on saves can be tuned either globally or individually
247for one file:</p>
248<dl>
249<dt><code>int xmlGetDocCompressMode (xmlDocPtr doc);</code></dt>
250<dd><p>
251Get the document compression ratio (0-9)</p>
252</dd>
253</dl>
254<dl>
255<dt><code>void xmlSetDocCompressMode (xmlDocPtr doc, int mode);</code></dt>
256<dd><p>
257Set the document compression ratio</p>
258</dd>
259</dl>
260<dl>
261<dt><code>int xmlGetCompressMode(void);</code></dt>
262<dd><p>
263Get the default compression ratio</p>
264</dd>
265</dl>
266<dl>
267<dt><code>void xmlSetCompressMode(int mode);</code></dt>
268<dd><p>
269set the default compression ratio</p>
270</dd>
271</dl>
272
273<h2><a name="DOM">DOM Principles</a></h2>
Daniel Veillardccb09631998-10-27 06:21:04 +0000274<p>
275<a href="http://www.w3.org/DOM/">DOM</a> stands for the <em>Document Object
276Model</em> this is an API for accessing XML or HTML structured documents.
277Native support for DOM in Gnome is on the way (module gnome-dom), and it will
Daniel Veillard25940b71998-10-29 05:51:30 +0000278be based on gnome-xml. This will be a far cleaner interface to manipulate XML
279files within Gnome since it won't expose the internal structure. DOM defiles a
280set of IDL (or Java) interfaces allowing to traverse and manipulate a
281document. The DOM library will allow accessing and modifying "live" documents
282presents on other programs like this:</p>
Daniel Veillardccb09631998-10-27 06:21:04 +0000283<p>
284<img src="DOM.gif" alt=" DOM.gif "></p>
285<p>
286This should help greatly doing things like modifying a gnumeric spreadsheet
287embedded in a GWP document for example.</p>
Daniel Veillard14fff061999-06-22 21:49:07 +0000288
289<h3><a name="Example">A real example</a></h3>
Daniel Veillardccb09631998-10-27 06:21:04 +0000290<p>
Daniel Veillard14fff061999-06-22 21:49:07 +0000291Here is a real size example, where the actual content of the application data
292is not kept in the DOM tree but uses internal structures. It is based on
293a proposal to keep a database of jobs related to Gnome, with an XML based
294storage structure. Here is an <a href="gjobs.xml">XML encoded jobs base</a>:
295<pre>
296&lt;?xml version="1.0"?>
297&lt;gjob:Helping xmlns:gjob="http://www.gnome.org/some-location">
298 &lt;gjob:Jobs>
299
300 &lt;gjob:Job>
301 &lt;gjob:Project ID="3"/>
302 &lt;gjob:Application>GBackup&lt;/gjob:Application>
303 &lt;gjob:Category>Development&lt;/gjob:Category>
304
305 &lt;gjob:Update>
306 &lt;gjob:Status>Open&lt;/gjob:Status>
307 &lt;gjob:Modified>Mon, 07 Jun 1999 20:27:45 -0400 MET DST&lt;/gjob:Modified>
308 &lt;gjob:Salary>USD 0.00&lt;/gjob:Salary>
309 &lt;/gjob:Update>
310
311 &lt;gjob:Developers>
312 &lt;gjob:Developer>
313 &lt;/gjob:Developer>
314 &lt;/gjob:Developers>
315
316 &lt;gjob:Contact>
317 &lt;gjob:Person>Nathan Clemons&lt;/gjob:Person>
318 &lt;gjob:Email>nathan@windsofstorm.net&lt;/gjob:Email>
319 &lt;gjob:Company>
320 &lt;/gjob:Company>
321 &lt;gjob:Organisation>
322 &lt;/gjob:Organisation>
323 &lt;gjob:Webpage>
324 &lt;/gjob:Webpage>
325 &lt;gjob:Snailmail>
326 &lt;/gjob:Snailmail>
327 &lt;gjob:Phone>
328 &lt;/gjob:Phone>
329 &lt;/gjob:Contact>
330
331 &lt;gjob:Requirements>
332 The program should be released as free software, under the GPL.
333 &lt;/gjob:Requirements>
334
335 &lt;gjob:Skills>
336 &lt;/gjob:Skills>
337
338 &lt;gjob:Details>
339 A GNOME based system that will allow a superuser to configure
340 compressed and uncompressed files and/or file systems to be backed
341 up with a supported media in the system. This should be able to
342 perform via find commands generating a list of files that are passed
343 to tar, dd, cpio, cp, gzip, etc., to be directed to the tape machine
344 or via operations performed on the filesystem itself. Email
345 notification and GUI status display very important.
346 &lt;/gjob:Details>
347
348 &lt;/gjob:Job>
349
350 &lt;/gjob:Jobs>
351&lt;/gjob:Helping>
352
353</pre>
354<p>
355While loading the XML file into an internal DOM tree is a matter of calling
356only a couple of functions, browsing the tree to gather the informations
357and generate the internals structures is harder, and more error prone.
Daniel Veillardccb09631998-10-27 06:21:04 +0000358</p>
Daniel Veillard14fff061999-06-22 21:49:07 +0000359<p>
360The suggested principle is to be tolerant with respect to the input
361structure. For example the ordering of the attributes is not significant,
362Cthe XML specification is clear about it. It's also usually a good idea
363to not be dependant of the orders of the childs of a given node, unless it
364really makes things harder. Here is some code to parse the informations
365for a person:
366</p>
367<pre>
368/*
369 * A person record
370 */
371typedef struct person {
372 char *name;
373 char *email;
374 char *company;
375 char *organisation;
376 char *smail;
377 char *webPage;
378 char *phone;
379} person, *personPtr;
380
381/*
382 * And the code needed to parse it
383 */
384personPtr parsePerson(xmlDocPtr doc, xmlNsPtr ns, xmlNodePtr cur) {
385 personPtr ret = NULL;
386
387DEBUG("parsePerson\n");
388 /*
389 * allocate the struct
390 */
391 ret = (personPtr) malloc(sizeof(person));
392 if (ret == NULL) {
393 fprintf(stderr,"out of memory\n");
394 return(NULL);
395 }
396 memset(ret, 0, sizeof(person));
397
398 /* We don't care what the top level element name is */
399 cur = cur->childs;
400 while (cur != NULL) {
401 if ((!strcmp(cur->name, "Person")) &amp;&amp; (cur->ns == ns))
402 ret->name = xmlNodeListGetString(doc, cur->childs, 1);
403 if ((!strcmp(cur->name, "Email")) &amp;&amp; (cur->ns == ns))
404 ret->email = xmlNodeListGetString(doc, cur->childs, 1);
405 cur = cur->next;
406 }
407
408 return(ret);
409}
410</pre>
411<p>
412Here is a couple of things to notice:</p>
413<ul>
414<li> Usually a recursive parsing style is the more convenient one,
415XML data being by nature subject to repetitive constructs and usualy exibit
416highly stuctured patterns.
417<li> The two arguments of type <em>xmlDocPtr</em> and <em>xmlNsPtr</em>, i.e.
418the pointer to the global XML document and the namespace reserved to the
419application. Document wide information are needed for example to decode
420entities and it's a good coding practice to define a namespace for your
421application set of data and test that the element and attributes you're
422analyzing actually pertains to your application space. This is done by a simple
423equality test (cur->ns == ns).
424<li> To retrieve text and attributes value, it is suggested to use
425the function <em>xmlNodeListGetString</em> to gather all the text and
426entity reference nodes generated by the DOM output and produce an
427single text string.
428</ul>
429<p>
430Here is another piece of code used to parse another level of the structure:
431</p>
432<pre>
433/*
434 * a Description for a Job
435 */
436typedef struct job {
437 char *projectID;
438 char *application;
439 char *category;
440 personPtr contact;
441 int nbDevelopers;
442 personPtr developers[100]; /* using dynamic alloc is left as an exercise */
443} job, *jobPtr;
444
445/*
446 * And the code needed to parse it
447 */
448jobPtr parseJob(xmlDocPtr doc, xmlNsPtr ns, xmlNodePtr cur) {
449 jobPtr ret = NULL;
450
451DEBUG("parseJob\n");
452 /*
453 * allocate the struct
454 */
455 ret = (jobPtr) malloc(sizeof(job));
456 if (ret == NULL) {
457 fprintf(stderr,"out of memory\n");
458 return(NULL);
459 }
460 memset(ret, 0, sizeof(job));
461
462 /* We don't care what the top level element name is */
463 cur = cur->childs;
464 while (cur != NULL) {
465
466 if ((!strcmp(cur->name, "Project")) &amp;&amp; (cur->ns == ns)) {
467 ret->projectID = xmlGetProp(cur, "ID");
468 if (ret->projectID == NULL) {
469 fprintf(stderr, "Project has no ID\n");
470 }
471 }
472 if ((!strcmp(cur->name, "Application")) &amp;&amp; (cur->ns == ns))
473 ret->application = xmlNodeListGetString(doc, cur->childs, 1);
474 if ((!strcmp(cur->name, "Category")) &amp;&amp; (cur->ns == ns))
475 ret->category = xmlNodeListGetString(doc, cur->childs, 1);
476 if ((!strcmp(cur->name, "Contact")) &amp;&amp; (cur->ns == ns))
477 ret->contact = parsePerson(doc, ns, cur);
478 cur = cur->next;
479 }
480
481 return(ret);
482}
483</pre>
484<p>
485One can notice that once used to it, writing this kind of code
486is quite simple, but boring. Ultimately, it could be possble to write
487stubbers taking either C data structure definitions, a set of XML examples
488or an XML DTD and produce the code needed to import and export the
489content between C data and XML storage. This is left as an exercise to
490the reader :-)</p>
491<p>
492Feel free to use <a href="gjobread.c">the code for the full C parsing
493example</a> as a template,
494
495<a href="mailto:Daniel.Veillard@w3.org">Daniel Veillard</a>
Daniel Veillardccb09631998-10-27 06:21:04 +0000496</body>
497</html>