Do I need SAX for .NET? (or does straight Java ports to C# make sense?)

Note: this entry has moved.

After reading Oleg's post about an upcoming SAX.NET implementation, and while I still look forward to the other XML fellow developer working on that, I got certainly excited and run to download and have a look at it. I was dissapointed, I must say.

When I see a project implementing a class called XmlNamespaces containing methods such as AddMapping, GetPrefixMapping, PushScope and PopScope (among others), which do exactly the same as the System.Xml.XmlNamespaceManager with its AddNamespace, LookupNamespace, LookupPrefix, PushScope and PopScope, I start wondering whether straight ports of other platform libraries really does make sense in .NET. The mismatch doesn't end there:

  • There's IAttributes AND IAttributes2, and the corresponding implementations called AttributesImpl and AttributesImpl2 (?!?!). Multiply that by ILocator, IEntityResolver and so on. This is the first port and there's already interface versioning problems?
  • There's an IXMLReader (note the casing) class with an EntityResolver property which doesn't try to take advantage of .NET XmlResolver class, instead reinventing it through the IEntityResolver interface
  • All the GetFeature/SetFeature/IProperty baggage that only makes sense when multiple XML parsers are available and with varying features support (which judging from the silence of death to my request for support to such scenarios isn't going to happen at all in .NET)
  • Non-standard delegate such as OnPropertyChange(IProperty property, object newValue) - in .NET world it would have been OnPropertyChange(object sender, ProperyChangeEventArgs e).
  • Trivial things such as: public static string GetString(RsId id) { string name = Enum.GetName(typeof(RsId), id); return rm.GetString(name); // Should have been: // return rm.GetString(id.ToString()); }

I think copying Java projects over to .NET is not always a good idea, specially if done by people who doesn't work with C# and .NET on a daily basis. Examples of well done ports are NUnit and Log4Net, for example. Note, however, that it wasn't until v2 that NUnit started using .NET-isms as custom Attributes.

So, do I want SAX.NET? Definitely NOT. I like some of its ideas. We, as .NET developers, should take the best ideas from it, mix them with .NET-friendly APIs, take advantage of built-in infrastructure, and improve on it. So, I still like it much more the Xml Streaming Events (XSE) idea than any of these ports. I have to work further on it, develop more use cases, clarify the API and give a second though to some concepts, but it definitely integrates far better with current and future .NET XML support. What I definitely don't want, is to code against a pseudo-.NET/pseudo-Java API.


  • A SAX parser for .NET is not to be confused with, the component and tools company. :)

  • You're definitely right. Changed the title to reflect that.


  • You are being too harsh.

    The fact that *you* do not need a SAX parser for .NET does not mean that other people do

    not need a SAX parser for .NET

    It might help them port existing code, without having to spend too much time

    rearchitecting their code that they might

    have in Java to fit .NET

    You might also be more successful if you

    point the authors of the software how they

    could improve their software, and reuse some classes from .NET to achieve a better



  • You're damn right Miguel!

    I should have entitled the post "Do *I* need ...".

    About people porting their Java apps to C#, you're definitely right again. That's an scenario I didn't think about.

    About being succesful by pointing them the problems, that's what I did in this post. I know I should better go and fix the code. Unfortunately, I don't have the time to do so, and posting on my weblog is my *little* contribution to that (note that I didn't say "it sucks", I pointed specific problems I found), and that's almost all I have time for. Yeah, I know I should also mail this to the project owner...

    Un abrazo amigo!

  • By accident I stumbled upon this web log.

    Some of the criticism is verly likely warranted,

    but would it not have been reasonable to contact

    the maintainer (which would be me) directly, or

    leave a message on the SF project?

    Yes, I am fairly new to .NET, and I have repeatedly

    invited feedback and criticism in the ReadMe file

    included with the distros. Would have been nice

    if someone had actually bothered to provide that feedback and correct my misdirected ways.


  • You're absolutely right Karl. Definitely my fault. You shouldn't have read my feedback by coincidence.

    As you can see, I've doubts about the whole porting thing, but it's good to see alternatives anyway.

  • So, what are the things you would like to use?

    I already know what you don't like.

    Btw, my plan was to ease porting, so I kept it pretty

    close to the original. And even that ran into

    resistance. I thought I had deviated a lot from

    the original API. I guess not enough.


  • After a very quick look at XSE it looks conceptually

    like something I am using almost exclusively in my

    SAX applications. (not ported to C# yet).

    It's a kind of low-level XPath like call-back API,

    where call-backs are not based on the next element

    start/end but on some "expression" matching.

    Has also been good for high speed transformations.


  • After a very quick look at XSE it looks conceptually

    like something I am using almost exclusively in my

    SAX applications. (not ported to C# yet).

Comments have been disabled for this content.