[XML-SIG] SAX Namespaces

[Uche Ogbuji]

[snip Paul's arguments for the (uri, local, rawname) triple]

I'll just note for the moment, that based on my experience implementing SAX->
DOM and XPath, I'm nto convinced that using the triple makes life so much 
easier.

Basically, I wouldn't use XPath as an argument for it.  4XPath certainly does 
fine without it.  If Lars's approach makes life easier for "direct-to-SAX" 
programmers, I'd vote for that.

Also, Paul seems to be arguing that "direct-to-SAX" programmers should change 
their ways and move to higher-level APIs.  I think that's unfair.  I avoid SAX 
myself, but I know from many people that they prefer that route and why should 
we strong-arm them to another approach?  Let pulldom or pyxie or DOM or 
whatever win out on its merits, not by making SAX more difficult.

> Let's say the speedup is "only" 5%, but 97% of all SAX-using programs
> never use the SAX API directly anyhow? Then that speedup comes "for
> free" from the point of view of those programmers.  It's like a tweak in
> the bowels of Python that makes Guido's job a little bit harder but
> makes Python run faster for everyone. It's like rewriting a Python
> module in C for the sake of all of the apps built on top of it. That's
> where I think we are going. Heck, I woudn't be suprised if we see Python
> SAX producers and consumers both written in C soon. I think of it as a
> device driver API.

This puzzles me.  A while back you seemed a bit dismayed when you found that 
4XPath and 4XSLT used C modules, but here you seem to be advocating moving at 
least some XML tools to C.

I still think that there is no reason why Python/XML tools shoudln't be in C 
as long as the maintainers take responsibility to port or assist in porting to 
all Python platforms.

> No, it isn't too late and I consider SAX your domain. I just did what
> seemed to me to be the best thing for performance when it comes to names
> and I haven't touched AttributeList yet.

Until further discussion I'd vote for changing it back to Lars's original API 
for q-names.  Apart from all the other arguments, Lars did put up his API and 
invite us all to hash it out (and there _was_ some discussion of the matter).  
IMO it's a bad idea to suddenly change it all now.

-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +01 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python