Partager via

Some Thoughts on the SAX dot NET Project

  • Article

A little while ago I noticed the SAX dot NET project was announced on the XML-DEV mailing list. From the desxcription on the project page

SAX dot NET is a C# port of the original Java based SAX API specifications. When compiled into a .NET assembly it becomes available to the other .NET languages as well.

The .NET Framework doesn't ship with an implementation of a SAX push model XML parser but instead ships with the pull-model parser in the form of the System.Xml.XmlReader class. The primary reasons for this can be gleaned from my article A Survey of APIs and Techniques for Processing XML where I list the pros and cons of various approaches for processing XML. The main advanatages a pull-model XML parser like the XmlReader have over a push model XML parser like SAX are

Pull model parsers typically do not require a specialized class for handling XML processing since there is no requirement to implement specific interfaces or subclass certain classes for the purpose of registering callbacks. Also the need to explicitly track application states using boolean flags and similar variables is significantly reduced when using a pull model parser

I can understand that developers migrating to the .NET Framework from Java platforms or MSXML would like to have the familiar feel of the SAX API so I definitely welcome such projects. However I have seen some criticism of the project from Daniel Cazzulino, a Microsoft XML MVP, in his post Do we need SAX for .NET? (or does Java ports to C# make sense?) he points out of some of the disadvantages of blindly porting an API from one platform to another. He points out some inconsistencies and redundancies between SAX dot NET and the .NET Framework such as

  • There  is an XmlNamespaces class that does the same thing as the System.Xml.XmlNamespaceManager class

  • There are IAttributes AND IAttributes2, and the corresponding implementations called AttributesImpl and AttributesImpl2 which seem to imply interface versioning problems and legacy issues in a brand new project.

  • The existence of non-standard delegates such as OnPropertyChange(IProperty property, object newValue)  instead of the  typical pattern in the .NET world where it should be OnPropertyChange(object sender, ProperyChangeEventArgs e).

I think Daniel raises good points and encourage any developer porting an API to the .NET Framework to endeavor to make it consistent with the patterns and naming conventions in the .NET Framework. Doing so makes it easier for developers to understand how to use the API since it will be familiar and contains few surprises.

Comments

  • Anonymous
    April 03, 2004
    Hi Dare,

    Im also a guy who comes from Java XML world .Net XML. It was not my choice, but i took the opportunity to have a deeper look into System.Xml and its concept.

    Although im coming from Java XML world, i never liked SAX. I could not understand why all my fellows wrote Handlers in which they always kept the state of parsing. My first XML-Parser was handwritten which worked on a stream and without much knowledge we intuitively developed a parser now known as Pull-Parser.

    The main point for me against SAX is the error-proneness when XML other than expected is parsed. What happens, if startElement() is called when it should not be called......

    PullParser let the developer have more influence in parsing. The developer says what should be next.... The result is a much better ExceptionThrowing.

    In some projects i also used a PullParser Constructor, which created the Object from the Parser.

    In my opinion SAX is dead and i totaly agree with you, if someone wants to port his Java code to C# and comes to the parser stuff. Then the best solution should not be to port SAX, one should port their Project to the new opportunities System.Xml offers to you.

    But now i have to say something else, maybe you dont want to hear it, but its crucial and also a big point for all Java -> C# porters.

    I'm working on a YFilter (XML Filtering with statemachines) implementation for C#. therefore i need a XPath Parser. System.Xml has one "inside" but the Parser and the parsed data structure is not public to the API user.
    So one has to reinvent the wheel when working with .Net and System.Xml

    My solution is a port of java saxpath to c#........

    Sorry but i don't use a library (System.Xml) which prevents me from real developing by hiding the interesting things inside.

    So maybe the OpenSource Community has to port all those existing things, that are also included in System.Xml
    Just imagine someone wants to do something else than verifing XML with System.Xml.Schema....
    When will there be a Xalan XSL port?

    stefan

    replies and flames welcome :-)

    lischke(-ed-)cs.tu-berlin.de
  • Anonymous
    May 14, 2004
    I created a response and to this blog item and Daniel Cazzulino's topic on the subject and posted it on my site:

    http://www.jeffrafter.com/saxdotnet.html

    Discussion is welcomed...

    Jeff Rafter