XML::SAX::Expat has been moving ahead fairly well and now supports nearly all SAX events (a few aren't yet, but I don't know if they can be. It's very possible that I've overlooked something).
Same status on the XML::SAX::Writer side where almost all events have been implemented (in fact all except for one corner case which I need to explore). The formatting is the largest part that still needs to be worked on, but given that it really is only needed if you want to pretty print your XML, it can be added step by step and isn't imho all that important.
The latest versions of both those modules are on CPAN. Be warned that they haven't been thoroughly tested yet. I need to look into Barrie Slaymaker's Diff module and to write many tests here.
I wish someone would write a reusable SAX driver/filter/handler test suite. I subtly tried to have Kip Hampton (Hi Kip !) take care of that because he writes a lot of good tests for various modules but my suggestion skills are no match for his psychic defenses. If you have much weaker psychic defenses, or are simply looking for a cool project people will love you for then this would be a very cool thing to do.
I'm also done writing XML::SAX::SVGExpand, and its SVGContract companion. There are simple modules that either take SVG's path/polyline/polygon data and expand it into an XMLized syntax so that it is more palatable to XML tools such as XSLT that don't have access to a full fledged SVG DOM, or take the aforementionned XMLized syntax and turn it back into SVG's native path/point syntax.
SVGContract reminded me that we really need to start writing a SAX Patterns document. SAX is trivial in itself, but some ways of using it (or using it to its best) are not always known. In the case of SVGContract I need to buffer all events between <path> and </path>, extract and eliminate those that are part of the expanded syntax, set <path>'s d attribute to the value of those, and only then allow the events -- including start_element and end_element for <path> to be fired. How this is done is actually quite simple (mostly AUTOLOAD and knowing your status in other subs, plus a tiny little bit of trickery) but you can judge from the obfuscation of my own explanation that it could warrant a longer and more detailed exploration :-) There are dozens of other such SAX patterns that every XML programmer needs to have in his toolbox.
I haven't released those two to CPAN yet as I want to make sure that the syntax is the one I want, and I really need to document it.
I've also realised that CSS::SAC needs a rewrite, possibly with some compatibility breakage. I realised that while working on the SAC spec, and based on my experience from SAX (both spec and implementation). I guess the rewrite will happen progressively as I move ahead in the spec-writing.
Talking about spec writing, Kip and I were discussing PerlDOM (he made a very cool piece about it in his journal) on #axkit (as usual, if you haven't stolen the Heart of Gold yet, don't bother, #axkit is where the world is ruled from. Ok maybe not, but a lot of cool conversations take place there ;-). I ranted a lot but I think it clarified things a good deal for me, so I think I'm going to work on helping with that spec as well. In case you hadn't figured that out yet, I actually enjoy spec-writing :-) I just wish there were a really good DocBook editor out there. So far I've been rather unimpressed (Simple DocBook would be good enough).
