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

[Toni Uusitalo <toni uusitalo luukku com>]

At 09:39 13.8.2003 -0400, you wrote:
> 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.

Sorry, C is not poor. We should rename C to C$.
C++, C# and C$
C is rich ;)

> > - For example namespace info for callbacks has been well thought over and
> > tested
> > - 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 !).

Yes. That makes sense. I guess No API is carved in stone (or was there API
of Moses?).


> > p.s. I myself have written minimal SAX2 based XML parser in ANSI C with
> > namespace support and API similar to
> > SAX2
>
>   Looked at it:
>
> --------------
> startElementHandler
> int (*XML_START_ELEMENT_HANDLER)(void *UserData, const XMLCH *uri, const 
> XMLCH *localName,
>                                  const XMLCH *qName, LPXMLVECTOR atts);
>
> endElementHandler
> 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.

Yes. I vote for SAX API here.

> --------------
> 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.

Ok. Besides being bad programming style this empty string stuff is might be 
good
example of an attempt to implement SAX2 API in C "too faithful to Javadocs"
hehheh ;-)

I guess you won't go into this trap.

> --------------
> 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.

Yes! This one is good example of misleading implementation! You expected
localName to have valid value when in default namespace cos that's the way SAX
should be implemented. Maybe you consider strict SAX2 implementation now ;)

Seriously, I made qName to have always valid value cos I thought it would
be more handy to parser user just use qName if he isn't interested in namespace
stuff and not to force testing uri and localName or qName in that case.

I guess I must rethink this localName stuff...

"SAX2 guarantees that the localName will be meaningful if the namespace is not
the empty string, otherwise the qName will be meaningful. If the value for
localName or qName is not meaningful it will be set to the empty string, not
to null. Some XML parsers always supply both names, but this is not required."
Exerpt from http://saxadapter.sourceforge.net/XMLNamespaceTutorial.html


Toni Uusitalo