Daniel says he's disappointed in SAX.NET project I was writing about. Unlike lazy me, he downloaded it and inspected implementation. Well, I mostly agree with him. This piece of direct thoughtless porting of complex convolute Java API to .NET looks weird and kinda unnatural. "namespace System.Xml.Sax {" isn't what I like to see altogether. Too many conventions are broken. Too bad to taste good. Well, I hope are they will improve things. At least todays conversation in xml-dev gives some hopes to think that.
Attributes2 and friends are traces of long SAX API evolution. SAX was created in a vacuum, there wasn't standard Java XML API at that time, while SAX.NET is going to live in .NET land and must be System.Xml-friendly. The question is is it feasible at all?
I ran into the same issues when trying to write my SAX parser. The namespace for SAX is org.xml.sax... hardly usable for .NET. So, we are faced with Org.Xml.Sax, which is moderatly usable, or ditching the namespace and doing something unique like XmlAdvice.Xml.Sax. I chose the XmlAdvice.Xml.Sax namespace because I have other projects that fit within the XmlAdvice namespace and assemblies that I use.