On reading/writing XML in .NET

Dino Esposito has published a quite comprehensive article, named Real-World XML: Manipulate XML Data Easily with Integrated Readers and Writers in the .NET Framework in May MSDN mag issue.

While reading the article two things caught my eye - usual negation of SAX usefulness and another API quirk, which should be remembered.

1. Being particlularly fan of XML pull processing I nevertheless don't understand why one may completely deny usefulness of push processing. I like both push and pull, why to limit myself to only one? Pull is good when application knows what it wants to pull out, and push is good for generic rule based processing.

   "All the functions of a SAX parser can be implemented easily and more effectively by using an XML reader."

   I'm still not convinced, in next version of XmlReader API may be, but not now. Consider MSDN example of attributes to elements convertor, based on XmlTextReader. Hmm, state machinery, 4 overrided members... And here is SAX version:

   import org.xml.sax.*;
   import org.xml.sax.helpers.*;
   
   public class Attrs2ElementsFilter extends XMLFilterImpl {
       public void startElement(String namespaceURI, String localName,
         String qualifiedName, Attributes atts) throws SAXException {
         AttributesImpl newAttributes = new AttributesImpl();
         super.startElement(namespaceURI, localName, 
             qualifiedName, newAttributes); 
         for (int i = 0; i < atts.getLength(); i++) {
             super.startElement("", atts.getLocalName(i), 
                 atts.getQName(i), newAttributes);
             super.characters(atts.getValue(i).toCharArray(), 0, 
                 atts.getValue(i).length());
             super.endElement("", atts.getLocalName(i), 
                 atts.getQName(i));
           }
       }
   }

   As for me, SAX won in this particular task.
2. Quirky one, need-to-be-remembered. (Sure they will change it in the V2 API). While the API allows XmlReader as argument to XmlValidatingReader constructor, it must be XmlTextReader.

   Note that although the signature of one of the XmlValidatingReader constructors refers generically to an XmlReader class as the underlying reader, that reader can only be an instance of the XmlTextReader class or a class which derives from it. This means that you cannot use any class which happens to inherit from XmlReader (such as a custom XML reader). Internally, the XmlValidatingReader class assumes that the underlying reader is an XmlTextReader object and specifically casts the input reader to XmlTextReader. If you use XmlNodeReader or a custom reader class, you will not get any error at compile time but an exception will be thrown at run time.