| <!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> |