| <html> |
| <head> |
| <title>Upgrading libxml client code from 1.x to 2.x</title> |
| <meta name="GENERATOR" content="amaya V4.1"> |
| <meta http-equiv="Content-Type" content="text/html"> |
| </head> |
| |
| <body bgcolor="#ffffff"> |
| <h1 align="center">Upgrading libxml client code from 1.x to 2.x</h1> |
| |
| <h2>Incompatible changes:</h2> |
| |
| <p>Version 2 of libxml is the first version introducing serious backward |
| incompatible changes. The main goals were:</p> |
| <ul> |
| <li>a general cleanup. A number of mistakes inherited from the very early |
| versions couldn't be changed due to compatibility constraints. Example the |
| "childs" element in the nodes.</li> |
| <li>Uniformization of the various nodes, at least for their header and link |
| parts (doc, parent, children, prev, next), the goal is a simpler |
| programming model and simplifying the task of the DOM implementors.</li> |
| <li>better conformances to the XML specification, for example version 1.x |
| had an heuristic to try to detect ignorable white spaces. As a result the |
| SAX event generated were ignorableWhitespace() while the spec requires |
| character() in that case. This also mean that a number of DOM node |
| containing blank text may populate the DOM tree which were not present |
| before.</li> |
| </ul> |
| |
| <h2>How to fix libxml-1.x code:</h2> |
| |
| <p>So client code of libxml designed to run with version 1.x may have to be |
| changed to compile against version 2.x of libxml. Here is a list of changes |
| that I have collected, they may not be sufficient, so in case you find other |
| change which are required, <a href="mailto:Daniel.Ïeillardw3.org">drop me a |
| mail</a>:</p> |
| <ol> |
| <li>The package name have changed from libxml to libxml2, the library name |
| is now -lxml2 . There is a new xml2-config script which should be used to |
| select the right parameters libxml2</li> |
| <li>Node <strong>childs</strong> field has been renamed |
| <strong>children</strong> so s/childs/children/g should be applied |
| (probablility of having "childs" anywere else is close to 0+</li> |
| <li>The document don't have anymore a <strong>root</strong> element it has |
| been replaced by <strong>children</strong> and usually you will get a list |
| of element here. For example a Dtd element for the internal subset and |
| it's declaration may be found in that list, as well as processing |
| instructions or comments found before or after the document root element. |
| Use <strong>xmlDocGetRootElement(doc)</strong> to get the root element of |
| a document. Alternatively if you are sure to not reference Dtds nor have |
| PIs or comments before or after the root element |
| s/->root/->children/g will probably do it.</li> |
| <li>The white space issue, this one is more complex, unless special case of |
| validating parsing, the line breaks and spaces usually used for indenting |
| and formatting the document content becomes significant. So they are |
| reported by SAX and if your using the DOM tree, corresponding nodes are |
| generated. Too approach can be taken: |
| <ol> |
| <li>lazy one, use the compatibility call |
| <strong>xmlKeepBlanksDefault(0)</strong> but be aware that you are |
| relying on a special (and possibly broken) set of heuristics of libxml |
| to detect ignorable blanks. Don't complain if it breaks or make your |
| application not 100% clean w.r.t. to it's input.</li> |
| <li>the Right Way: change you code to accept possibly unsignificant |
| blanks characters, or have your tree populated with weird blank text |
| nodes. You can spot them using the comodity function |
| <strong>xmlIsBlankNode(node)</strong> returning 1 for such blank |
| nodes.</li> |
| </ol> |
| <p>Note also that with the new default the output functions don't add any |
| extra indentation when saving a tree in order to be able to round trip |
| (read and save) without inflating the document with extra formatting |
| chars.</p> |
| </li> |
| <li>The include path has changed to $prefix/libxml/ and the includes |
| themselves uses this new prefix in includes instructions... If you are |
| using (as expected) the |
| <pre>xml2-config --cflags</pre> |
| <p>output to generate you compile commands this will probably work out of |
| the box</p> |
| </li> |
| </ol> |
| |
| <h2>Ensuring both libxml-1.x and libxml-2.x compatibility</h2> |
| |
| <p>Two new version of libxml (1.8.11) and libxml2 (2.3.4) have been released |
| to allow smoth upgrade of existing libxml v1code while retaining |
| compatibility. They offers the following:</p> |
| <ol> |
| <li>similar include naming, one should use |
| <strong>#include<libxml/...></strong> in both cases.</li> |
| <li>similar identifiers defined via macros for the child and root fields: |
| respectively <strong>xmlChildrenNode</strong> and |
| <strong>xmlRootNode</strong></li> |
| <li>a new macro <strong>LIBXML_TEST_VERSION</strong> which should be |
| inserted once in the client code</li> |
| </ol> |
| |
| <p>So the roadmap to upgrade your existing libxml applications is the |
| following:</p> |
| <ol> |
| <li>install the libxml-1.8.8 (and libxml-devel-1.8.8) packages</li> |
| <li>find all occurences where the xmlDoc <strong>root</strong> field is used |
| and change it to <strong>xmlRootNode</strong></li> |
| <li>similary find all occurences where the xmlNode <strong>childs</strong> |
| field is used and change it to <strong>xmlChildrenNode</strong></li> |
| <li>add a <strong>LIBXML_TEST_VERSION</strong> macro somewhere in your |
| <strong>main()</strong> or in the library init entry point</li> |
| <li>Recompile, check compatibility, it should still work</li> |
| <li>Change your configure script to look first for xml2-config and fallback |
| using xml-config . Use the --cflags and --libs ouptut of the command as |
| the Include and Linking parameters needed to use libxml.</li> |
| <li>install libxml2-2.3.x and libxml2-devel-2.3.x (libxml-1.8.y and |
| libxml-devel-1.8.y can be kept simultaneously)</li> |
| <li>remove your config.cache, relaunch your configuration mechanism, and |
| recompile, if steps 2 and 3 were done right it should compile as-is</li> |
| <li>Test that your application is still running correctly, if not this may |
| be due to extra empty nodes due to formating spaces being kept in libxml2 |
| contrary to libxml1, in that case insert xmlKeepBlanksDefault(1) in your |
| code before calling the parser (next to |
| <strong>LIBXML_TEST_VERSION</strong> is a fine place).</li> |
| </ol> |
| |
| <p>Following those steps should work. It worked for some of my own code.</p> |
| |
| <p>Let me put some emphasis on the fact that there is far more changes from |
| libxml 1.x to 2.x than the ones you may have to patch for. The overall code |
| has been considerably improved and the conformance to the XML specification |
| has been drastically improve. Don't take those changes as an excuse to not |
| upgrade, it may cost a lot on the long term ...</p> |
| |
| <p><a href="mailto:Daniel.Veillard@w3.org">Daniel Veillard</a></p> |
| |
| <p>$Id: upgrade.html,v 1.7 2000/06/30 18:39:56 veillard Exp $</p> |
| </body> |
| </html> |