February 8, 2004
@ 10:15 PM
Comments [2]
My Review of ATOM.NET

I noticed Gordon Weakliem reviewed ATOM.NET, an API for parsing and generating ATOM feeds. I went to the ATOM.NET website and decided to take a look at the ATOM.NET documentation. The following comments come from two perspectives, the first is as a developer who'll most likely have to implement something akin to ATOM.NET for RSS Bandit's internal workings and the other is from the perspective of being one of the folks at Microsoft whose job it is to design and critique XML-based APIs.

  • The AtomWriter class is superflous. The class that only has one method Write(AtomFeed) which makes more sense being on the AtomFeed class since an object should know how to persist itself. This is the model we followed with the XmlDocument class in the .NET Framework which has an overloaded Save() method. The AtomWriter class would be quite useful if it allowed you to perform schema driven generation of an AtomFeed, the same way the XmlWriter class in the .NET Framework is aimed at providing a convenient way to programmatically generate well-formed XML [although it comes close but doesn't fully do this in v1.0 & v1.1 of the .NET Framework]

  • I have the same feelings about the AtomReader class. This class also seems superflous. The functionality it provides is akin to the overloaded Load() method we have on the  XmlDocument class in the .NET Framework. I'd say it makes more sense and is more usable if this functionality was provided as a Load() method on an AtomFeed class than as a separate class unless the AtomReader class actually gets some more functionality.

  • There's no easy way to serialize an AtomEntry class as XML which means it'll be cumbersome using this ATOM.NET for the ATOM API since it requires sending  elements as XML over the wire. I use this functionality all the time in RSS Bandit internally from passing entries as XML for XSLT themes to the CommentAPI to IBlogExtension.

  • There is no consideration for how to expose extension elements and attributes in ATOM.NET. As far as I'm concerned this is a deal breaker that makes the ATOM.NET useless for aggregator authors since it means they can't handle extensions in ATOM feeds even though they may exist and have already started popping up in various feeds.


 

Categories: XML

« I'm Touched | Home | Dealing with Difficulties Using Namespac... »
Tuesday, 10 February 2004 00:00:57 (GMT Standard Time, UTC+00:00)
Good point on the AtomWriter/AtomReader classes. About the point that "a class should know how to serialize itself" - I agree, but how to implement this? My first thought was to overload ToString(), but that seemed like an abuse of ToString(), though I don't know that it violates any FCL guidelines. It'd end up being like the OuterXml property on System.Xml.XmlNode, which is a pretty easy way to dump or assign to a node. I started thinking that since he went with a strongly typed model, maybe .NET Serialization would be more appropriate, though probably a ton of work for a pretty simple feature. Really, it would be extra work for the user of the class, you'd have to set up an XML Serializer and all that jazz when all you want is a string. The pragmatic in me says to forget about XML Serialization, but I get the feeling that since he went with a strongly typed object model, serialization might be more appropriate. Any thoughts on this?
Gordon Weakliem
Tuesday, 10 February 2004 05:32:45 (GMT Standard Time, UTC+00:00)
>About the point that "a class should know how to serialize itself" - I agree, but how to implement this?

I don't see why the model the XmlDocument class isn't good enough. Have a method that takes an XmlWriter with some helper methods that delegate to it that take in a Stream, TextWriter or filename. If you do want to create a method that returns the XML as a string for convenience then I'd suggest coming up with a ToXml() method not overloading ToString().
Dare Obasanjo
Comments are closed.