diff --git a/ChangeLog b/ChangeLog
index 7c4bc2df..3ba430d1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+Mon Feb 26 22:09:45 CET 2001 Daniel Veillard
Libxml is made of multiple components; some of them are optional, -and most of -the block interfaces are public. The main components are:
+Libxml is made of multiple components; some of them are optional, and most +of the block interfaces are public. The main components are:
Most of the other interfaces of libxml are based on the DOM -tree-building facility, so nearly everything up to the end of this document -presupposes the use of the standard DOM tree build. Note that the DOM tree -itself is built by a set of registered default callbacks, without internal -specific interface.
+Most of the other interfaces of libxml are based on the DOM tree-building +facility, so nearly everything up to the end of this document presupposes the +use of the standard DOM tree build. Note that the DOM tree itself is built by +a set of registered default callbacks, without internal specific +interface.
The HTML parser embedded into libxml also has a push -interface; the functions are just prefixed by "html" rather than "xml".
+The HTML parser embedded into libxml also has a push interface; the +functions are just prefixed by "html" rather than "xml".
The tree-building interface makes the parser
-memory-hungry, first loading the document in memory and then building
-the tree itself.
-Reading a document without building the tree is possible using the SAX
-interfaces (see SAX.h and James
+ The tree-building interface makes the parser memory-hungry, first loading
+the document in memory and then building the tree itself. Reading a document
+without building the tree is possible using the SAX interfaces (see SAX.h and
+James
Henstridge's documentation). Note also that the push interface can be
limited to SAX: just use the two first arguments of
xmlCreatePushParserCtxt()
.
xmlNodePtr xmlStringGetNodeList(xmlDocPtr doc, const xmlChar
*value);
This function takes an "external" string and converts 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 entity - nodes, hence the result of the function may not be a single node.
+This function takes an "external" string and converts 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 entity nodes, hence the result of the function may not be + a single node.
<mydoc xmlns="http://mydoc.example.org/schemas/"> <elem1>...</elem1> <elem2>...</elem2> </mydoc>-
The namespace value has to be an absolute URL, but the URL doesn't
-have to point to any existing resource on the Web. It will bind all the
-element and atributes with that URL. I suggest to use an URL within a domain
-you control, and that the URL should contain some kind of version information
-if possible. For example, "http://www.gnome.org/gnumeric/1.0/"
is
-a good namespace scheme.
The namespace value has to be an absolute URL, but the URL doesn't have to
+point to any existing resource on the Web. It will bind all the element and
+atributes with that URL. I suggest to use an URL within a domain you control,
+and that the URL should contain some kind of version information if possible.
+For example, "http://www.gnome.org/gnumeric/1.0/"
is a good
+namespace scheme.
Then when you load a file, make sure that a namespace carrying the version-independent prefix is installed on the root element of your document, @@ -1169,13 +1169,11 @@ 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.
+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 @@ -1206,8 +1204,8 @@ 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 +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 defines a set of IDL (or Java) interfaces allowing you to traverse and manipulate a document. The DOM library will allow accessing and modifying "live" documents @@ -1290,15 +1288,14 @@ base:
</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.
+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 -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:
+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:/* * A person record */ @@ -1354,10 +1351,9 @@ DEBUG("parsePerson\n"); 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). -
Here is another piece of code used to parse another level of the @@ -1414,11 +1410,11 @@ DEBUG("parseJob\n"); return(ret); } -
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 :-)
+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 :-)
Feel free to use the code for the full C parsing example as a template, it is also available with Makefile in the @@ -1450,6 +1446,6 @@ Gnome CVS base under gnome-xml/example
-$Id: xml.html,v 1.68 2001/02/24 17:48:53 veillard Exp $
+$Id: xml.html,v 1.69 2001/02/26 07:31:12 veillard Exp $