Re: [xml] Refactoring of the SAX interface for namespace support

On Wed, Aug 13, 2003 at 04:12:53PM +0200, Toni Uusitalo wrote:

I think there could be some benefits implementing SAX interface as close to 
existing Java/C++ SAX2 interface as you can get with poor old C:

  For me C is not poor.

- For example namespace info for callbacks has been well thought over and 
- Existing documentation on SAX can be more easy to grasp when callbacks 
are similar (in the limits of C of course)

  Well I think it's a trivial change actually. The point is to have
a clear description on how this changed and I will do this.

Of course performance issues are on the scale too but I think little 
performance benefit over usability isn't worth it.

  Well for me performances are a critical aspect at this point, after
conformance to standards (note that if SAX actually had gone through due
standard process I would feel far more annoyed to break it !).

p.s. I myself have written minimal SAX2 based XML parser in ANSI C with 
namespace support and API similar to

  Looked at it:

int (*XML_START_ELEMENT_HANDLER)(void *UserData, const XMLCH *uri, const XMLCH *localName, 
                                 const XMLCH *qName, LPXMLVECTOR atts);

int (*XML_END_ELEMENT_HANDLER)(void *UserData, const XMLCH *uri, const XMLCH *localName,
                               const XMLCH *qName);

  This looks very close to proposal #1, I still prefer having per attributes
callbacks to avoid the complication of walking over the atts vector. But this
is one more vote toward the first option.

Similar to SAX2 events, note that uri or localName parameter doesn't have value NULL when unavailable but 
their values are empty string, this can be tested with

if (!*uri) ...

  Bahh, this is not common for C, and force and indirect memory reference
instead of just a register test, I'm not thrilled ? Is that supposed to 
help programmers, I can't see why.

of course. Difference from SAX is that qName has always valid value. localName is empty string when element 
doesn't belong to any namespace or belongs to default namespace.

   Localname empty when in default namespace ? that sounds very misleading.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]