Well, bugs or missing features are always possible, and I will make a point -of fixing them in a timely fashion. The best way to report a bug is to use the -Gnome bug -tracking database (make sure to use the "libxml" module name). I look at -reports there regularly and it's good to have a reminder when a bug is still -open. Check the instructions on reporting -bugs and be sure to specify that the bug is for the package libxml.
+Well, bugs or missing features are always possible, and I will make a +point of fixing them in a timely fashion. The best way to report a bug is to +use the Gnome +bug tracking database (make sure to use the "libxml" module name). I look +at reports there regularly and it's good to have a reminder when a bug is +still open. Check the instructions on +reporting bugs and be sure to specify that the bug is for the package +libxml.
There is also a mailing-list xml@gnome.org for libxml, with an on-line archive (old). To subscribe to this list, please -visit the associated -Web page and follow the instructions. Do not send code, I won't -debug it (but patches are really appreciated!).
+href="http://xmlsoft.org/messages">old). To subscribe to this list, +please visit the associated Web page and +follow the instructions. Do not send code, I won't debug it +(but patches are really appreciated!).Check the following too before posting:
Alternatively, you can just send the bug to the xml@gnome.org list; if it's really libxml -related I will approve it.. Please do not send me mail directly especially for -portability problem, it makes things really harder to track and in some cases -I'm not the best person to answer a given question, ask the list instead.
+related I will approve it.. Please do not send me mail directly especially +for portability problem, it makes things really harder to track and in some +cases I'm not the best person to answer a given question, ask the list +instead.Of course, bugs reported with a suggested patch for fixing them will probably be processed faster.
@@ -219,8 +223,8 @@ href="http://rpmfind.net/linux/RPM/libxml2-devel.html">libxml(2)-devel packages installed to compile applications using libxml.) Igor Zlatkovic is now the maintainer of the Windows port, he provides -binaries +href="http://www.fh-frankfurt.de/~igor/projects/libxml/index.html">he +provides binariesThe Gnome CVS base. Check the Gnome CVS Tools page; - the CVS module is gnome-xml.
+ href="http://developer.gnome.org/tools/cvs.html">Gnome CVS Tools + page; the CVS module is gnome-xml.Items floating around but not actively worked on, get in touch with me if you want to test those
/> rather than with >. Note that,
-for example, the image tag has no content (just an attribute) and is closed by
-ending the tag with />.
+(no content), a single tag can serve as both the opening and closing tag if
+it ends with /> rather than with >. Note
+that, for example, the image tag has no content (just an attribute) and is
+closed by ending the tag with />.
XML can be applied sucessfully to a wide range of uses, from long term -structured document maintenance (where it follows the steps of SGML) to simple -data encoding mechanisms like configuration file formatting (glade), +structured document maintenance (where it follows the steps of SGML) to +simple data encoding mechanisms like configuration file formatting (glade), spreadsheets (gnumeric), or even shorter lived documents such as WebDAV where it is used to encode remote calls between a client and a server.
@@ -849,16 +872,16 @@ it is used to encode remote calls between a client and a server.Check the separate libxslt page
-XSL Transformations, is a language -for transforming XML documents into other XML documents (or HTML/textual -output).
+XSL Transformations, is a +language for transforming XML documents into other XML documents (or +HTML/textual output).
A separate library called libxslt is being built on top of libxml2. This module "libxslt" can be found in the Gnome CVS base too.
You can check the features supported -and the progresses on the features +supported and the progresses on the Changelog
Sometimes the DOM tree output is just too large to fit reasonably into memory. In that case (and if you don't expect to save back the XML document -loaded using libxml), it's better to use the SAX interface of libxml. SAX is a -callback-based interface to the parser. Before parsing, the -application layer registers a customized set of callbacks which are called by -the library as it progresses through the XML input.
+loaded using libxml), it's better to use the SAX interface of libxml. SAX is +a callback-based interface to the parser. Before parsing, +the application layer registers a customized set of callbacks which are +called by the library as it progresses through the XML input.To get more detailed step-by-step guidance on using the SAX interface of
libxml, see the
This section is directly intended to help programmers getting bootstrapped
-using the XML library from the C language. It is not intended to be extensive.
-I hope the automatically generated documents will provide the completeness
-required, but as a separate set of documents. The interfaces of the XML
-library are by principle low level, there is nearly zero abstraction. Those
-interested in a higher level API should look at DOM.The XML library interfaces
The parser interfaces for XML are separated from the HTML parser @@ -1038,8 +1062,8 @@ failure).
In order for the application to keep the control when the document is being -fetched (which is common for GUI based programs) libxml provides a push +
In order for the application to keep the control when the document is +being fetched (which is common for GUI based programs) libxml provides a push interface, too, as of version 1.8.3. Here are the interface functions:
xmlParserCtxtPtr xmlCreatePushParserCtxt(xmlSAXHandlerPtr sax,
void *user_data,
@@ -1090,8 +1114,8 @@ limited to SAX: just use the two first arguments of
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. (These are
-also described in <libxml/tree.h>.) For example, here is a piece of code
-that produces the XML document used in the previous examples:
+also described in <libxml/tree.h>.) For example, here is a piece of
+code that produces the XML document used in the previous examples:
#include <libxml/tree.h>
xmlDocPtr doc;
xmlNodePtr tree, subtree;
@@ -1113,8 +1137,8 @@ that produces the XML document used in the previous examples:
Traversing the tree
Basically by including "tree.h" your
-code has access to the internal structure of all the elements of the tree. The
-names should be somewhat simple like parent,
+code has access to the internal structure of all the elements of the tree.
+The names should be somewhat simple like parent,
children, next, prev,
properties, etc... For example, still with the previous
example:
@@ -1138,8 +1162,8 @@ is an excerpt from the tree API:
xmlAttrPtr xmlSetProp(xmlNodePtr node, const xmlChar *name, const
xmlChar *value);This sets (or changes) an attribute carried by an ELEMENT node. The - value can be NULL.
+This sets (or changes) an attribute carried by an ELEMENT node. + The value can be NULL.
Two functions are provided for reading and writing the text associated with -elements:
+Two functions are provided for reading and writing the text associated +with elements:
xmlNodePtr xmlStringGetNodeList(xmlDocPtr doc, const xmlChar
*value);xmlns="http://...." should not break validity even on less
flexible parsers. Using namespaces to mix and differentiate content coming
-from multiple DTDs will certainly break current validation schemes. I will try
-to provide ways to do this, but this may not be portable or standardized.
+from multiple DTDs will certainly break current validation schemes. I will
+try to provide ways to do this, but this may not be portable or
+standardized.
The validation process and building DTDs are the two most difficult parts of the XML life cycle. Briefly a DTD defines all the possibles element to be -found within your document, what is the formal shape of your document tree (by -defining the allowed content of an element, either text, a regular expression -for the allowed list of children, or mixed content i.e. both text and -children). The DTD also defines the allowed attributes for all elements and -the types of the attributes. For more detailed information, I suggest that you -read the related parts of the XML specification, the examples found under -gnome-xml/test/valid/dtd and any of the large number of books available on -XML. The dia example in gnome-xml/test/valid should be both simple and +found within your document, what is the formal shape of your document tree +(by defining the allowed content of an element, either text, a regular +expression for the allowed list of children, or mixed content i.e. both text +and children). The DTD also defines the allowed attributes for all elements +and the types of the attributes. For more detailed information, I suggest +that you read the related parts of the XML specification, the examples found +under gnome-xml/test/valid/dtd and any of the large number of books available +on XML. The dia example in gnome-xml/test/valid should be both simple and complete enough to allow you to build your own.
A word of warning, building a good DTD which will fit the needs of your application in the long-term is far from trivial; however, the extra level of -quality it can ensure is well worth the price for some sets of applications or -if you already have already a DTD defined for your application field.
+quality it can ensure is well worth the price for some sets of applications +or if you already have already a DTD defined for your application field.The validation is not completely finished but in a (very IMHO) usable state. Until a real validation interface is defined the way to do it is to -define and set the xmlDoValidityCheckingDefaultValue external -variable to 1, this will of course be changed at some point:
+define and set the xmlDoValidityCheckingDefaultValue +external variable to 1, this will of course be changed at some point:extern int xmlDoValidityCheckingDefaultValue;
@@ -1397,11 +1422,12 @@ core.DOM stands for the Document Object -Model; 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 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 stands for the Document +Object Model; 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 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.
The current DOM implementation on top of libxml is the gdome2 Gnome module, this @@ -1473,13 +1499,13 @@ base:
</gjob:Jobs> </gjob:Helping> -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 ata and generate -the internal structures is harder, and more error prone.
+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 ata and +generate the internal structures is harder, and more error prone.
The suggested principle is to be tolerant with respect to the input -structure. For example, the ordering of the attributes is not significant, the -XML specification is clear about it. It's also usually a good idea not to +structure. For example, the ordering of the attributes is not significant, +the XML specification is clear about it. It's also usually a good idea not to depend on the order of the children of a given node, unless it really makes things harder. Here is some code to parse the information for a person:
/*
@@ -1530,13 +1556,13 @@ DEBUG("parsePerson\n");
Once you are 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 :-)
+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 :-)Feel free to use the code for the full C parsing example as a template, it is also available with Makefile in the @@ -1608,41 +1634,42 @@ Gnome CVS base under gnome-xml/example
Website: http://lusis.org/~ari/xml++/
$Id: xml.html,v 1.103 2001/07/26 18:30:26 veillard Exp $
+$Id: xml.html,v 1.104 2001/07/27 18:56:57 veillard Exp $