| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 2 | "http://www.w3.org/TR/REC-html40/loose.dtd"> | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 3 | <html> | 
|  | 4 | <head> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 5 | <title>The XML library for Gnome</title> | 
|  | 6 | <meta name="GENERATOR" content="amaya V2.1"> | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 7 | </head> | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 8 |  | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 9 | <body bgcolor="#ffffff"> | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 10 | <h1 align="center">The XML library for Gnome</h1> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 11 |  | 
| Daniel Veillard | c8eab3a | 1999-09-04 18:27:23 +0000 | [diff] [blame] | 12 | <h2 style="text-align: center">libxml, a.k.a. gnome-xml</h2> | 
|  | 13 |  | 
|  | 14 | <p></p> | 
|  | 15 |  | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 16 | <p>This document describes the <a href="http://www.w3.org/XML/">XML</a> | 
|  | 17 | library provideed in the <a href="http://www.gnome.org/">Gnome</a> framework. | 
| Daniel Veillard | c8eab3a | 1999-09-04 18:27:23 +0000 | [diff] [blame] | 18 | XML is a standard to build tag based structured documents/data.</p> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 19 |  | 
|  | 20 | <p>The internal document repesentation is as close as possible to the <a | 
| Daniel Veillard | c8eab3a | 1999-09-04 18:27:23 +0000 | [diff] [blame] | 21 | href="http://www.w3.org/DOM/">DOM</a> interfaces.</p> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 22 |  | 
|  | 23 | <p>Libxml also has a <a href="http://www.megginson.com/SAX/index.html">SAX | 
|  | 24 | interface</a>, <a href="mailto:james@daa.com.au">James Henstridge</a> made <a | 
|  | 25 | href="http://www.daa.com.au/~james/gnome/xml-sax/xml-sax.html">a nice | 
|  | 26 | documentation</a> expaining how to use it. The interface is as compatible as | 
|  | 27 | possible with <a href="http://www.jclark.com/xml/expat.html">Expat</a> | 
|  | 28 | one.</p> | 
|  | 29 |  | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 30 | <p>There is also a mailing-list <a | 
| Daniel Veillard | 6bd26dc | 1999-09-03 14:28:40 +0000 | [diff] [blame] | 31 | href="mailto:xml@rufus.w3.org">xml@rufus.w3.org</a> for libxml, with an <a | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 32 | href="http://rpmfind.net/veillard/XML/messages">on-line archive</a>. To | 
|  | 33 | subscribe to this majordomo based list, send a mail to <a | 
| Daniel Veillard | 6bd26dc | 1999-09-03 14:28:40 +0000 | [diff] [blame] | 34 | href="mailto:majordomo@rufus.w3.org">majordomo@rufus.w3.org</a> with | 
|  | 35 | "subscribe xml" in the <strong>content</strong> of the message.</p> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 36 |  | 
|  | 37 | <p>This library is released both under the W3C Copyright and the GNU LGP, | 
|  | 38 | basically everybody should be happy, if not, drop me a mail.</p> | 
|  | 39 |  | 
|  | 40 | <p>People are invited to use the <a | 
|  | 41 | href="http://cvs.gnome.org/lxr/source/gdome/">gdome Gnome module to</a> get a | 
|  | 42 | full DOM interface, thanks to <a href="mailto:raph@levien.com">Raph | 
|  | 43 | Levien</a>, check his <a | 
|  | 44 | href="http://www.levien.com/gnome/domination.html">DOMination paper</a>. He | 
|  | 45 | uses it for his implementation of <a | 
|  | 46 | href="http://www.w3.org/Graphics/SVG/">SVG</a> called <a | 
|  | 47 | href="http://www.levien.com/svg/">gill</a>.</p> | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 48 |  | 
| Daniel Veillard | c8eab3a | 1999-09-04 18:27:23 +0000 | [diff] [blame] | 49 | <h2>Extensive documentation</h2> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 50 |  | 
| Daniel Veillard | c8eab3a | 1999-09-04 18:27:23 +0000 | [diff] [blame] | 51 | <p>The code is commented in a <a href=""></a>way which allow <a | 
|  | 52 | href="http://rpmfind.net/veillard/XML/libxml.html">extensive documentation</a> | 
|  | 53 | to be automatically extracted.</p> | 
|  | 54 |  | 
|  | 55 | <p>At some point I will change the back-end to produce XML documentation in | 
|  | 56 | addition to SGML Docbook and HTML.</p> | 
|  | 57 |  | 
|  | 58 | <h2>XML</h2> | 
|  | 59 |  | 
|  | 60 | <p><a href="http://www.w3.org/TR/REC-xml">XML is a standard</a> for markup | 
|  | 61 | based structured documents, here is <a name="example">an example</a>:</p> | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 62 | <pre><?xml version="1.0"?> | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 63 | <EXAMPLE prop1="gnome is great" prop2="&amp; linux too"> | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 64 | <head> | 
|  | 65 | <title>Welcome to Gnome</title> | 
|  | 66 | </head> | 
|  | 67 | <chapter> | 
|  | 68 | <title>The Linux adventure</title> | 
|  | 69 | <p>bla bla bla ...</p> | 
|  | 70 | <image href="linus.gif"/> | 
|  | 71 | <p>...</p> | 
|  | 72 | </chapter> | 
|  | 73 | </EXAMPLE></pre> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 74 |  | 
|  | 75 | <p>The first line specify that it's an XML document and gives useful | 
|  | 76 | informations about it's encoding. Then the document is a text format whose | 
|  | 77 | structure is specified by tags between brackets. <strong>Each tag opened have | 
|  | 78 | to be closed</strong> XML is pedantic about this, not that for example the | 
|  | 79 | image tag has no content (just an attribute) and is closed by ending up the | 
|  | 80 | tag with <code>/></code>.</p> | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 81 |  | 
| Daniel Veillard | c8eab3a | 1999-09-04 18:27:23 +0000 | [diff] [blame] | 82 | <p>XML can be applied sucessfully to a wide range or usage from long term | 
|  | 83 | structured document maintenance where it follows the steps of SGML to simple | 
|  | 84 | data encoding mechanism like configuration file format (glade), spreadsheets | 
|  | 85 | (gnumeric), or even shorter lived document like in WebDAV where it is used to | 
|  | 86 | encode remote call between a client and a server.</p> | 
|  | 87 |  | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 88 | <h2>The tree output</h2> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 89 |  | 
|  | 90 | <p>The parser returns a tree built during the document analysis. The value | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 91 | returned is an <strong>xmlDocPtr</strong> (i.e. a pointer to an | 
|  | 92 | <strong>xmlDoc</strong> structure). This structure contains informations like | 
|  | 93 | the file  name, the document type, and a <strong>root</strong> pointer which | 
|  | 94 | is the root of the document (or more exactly the first child under the root | 
|  | 95 | which is the document). The tree is made of <strong>xmlNode</strong>s, chained | 
|  | 96 | in double linked lists of siblings and with childs<->parent relationship. | 
|  | 97 | An xmlNode can also carry properties (a chain of xmlAttr structures). An | 
|  | 98 | attribute may have a value which is a list of TEXT or ENTITY_REF nodes.</p> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 99 |  | 
|  | 100 | <p>Here is an example (erroneous w.r.t. the XML spec since there should be | 
|  | 101 | only one ELEMENT under the root):</p> | 
|  | 102 |  | 
|  | 103 | <p><img src="structure.gif" alt=" structure.gif "></p> | 
|  | 104 |  | 
|  | 105 | <p>In the source package there is a small program (not installed by default) | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 106 | called <strong>tester</strong> which parses XML files given as argument and | 
|  | 107 | prints them back as parsed, this is useful to detect errors both in XML code | 
|  | 108 | and in the XML parser itself. It has an option <strong>--debug</strong> which | 
|  | 109 | prints the actual in-memory structure of the document, here is the result with | 
|  | 110 | the <a href="#example">example</a> given before:</p> | 
|  | 111 | <pre>DOCUMENT | 
|  | 112 | version=1.0 | 
|  | 113 | standalone=true | 
|  | 114 | ELEMENT EXAMPLE | 
|  | 115 | ATTRIBUTE prop1 | 
|  | 116 | TEXT | 
|  | 117 | content=gnome is great | 
|  | 118 | ATTRIBUTE prop2 | 
|  | 119 | ENTITY_REF | 
|  | 120 | TEXT | 
|  | 121 | content= too | 
|  | 122 | ELEMENT head | 
|  | 123 | ELEMENT title | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 124 | TEXT | 
|  | 125 | content=Welcome to Gnome | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 126 | ELEMENT chapter | 
|  | 127 | ELEMENT title | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 128 | TEXT | 
|  | 129 | content=The Linux adventure | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 130 | ELEMENT p | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 131 | TEXT | 
|  | 132 | content=bla bla bla ... | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 133 | ELEMENT image | 
|  | 134 | ATTRIBUTE href | 
|  | 135 | TEXT | 
|  | 136 | content=linus.gif | 
|  | 137 | ELEMENT p | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 138 | TEXT | 
|  | 139 | content=...</pre> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 140 |  | 
|  | 141 | <p>This should be useful to learn the internal representation model.</p> | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 142 |  | 
| Daniel Veillard | c8eab3a | 1999-09-04 18:27:23 +0000 | [diff] [blame] | 143 | <h2>The SAX interface</h2> | 
|  | 144 |  | 
|  | 145 | <p>Sometimes the DOM tree output is just to large to fit reasonably into | 
|  | 146 | memory. In that case and if you don't expect to save back the XML document | 
|  | 147 | loaded using libxml, it's better to use the SAX interface of libxml. SAX is a | 
|  | 148 | <strong>callback based interface</strong> to the parser. Before parsing, the | 
|  | 149 | application layer register a customized set of callbacks which will be called | 
|  | 150 | by the library as it progresses through the XML input.</p> | 
|  | 151 |  | 
|  | 152 | <p>To get a more detailed step-by-step guidance on using the SAX interface of | 
|  | 153 | libxml, <a href="mailto:james@daa.com.au">James Henstridge</a> made <a | 
|  | 154 | href="http://www.daa.com.au/~james/gnome/xml-sax/xml-sax.html">a nice | 
|  | 155 | documentation.</a></p> | 
|  | 156 |  | 
|  | 157 | <p>You can debug the SAX behaviour by using the <strong>testSAX</strong> | 
|  | 158 | program located in the gnome-xml module (it's usually not shipped in the | 
|  | 159 | binary packages of libxml, but you can also find it in the tar source | 
|  | 160 | distribution). Here is the sequence of callback that would be generated when | 
|  | 161 | parsing the example given before as reported by testSAX:</p> | 
|  | 162 | <pre>SAX.setDocumentLocator() | 
|  | 163 | SAX.startDocument() | 
|  | 164 | SAX.getEntity(amp) | 
|  | 165 | SAX.startElement(EXAMPLE, prop1='gnome is great', prop2='&amp; linux too') | 
|  | 166 | SAX.characters(   , 3) | 
|  | 167 | SAX.startElement(head) | 
|  | 168 | SAX.characters(    , 4) | 
|  | 169 | SAX.startElement(title) | 
|  | 170 | SAX.characters(Welcome to Gnome, 16) | 
|  | 171 | SAX.endElement(title) | 
|  | 172 | SAX.characters(   , 3) | 
|  | 173 | SAX.endElement(head) | 
|  | 174 | SAX.characters(   , 3) | 
|  | 175 | SAX.startElement(chapter) | 
|  | 176 | SAX.characters(    , 4) | 
|  | 177 | SAX.startElement(title) | 
|  | 178 | SAX.characters(The Linux adventure, 19) | 
|  | 179 | SAX.endElement(title) | 
|  | 180 | SAX.characters(    , 4) | 
|  | 181 | SAX.startElement(p) | 
|  | 182 | SAX.characters(bla bla bla ..., 15) | 
|  | 183 | SAX.endElement(p) | 
|  | 184 | SAX.characters(    , 4) | 
|  | 185 | SAX.startElement(image, href='linus.gif') | 
|  | 186 | SAX.endElement(image) | 
|  | 187 | SAX.characters(    , 4) | 
|  | 188 | SAX.startElement(p) | 
|  | 189 | SAX.characters(..., 3) | 
|  | 190 | SAX.endElement(p) | 
|  | 191 | SAX.characters(   , 3) | 
|  | 192 | SAX.endElement(chapter) | 
|  | 193 | SAX.characters( , 1) | 
|  | 194 | SAX.endElement(EXAMPLE) | 
|  | 195 | SAX.endDocument()</pre> | 
|  | 196 |  | 
|  | 197 | <p>Most of the other functionnalities of libxml are based on the DOM tree | 
|  | 198 | building facility, so nearly everything up to the end of this document | 
|  | 199 | presuppose the use of the standard DOM tree build. Note that the DOM tree | 
|  | 200 | itself is built by a set of registered default callbacks, without internal | 
|  | 201 | specific interface.</p> | 
|  | 202 |  | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 203 | <h2>The XML library interfaces</h2> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 204 |  | 
|  | 205 | <p>This section is directly intended to help programmers getting bootstrapped | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 206 | using the XML library from the C language. It doesn't intent to be extensive, | 
|  | 207 | I hope the automatically generated docs will provide the completeness | 
|  | 208 | required, but as a separated set of documents. The interfaces of the XML | 
|  | 209 | library are by principle low level, there is nearly zero abstration. Those | 
| Daniel Veillard | c8eab3a | 1999-09-04 18:27:23 +0000 | [diff] [blame] | 210 | interested in a higher level API should <a href="#DOM">look at DOM</a>.</p> | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 211 |  | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 212 | <h3>Invoking the parser</h3> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 213 |  | 
|  | 214 | <p>Usually, the first thing to do is to read an XML input, the parser accepts | 
|  | 215 | to parse both memory mapped documents or direct files. The functions are | 
|  | 216 | defined in "parser.h":</p> | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 217 | <dl> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 218 | <dt><code>xmlDocPtr xmlParseMemory(char *buffer, int size);</code></dt> | 
|  | 219 | <dd><p>parse a zero terminated string containing the document</p> | 
|  | 220 | </dd> | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 221 | </dl> | 
|  | 222 | <dl> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 223 | <dt><code>xmlDocPtr xmlParseFile(const char *filename);</code></dt> | 
|  | 224 | <dd><p>parse an XML document contained in a file (possibly compressed)</p> | 
|  | 225 | </dd> | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 226 | </dl> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 227 |  | 
|  | 228 | <p>This returns a pointer to the document structure (or NULL in case of | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 229 | failure).</p> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 230 |  | 
|  | 231 | <p>A couple of comments can be made, first this mean that the parser is | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 232 | memory-hungry, first to load the document in memory, second to build the tree. | 
|  | 233 | Reading a document without building the tree will be possible in the future by | 
|  | 234 | pluggin the code to the SAX interface (see SAX.c).</p> | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 235 |  | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 236 | <h3>Building a tree from scratch</h3> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 237 |  | 
|  | 238 | <p>The other way to get an XML tree in memory is by building it. Basically | 
|  | 239 | there is a set of functions dedicated to building new elements, those are also | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 240 | described in "tree.h", here is for example the piece of code producing the | 
|  | 241 | example used before:</p> | 
|  | 242 | <pre>    xmlDocPtr doc; | 
|  | 243 | xmlNodePtr tree, subtree; | 
|  | 244 |  | 
|  | 245 | doc = xmlNewDoc("1.0"); | 
|  | 246 | doc->root = xmlNewDocNode(doc, NULL, "EXAMPLE", NULL); | 
|  | 247 | xmlSetProp(doc->root, "prop1", "gnome is great"); | 
|  | 248 | xmlSetProp(doc->root, "prop2", "&linux; too"); | 
|  | 249 | tree = xmlNewChild(doc->root, NULL, "head", NULL); | 
|  | 250 | subtree = xmlNewChild(tree, NULL, "title", "Welcome to Gnome"); | 
|  | 251 | tree = xmlNewChild(doc->root, NULL, "chapter", NULL); | 
|  | 252 | subtree = xmlNewChild(tree, NULL, "title", "The Linux adventure"); | 
|  | 253 | subtree = xmlNewChild(tree, NULL, "p", "bla bla bla ..."); | 
|  | 254 | subtree = xmlNewChild(tree, NULL, "image", NULL); | 
|  | 255 | xmlSetProp(subtree, "href", "linus.gif");</pre> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 256 |  | 
|  | 257 | <p>Not really rocket science ...</p> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 258 |  | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 259 | <h3>Traversing the tree</h3> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 260 |  | 
|  | 261 | <p>Basically by including "tree.h" your code has access to the internal | 
|  | 262 | structure of all the element of the tree. The names should be somewhat simple | 
|  | 263 | like <strong>parent</strong>, <strong>childs</strong>, <strong>next</strong>, | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 264 | <strong>prev</strong>, <strong>properties</strong>, etc... For example still | 
|  | 265 | with the previous example:</p> | 
|  | 266 | <pre><code>doc->root->childs->childs</code></pre> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 267 |  | 
|  | 268 | <p>points to the title element,</p> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 269 | <pre>doc->root->childs->next->child->child</pre> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 270 |  | 
|  | 271 | <p>points to the text node containing the chapter titlle "The Linux adventure" | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 272 | and</p> | 
|  | 273 | <pre>doc->root->properties->next->val</pre> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 274 |  | 
|  | 275 | <p>points to the entity reference containing the value of "&linux" at the | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 276 | beginning of the second attribute of the root element "EXAMPLE".</p> | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 277 |  | 
|  | 278 | <h3>Modifying the tree</h3> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 279 |  | 
|  | 280 | <p>functions are provided to read and write the document content:</p> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 281 | <dl> | 
| Daniel Veillard | dd6b367 | 1999-09-23 22:19:22 +0000 | [diff] [blame^] | 282 | <dt><code>xmlAttrPtr xmlSetProp(xmlNodePtr node, const xmlChar *name, const | 
|  | 283 | xmlChar *value);</code></dt> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 284 | <dd><p>This set (or change) an attribute carried by an ELEMENT node the | 
|  | 285 | value can be NULL</p> | 
|  | 286 | </dd> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 287 | </dl> | 
|  | 288 | <dl> | 
| Daniel Veillard | dd6b367 | 1999-09-23 22:19:22 +0000 | [diff] [blame^] | 289 | <dt><code>const xmlChar *xmlGetProp(xmlNodePtr node, const xmlChar | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 290 | *name);</code></dt> | 
|  | 291 | <dd><p>This function returns a pointer to the property content, note that | 
|  | 292 | no extra copy is made</p> | 
|  | 293 | </dd> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 294 | </dl> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 295 |  | 
|  | 296 | <p>Two functions must be used to read an write the text associated to | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 297 | elements:</p> | 
|  | 298 | <dl> | 
| Daniel Veillard | dd6b367 | 1999-09-23 22:19:22 +0000 | [diff] [blame^] | 299 | <dt><code>xmlNodePtr xmlStringGetNodeList(xmlDocPtr doc, const xmlChar | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 300 | *value);</code></dt> | 
|  | 301 | <dd><p>This function takes an "external" string and convert it to one text | 
|  | 302 | node or possibly to a list of entity and text nodes. All non-predefined | 
|  | 303 | entity references like &Gnome; will be stored internally as an | 
|  | 304 | entity node, hence the result of the function may not be a single | 
|  | 305 | node.</p> | 
|  | 306 | </dd> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 307 | </dl> | 
|  | 308 | <dl> | 
| Daniel Veillard | dd6b367 | 1999-09-23 22:19:22 +0000 | [diff] [blame^] | 309 | <dt><code>xmlChar *xmlNodeListGetString(xmlDocPtr doc, xmlNodePtr list, int | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 310 | inLine);</code></dt> | 
|  | 311 | <dd><p>this is the dual function, which generate a new string containing | 
|  | 312 | the content of the text and entity nodes. Note the extra argument | 
|  | 313 | inLine, if set to 1 instead of returning the &Gnome; XML encoding in | 
|  | 314 | the string it will substitute it with it's value say "GNU Network Object | 
|  | 315 | Model Environment". Set it if you want to use the string for non XML | 
|  | 316 | usage like User Interface.</p> | 
|  | 317 | </dd> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 318 | </dl> | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 319 |  | 
|  | 320 | <h3>Saving a tree</h3> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 321 |  | 
|  | 322 | <p>Basically 3 options are possible:</p> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 323 | <dl> | 
| Daniel Veillard | dd6b367 | 1999-09-23 22:19:22 +0000 | [diff] [blame^] | 324 | <dt><code>void xmlDocDumpMemory(xmlDocPtr cur, xmlChar**mem, int | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 325 | *size);</code></dt> | 
|  | 326 | <dd><p>returns a buffer where the document has been saved</p> | 
|  | 327 | </dd> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 328 | </dl> | 
|  | 329 | <dl> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 330 | <dt><code>extern void xmlDocDump(FILE *f, xmlDocPtr doc);</code></dt> | 
|  | 331 | <dd><p>dumps a buffer to an open file descriptor</p> | 
|  | 332 | </dd> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 333 | </dl> | 
|  | 334 | <dl> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 335 | <dt><code>int xmlSaveFile(const char *filename, xmlDocPtr cur);</code></dt> | 
|  | 336 | <dd><p>save the document ot a file. In that case the compression interface | 
|  | 337 | is triggered if turned on</p> | 
|  | 338 | </dd> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 339 | </dl> | 
| Daniel Veillard | 10c6a8f | 1998-10-28 01:00:12 +0000 | [diff] [blame] | 340 |  | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 341 | <h3>Compression</h3> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 342 |  | 
|  | 343 | <p>The library handle transparently compression when doing file based | 
|  | 344 | accesses, the level of compression on saves can be tuned either globally or | 
|  | 345 | individually for one file:</p> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 346 | <dl> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 347 | <dt><code>int  xmlGetDocCompressMode (xmlDocPtr doc);</code></dt> | 
|  | 348 | <dd><p>Get the document compression ratio (0-9)</p> | 
|  | 349 | </dd> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 350 | </dl> | 
|  | 351 | <dl> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 352 | <dt><code>void xmlSetDocCompressMode (xmlDocPtr doc, int mode);</code></dt> | 
|  | 353 | <dd><p>Set the document compression ratio</p> | 
|  | 354 | </dd> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 355 | </dl> | 
|  | 356 | <dl> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 357 | <dt><code>int  xmlGetCompressMode(void);</code></dt> | 
|  | 358 | <dd><p>Get the default compression ratio</p> | 
|  | 359 | </dd> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 360 | </dl> | 
|  | 361 | <dl> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 362 | <dt><code>void xmlSetCompressMode(int mode);</code></dt> | 
|  | 363 | <dd><p>set the default compression ratio</p> | 
|  | 364 | </dd> | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 365 | </dl> | 
|  | 366 |  | 
| Daniel Veillard | c8eab3a | 1999-09-04 18:27:23 +0000 | [diff] [blame] | 367 | <h2>Entities or no entities</h2> | 
|  | 368 |  | 
|  | 369 | <p>Entities principle is similar to simple C macros. They define an | 
|  | 370 | abbreviation for a given string that you can reuse many time through the | 
|  | 371 | content of your document. They are especially useful when frequent occurrences | 
|  | 372 | of a given string may occur within a document or to confine the change needed | 
|  | 373 | to a document to a restricted area in the internal subset of the document (at | 
|  | 374 | the beginning). Example:</p> | 
|  | 375 | <pre>1 <?xml version="1.0"?> | 
|  | 376 | 2 <!DOCTYPE EXAMPLE SYSTEM "example.dtd" [ | 
|  | 377 | 3 <!ENTITY xml "Extensible Markup Language"> | 
|  | 378 | 4 ]> | 
|  | 379 | 5 <EXAMPLE> | 
|  | 380 | 6    &xml; | 
|  | 381 | 7 </EXAMPLE> | 
|  | 382 |  | 
|  | 383 | </pre> | 
|  | 384 |  | 
|  | 385 | <p>Line 3 declares the xml entity. Line 6 uses the xml entity, by prefixing | 
|  | 386 | it's name with '&' and following it by ';' without any spaces added. | 
|  | 387 | There are 5 predefined entities in libxml allowing to escape charaters with | 
|  | 388 | predefined meaning in some parts of the xml document content: | 
|  | 389 | <strong>&lt;</strong> for the letter '<', <strong>&gt;</strong> for | 
|  | 390 | the letter '>',  <strong>&apos;</strong> for the letter ''', | 
|  | 391 | <strong>&quot;</strong> for the letter '"', and | 
|  | 392 | <strong>&amp;</strong> for the letter '&'.</p> | 
|  | 393 |  | 
|  | 394 | <p>One of the problems related to entities is that you may want the parser to | 
|  | 395 | substitute entities content to see the replacement text in your application, | 
|  | 396 | or you may prefer keeping entities references as such in the content to be | 
|  | 397 | able to save the document back without loosing this usually precious | 
|  | 398 | information (if the user went through the pain of explicitley defining | 
|  | 399 | entities, he may have a a rather negative attitude if you blindly susbtitute | 
|  | 400 | them as saving time). The function <a | 
|  | 401 | href="gnome-xml-parser.html#XMLSUBSTITUTEENTITIESDEFAULT">xmlSubstituteEntitiesDefault()</a> | 
|  | 402 | allows to check and change the behaviour, which is to not substitute entities | 
|  | 403 | by default.</p> | 
|  | 404 |  | 
|  | 405 | <p>Here is the DOM tree built by libxml for the previous document in the | 
|  | 406 | default case:</p> | 
|  | 407 | <pre>/gnome/src/gnome-xml -> ./tester --debug test/ent1 | 
|  | 408 | DOCUMENT | 
|  | 409 | version=1.0 | 
|  | 410 | ELEMENT EXAMPLE | 
|  | 411 | TEXT | 
|  | 412 | content= | 
|  | 413 | ENTITY_REF | 
|  | 414 | INTERNAL_GENERAL_ENTITY xml | 
|  | 415 | content=Extensible Markup Language | 
|  | 416 | TEXT | 
|  | 417 | content=</pre> | 
|  | 418 |  | 
|  | 419 | <p>And here is the result when substituting entities:</p> | 
|  | 420 | <pre>/gnome/src/gnome-xml -> ./tester --debug --noent test/ent1 | 
|  | 421 | DOCUMENT | 
|  | 422 | version=1.0 | 
|  | 423 | ELEMENT EXAMPLE | 
|  | 424 | TEXT | 
|  | 425 | content=     Extensible Markup Language</pre> | 
|  | 426 |  | 
|  | 427 | <p>So entities or no entities ? Basically it depends on your use case, I | 
|  | 428 | suggest to keep the non-substituting default behaviour and avoid using | 
|  | 429 | entities in your XML document or data if you are not willing to handle the | 
|  | 430 | entity references elements in the DOM tree.</p> | 
|  | 431 |  | 
|  | 432 | <p>Note that at save time libxml enforce the conversion of the predefined | 
|  | 433 | entities where necessary to prevent well-formedness problems, and will also | 
|  | 434 | transparently replace those with chars (i.e. will not generate entity | 
|  | 435 | reference elements in the DOM tree nor call the reference() SAX callback when | 
|  | 436 | finding them in the input).</p> | 
|  | 437 |  | 
|  | 438 | <h2>Namespaces</h2> | 
|  | 439 |  | 
|  | 440 | <p>The libxml library implement namespace @@ support by recognizing namespace | 
|  | 441 | contructs in the input, and does namespace lookup automatically when building | 
|  | 442 | the DOM tree. A namespace declaration is associated with an in-memory | 
|  | 443 | structure and all elements or attributes within that namespace point to it. | 
|  | 444 | Hence testing the namespace is a simple and fast equality operation at the | 
|  | 445 | user level. </p> | 
|  | 446 |  | 
|  | 447 | <p>I suggest it that people using libxml use a namespace, and declare it on | 
|  | 448 | the root element of their document as the default namespace. Then they dont | 
|  | 449 | need to happend the prefix in the content but we will have a basis for future | 
|  | 450 | semantic refinement and  merging of data from different sources. This doesn't | 
|  | 451 | augment significantly the size of the XML output, but significantly increase | 
|  | 452 | it's value in the long-term.</p> | 
|  | 453 |  | 
|  | 454 | <p>Concerning the namespace value, this has to be an URL, but this doesn't | 
|  | 455 | have to point to any existing resource on the Web. I suggest using an URL | 
|  | 456 | within a domain you control, which makes sense and if possible holding some | 
|  | 457 | kind of versionning informations. For example | 
|  | 458 | <code>"http://www.gnome.org/gnumeric/1.0"</code> is a good namespace scheme. | 
|  | 459 | Then when you load a file, make sure that a namespace carrying the | 
|  | 460 | version-independant prefix is installed on the root element of your document, | 
|  | 461 | and if the version information don't match something you know, warn the user | 
|  | 462 | and be liberal in what you accept as the input. Also do *not* try to base | 
|  | 463 | namespace checking on the prefix value <foo:text> may be exactly the same | 
|  | 464 | as <bar:text>  in another document, what really matter is the URI | 
|  | 465 | associated with the element or the attribute, not the prefix string which is | 
|  | 466 | just a shortcut for the full URI.</p> | 
|  | 467 |  | 
|  | 468 | <p>@@Interfaces@@</p> | 
|  | 469 |  | 
|  | 470 | <p>@@Examples@@</p> | 
|  | 471 |  | 
|  | 472 | <p>Usually people object using namespace in the case of validation, I object | 
|  | 473 | this and will make sure that using namespaces won't break validity checking, | 
|  | 474 | so even is you plan or are using validation I strongly suggest to add | 
|  | 475 | namespaces to your document. A default namespace scheme | 
|  | 476 | <code>xmlns="http://...."</code> should not break validity even on less | 
|  | 477 | flexible parsers. Now using namespace to mix and differenciate content coming | 
|  | 478 | from mutliple Dtd will certainly break current validation schemes, I will try | 
|  | 479 | to provide ways to do this, but this may not be portable or standardized.</p> | 
|  | 480 |  | 
|  | 481 | <h2>Validation, or are you afraid of DTDs ?</h2> | 
|  | 482 |  | 
|  | 483 | <p>Well what is validation and what is a DTD ?</p> | 
|  | 484 |  | 
|  | 485 | <p>Validation is the process of checking a document against a set of | 
|  | 486 | construction rules, a <strong>DTD</strong> (Document Type Definition) is such | 
|  | 487 | a set of rules.</p> | 
|  | 488 |  | 
|  | 489 | <p>The validation process and building DTDs are the two most difficult parts | 
|  | 490 | of  XML life cycle. Briefly a DTD defines all the possibles element to be | 
|  | 491 | found within your document, what is the formal shape of your document tree (by | 
|  | 492 | defining the allowed content of an element, either text, a regular expression | 
|  | 493 | for the allowed list of children, or mixed content i.e. both text and childs). | 
|  | 494 | The DTD also defines the allowed attributes for all elements and the types of | 
|  | 495 | the attributes. For more detailed informations, I suggest to read the related | 
|  | 496 | parts of the XML specification, the examples found under | 
|  | 497 | gnome-xml/test/valid/dtd and the large amount of books available on XML. The | 
|  | 498 | dia example in gnome-xml/test/valid should be both simple and complete enough | 
|  | 499 | to allow you to build your own.</p> | 
|  | 500 |  | 
|  | 501 | <p>A word of warning, building a good DTD which will fit your needs of your | 
|  | 502 | application in the long-term is far from trivial, however the extra level of | 
|  | 503 | quality it can insure is well worth the price for some sets of applications or | 
|  | 504 | if you already have already a DTD defined for your application field.</p> | 
|  | 505 |  | 
|  | 506 | <p>The validation is not completely finished but in a (very IMHO) usable | 
|  | 507 | state. Until a real validation interface is defined the way to do it is to | 
|  | 508 | define and set the <strong>xmlDoValidityCheckingDefaultValue</strong> external | 
|  | 509 | variable to 1, this will of course be changed at some point:</p> | 
|  | 510 |  | 
|  | 511 | <p>extern int xmlDoValidityCheckingDefaultValue;</p> | 
|  | 512 |  | 
|  | 513 | <p>...</p> | 
|  | 514 |  | 
|  | 515 | <p>xmlDoValidityCheckingDefaultValue = 1;</p> | 
|  | 516 |  | 
|  | 517 | <p></p> | 
|  | 518 |  | 
|  | 519 | <p>To handle external entities, use the function | 
|  | 520 | <strong>xmlSetExternalEntityLoader</strong>(xmlExternalEntityLoader f); to | 
|  | 521 | link in you HTTP/FTP/Entities database library to the standard libxml | 
|  | 522 | core.</p> | 
|  | 523 |  | 
|  | 524 | <p>@@interfaces@@</p> | 
|  | 525 |  | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 526 | <h2><a name="DOM">DOM Principles</a></h2> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 527 |  | 
|  | 528 | <p><a href="http://www.w3.org/DOM/">DOM</a> stands for the <em>Document Object | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 529 | Model</em> this is an API for accessing XML or HTML structured documents. | 
|  | 530 | Native support for DOM in Gnome is on the way (module gnome-dom), and it will | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 531 | be based on gnome-xml. This will be a far cleaner interface to manipulate XML | 
| Daniel Veillard | c08a2c6 | 1999-09-08 21:35:25 +0000 | [diff] [blame] | 532 | files within Gnome since it won't expose the internal structure. DOM defines a | 
| Daniel Veillard | 25940b7 | 1998-10-29 05:51:30 +0000 | [diff] [blame] | 533 | set of IDL (or Java) interfaces allowing to traverse and manipulate a | 
|  | 534 | document. The DOM library will allow accessing and modifying "live" documents | 
|  | 535 | presents on other programs like this:</p> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 536 |  | 
|  | 537 | <p><img src="DOM.gif" alt=" DOM.gif "></p> | 
|  | 538 |  | 
|  | 539 | <p>This should help greatly doing things like modifying a gnumeric spreadsheet | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 540 | embedded in a GWP document for example.</p> | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 541 |  | 
| Daniel Veillard | c8eab3a | 1999-09-04 18:27:23 +0000 | [diff] [blame] | 542 | <p>The current DOM implementation on top of libxml is the <a | 
|  | 543 | href="http://cvs.gnome.org/lxr/source/gdome/">gdome Gnome module</a>, this is | 
|  | 544 | a full DOM interface, thanks to <a href="mailto:raph@levien.com">Raph | 
|  | 545 | Levien</a>.</p> | 
|  | 546 |  | 
|  | 547 | <p>The gnome-dom module in the Gnome CVS base is obsolete</p> | 
|  | 548 |  | 
|  | 549 | <h2><a name="Example">A real example</a></h2> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 550 |  | 
|  | 551 | <p>Here is a real size example, where the actual content of the application | 
|  | 552 | data is not kept in the DOM tree but uses internal structures. It is based on | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 553 | a proposal to keep a database of jobs related to Gnome, with an XML based | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 554 | storage structure. Here is an <a href="gjobs.xml">XML encoded jobs | 
|  | 555 | base</a>:</p> | 
|  | 556 | <pre><?xml version="1.0"?> | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 557 | <gjob:Helping xmlns:gjob="http://www.gnome.org/some-location"> | 
|  | 558 | <gjob:Jobs> | 
|  | 559 |  | 
|  | 560 | <gjob:Job> | 
|  | 561 | <gjob:Project ID="3"/> | 
|  | 562 | <gjob:Application>GBackup</gjob:Application> | 
|  | 563 | <gjob:Category>Development</gjob:Category> | 
|  | 564 |  | 
|  | 565 | <gjob:Update> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 566 | <gjob:Status>Open</gjob:Status> | 
|  | 567 | <gjob:Modified>Mon, 07 Jun 1999 20:27:45 -0400 MET DST</gjob:Modified> | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 568 | <gjob:Salary>USD 0.00</gjob:Salary> | 
|  | 569 | </gjob:Update> | 
|  | 570 |  | 
|  | 571 | <gjob:Developers> | 
|  | 572 | <gjob:Developer> | 
|  | 573 | </gjob:Developer> | 
|  | 574 | </gjob:Developers> | 
|  | 575 |  | 
|  | 576 | <gjob:Contact> | 
|  | 577 | <gjob:Person>Nathan Clemons</gjob:Person> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 578 | <gjob:Email>nathan@windsofstorm.net</gjob:Email> | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 579 | <gjob:Company> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 580 | </gjob:Company> | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 581 | <gjob:Organisation> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 582 | </gjob:Organisation> | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 583 | <gjob:Webpage> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 584 | </gjob:Webpage> | 
|  | 585 | <gjob:Snailmail> | 
|  | 586 | </gjob:Snailmail> | 
|  | 587 | <gjob:Phone> | 
|  | 588 | </gjob:Phone> | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 589 | </gjob:Contact> | 
|  | 590 |  | 
|  | 591 | <gjob:Requirements> | 
|  | 592 | The program should be released as free software, under the GPL. | 
|  | 593 | </gjob:Requirements> | 
|  | 594 |  | 
|  | 595 | <gjob:Skills> | 
|  | 596 | </gjob:Skills> | 
|  | 597 |  | 
|  | 598 | <gjob:Details> | 
|  | 599 | A GNOME based system that will allow a superuser to configure | 
|  | 600 | compressed and uncompressed files and/or file systems to be backed | 
|  | 601 | up with a supported media in the system.  This should be able to | 
|  | 602 | perform via find commands generating a list of files that are passed | 
|  | 603 | to tar, dd, cpio, cp, gzip, etc., to be directed to the tape machine | 
|  | 604 | or via operations performed on the filesystem itself. Email | 
|  | 605 | notification and GUI status display very important. | 
|  | 606 | </gjob:Details> | 
|  | 607 |  | 
|  | 608 | </gjob:Job> | 
|  | 609 |  | 
|  | 610 | </gjob:Jobs> | 
| Daniel Veillard | c8eab3a | 1999-09-04 18:27:23 +0000 | [diff] [blame] | 611 | </gjob:Helping></pre> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 612 |  | 
|  | 613 | <p>While loading the XML file into an internal DOM tree is a matter of calling | 
|  | 614 | only a couple of functions, browsing the tree to gather the informations and | 
|  | 615 | generate the internals structures is harder, and more error prone.</p> | 
|  | 616 |  | 
|  | 617 | <p>The suggested principle is to be tolerant with respect to the input | 
|  | 618 | structure. For example the ordering of the attributes is not significant, Cthe | 
|  | 619 | XML specification is clear about it. It's also usually a good idea to not be | 
|  | 620 | dependant of the orders of the childs of a given node, unless it really makes | 
|  | 621 | things harder. Here is some code to parse the informations for a person:</p> | 
|  | 622 | <pre>/* | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 623 | * A person record | 
|  | 624 | */ | 
|  | 625 | typedef struct person { | 
|  | 626 | char *name; | 
|  | 627 | char *email; | 
|  | 628 | char *company; | 
|  | 629 | char *organisation; | 
|  | 630 | char *smail; | 
|  | 631 | char *webPage; | 
|  | 632 | char *phone; | 
|  | 633 | } person, *personPtr; | 
|  | 634 |  | 
|  | 635 | /* | 
|  | 636 | * And the code needed to parse it | 
|  | 637 | */ | 
|  | 638 | personPtr parsePerson(xmlDocPtr doc, xmlNsPtr ns, xmlNodePtr cur) { | 
|  | 639 | personPtr ret = NULL; | 
|  | 640 |  | 
|  | 641 | DEBUG("parsePerson\n"); | 
|  | 642 | /* | 
|  | 643 | * allocate the struct | 
|  | 644 | */ | 
|  | 645 | ret = (personPtr) malloc(sizeof(person)); | 
|  | 646 | if (ret == NULL) { | 
|  | 647 | fprintf(stderr,"out of memory\n"); | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 648 | return(NULL); | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 649 | } | 
|  | 650 | memset(ret, 0, sizeof(person)); | 
|  | 651 |  | 
|  | 652 | /* We don't care what the top level element name is */ | 
|  | 653 | cur = cur->childs; | 
|  | 654 | while (cur != NULL) { | 
|  | 655 | if ((!strcmp(cur->name, "Person")) && (cur->ns == ns)) | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 656 | ret->name = xmlNodeListGetString(doc, cur->childs, 1); | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 657 | if ((!strcmp(cur->name, "Email")) && (cur->ns == ns)) | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 658 | ret->email = xmlNodeListGetString(doc, cur->childs, 1); | 
|  | 659 | cur = cur->next; | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 660 | } | 
|  | 661 |  | 
|  | 662 | return(ret); | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 663 | }</pre> | 
|  | 664 |  | 
|  | 665 | <p>Here is a couple of things to notice:</p> | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 666 | <ul> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 667 | <li>Usually a recursive parsing style is the more convenient one, XML data | 
|  | 668 | being by nature subject to repetitive constructs and usualy exibit highly | 
|  | 669 | stuctured patterns.</li> | 
|  | 670 | <li>The two arguments of type <em>xmlDocPtr</em> and <em>xmlNsPtr</em>, i.e. | 
|  | 671 | the pointer to the global XML document and the namespace reserved to the | 
|  | 672 | application. Document wide information are needed for example to decode | 
|  | 673 | entities and it's a good coding practice to define a namespace for your | 
|  | 674 | application set of data and test that the element and attributes you're | 
|  | 675 | analyzing actually pertains to your application space. This is done by a | 
|  | 676 | simple equality test (cur->ns == ns).</li> | 
|  | 677 | <li>To retrieve text and attributes value, it is suggested to use the | 
|  | 678 | function <em>xmlNodeListGetString</em> to gather all the text and entity | 
|  | 679 | reference nodes generated by the DOM output and produce an single text | 
|  | 680 | string.</li> | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 681 | </ul> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 682 |  | 
|  | 683 | <p>Here is another piece of code used to parse another level of the | 
|  | 684 | structure:</p> | 
|  | 685 | <pre>/* | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 686 | * a Description for a Job | 
|  | 687 | */ | 
|  | 688 | typedef struct job { | 
|  | 689 | char *projectID; | 
|  | 690 | char *application; | 
|  | 691 | char *category; | 
|  | 692 | personPtr contact; | 
|  | 693 | int nbDevelopers; | 
|  | 694 | personPtr developers[100]; /* using dynamic alloc is left as an exercise */ | 
|  | 695 | } job, *jobPtr; | 
|  | 696 |  | 
|  | 697 | /* | 
|  | 698 | * And the code needed to parse it | 
|  | 699 | */ | 
|  | 700 | jobPtr parseJob(xmlDocPtr doc, xmlNsPtr ns, xmlNodePtr cur) { | 
|  | 701 | jobPtr ret = NULL; | 
|  | 702 |  | 
|  | 703 | DEBUG("parseJob\n"); | 
|  | 704 | /* | 
|  | 705 | * allocate the struct | 
|  | 706 | */ | 
|  | 707 | ret = (jobPtr) malloc(sizeof(job)); | 
|  | 708 | if (ret == NULL) { | 
|  | 709 | fprintf(stderr,"out of memory\n"); | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 710 | return(NULL); | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 711 | } | 
|  | 712 | memset(ret, 0, sizeof(job)); | 
|  | 713 |  | 
|  | 714 | /* We don't care what the top level element name is */ | 
|  | 715 | cur = cur->childs; | 
|  | 716 | while (cur != NULL) { | 
|  | 717 |  | 
|  | 718 | if ((!strcmp(cur->name, "Project")) && (cur->ns == ns)) { | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 719 | ret->projectID = xmlGetProp(cur, "ID"); | 
|  | 720 | if (ret->projectID == NULL) { | 
|  | 721 | fprintf(stderr, "Project has no ID\n"); | 
|  | 722 | } | 
|  | 723 | } | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 724 | if ((!strcmp(cur->name, "Application")) && (cur->ns == ns)) | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 725 | ret->application = xmlNodeListGetString(doc, cur->childs, 1); | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 726 | if ((!strcmp(cur->name, "Category")) && (cur->ns == ns)) | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 727 | ret->category = xmlNodeListGetString(doc, cur->childs, 1); | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 728 | if ((!strcmp(cur->name, "Contact")) && (cur->ns == ns)) | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 729 | ret->contact = parsePerson(doc, ns, cur); | 
|  | 730 | cur = cur->next; | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 731 | } | 
|  | 732 |  | 
|  | 733 | return(ret); | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 734 | }</pre> | 
| Daniel Veillard | 14fff06 | 1999-06-22 21:49:07 +0000 | [diff] [blame] | 735 |  | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 736 | <p>One can notice that once used to it, writing this kind of code is quite | 
|  | 737 | simple, but boring. Ultimately, it could be possble to write stubbers taking | 
|  | 738 | either C data structure definitions, a set of XML examples or an XML DTD and | 
|  | 739 | produce the code needed to import and export the content between C data and | 
|  | 740 | XML storage. This is left as an exercise to the reader :-)</p> | 
|  | 741 |  | 
|  | 742 | <p>Feel free to use <a href="gjobread.c">the code for the full C parsing | 
| Daniel Veillard | c8eab3a | 1999-09-04 18:27:23 +0000 | [diff] [blame] | 743 | example</a> as a template, it is also available with Makefile in the Gnome CVS | 
|  | 744 | base under gnome-xml/example</p> | 
| Daniel Veillard | b05deb7 | 1999-08-10 19:04:08 +0000 | [diff] [blame] | 745 |  | 
| Daniel Veillard | c8eab3a | 1999-09-04 18:27:23 +0000 | [diff] [blame] | 746 | <p></p> | 
|  | 747 |  | 
|  | 748 | <p><a href="mailto:Daniel.Veillard@w3.org">Daniel Veillard</a></p> | 
|  | 749 |  | 
| Daniel Veillard | dd6b367 | 1999-09-23 22:19:22 +0000 | [diff] [blame^] | 750 | <p>$Id: xml.html,v 1.8 1999/09/08 21:35:25 veillard Exp $</p> | 
| Daniel Veillard | ccb0963 | 1998-10-27 06:21:04 +0000 | [diff] [blame] | 751 | </body> | 
|  | 752 | </html> |