From: James Henstridge (james@daa.com.au)
Date: Wed Sep 22 1999 - 09:53:42 EDT
You could look at adding a function using a similar syntax to the X
graphics context creation functions (ie. a bitfield describing which
arguments are given and a structure holding the arguments), or something
like the gtk_widget_new function in gtk+ (a varargs type system). Both of
these would allow you to add extra flags to the function in a source
and binary backwards compatible way.
The problem with the current SAX functions which return an xmlDocPtr is
that there is no way to set this return value from the parser.
One other nice thing would be to reduce the size of the xmlParserCtxt
structure by moving the members that are specific to the DOM tree SAX
parser (which are not used (and inaccessible) to other parsers) to a
private structure that is passed around in the userData member.
This would also mean that the xmlParserCtxt structure would not need to
change when adding features to the DOM tree parser. Of course, if the
xmlParserCtxt is meant to be an internal structure, you could move it to
parserInternal.h and just leave the "typedef struct _xmlParserCtxt ..."
lines in parser.h.
Other than these small problems, I quite like the SAX interface in libxml.
James.
-- Email: james@daa.com.au WWW: http://www.daa.com.au/~james/On Wed, 22 Sep 1999, Daniel Veillard wrote:
> On Wed, Sep 22, 1999 at 08:19:01PM +0800, James Henstridge wrote: > > I wish I didn't have to rely on the xmlParserCtxt structure. It is just > > that the SAX parser entry points in libxml are not usable for most SAX > > parsers other than the DOM tree generator because they give no way of > > setting the userData pointer that is passed to each SAX callback. As it > > stands, you would need to use global variables to hold parser state > > information, which is not always desirable. > > I completely agree, you're not to blame, I am, but the parser interface > get more complex, there is a wide range of options: > - to use SAX or the DOM tree generation > - to substitute entities or not > - to validate or not > - to fetch external parser entities or not > - etc ... > This is actually growing as I implement more fully the XML specification > and it's unclear to me that adding one function per case is a good idea as > the number will explode fast. Maybe one function will all parameters are > tunable, but in that case I need a precise list of those parameters and > it was still growing last week (with remote entities/DTD fetching being > added). > I would like that interface to be the final one, and that's the reason > I didn't create "intermediary" ones. > > > The problem code in libglade is concentrated in the my_xmlSAXParseFile and > > my_xmlSAXParseMemory function in glade/glade-sax.c. These two functions > > give sane entry points to the libxml parser for custom SAX parsers. If > > you added routines with similar functionality to libxml, I can remove the > > problem code from libglade. > > > > Please consider doing this, as the SAX interface is very useful for > > writing fast parsers where the DOM tree is not required. > > Yes of course, more and more people are now using the SAX API so it probably > makes sense to provide (and maintain a specific SAX simplified API). > > Daniel > > -- > Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks : > Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux, WWW, rpmfind, > Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | rpm2html, XML, > http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe. >
---- Message from the list xml@rufus.w3.org Archived at : http://rufus.w3.org/veillard/XML/messages to unsubscribe: echo "unsubscribe xml" | mail majordomo@rufus.w3.org
This archive was generated by hypermail 2b29 : Wed Aug 02 2000 - 12:29:47 EDT