Declare the FPXMLParserProtocol protocol to conform to NSXMLParserDelegate when compiling with the MacOSX10.6 SDK. This prevents spurious warnings about objects not conforming to NSXMLParserDelegate.
Google News has a weird quirk with its RSS dates where it gives every date both a textual timezone as well as a numeric one. In addition, it adds a separator between the hours and minutes in the numeric timezone. Neither of these quirks are RFC822-compliant. We should support them anyway.
When we abort parsing the feed due to an error, we were releasing the feed object while it was still possibly in the middle of handling something. Ensure that each FPXMLParser stays alive at least long enough to finish any processing it was doing.
…(fixes #7) When a known extension element with a textual content, such as <dc:creator>, is encountered with no actual content, as in <dc:creator></dc:creator>, we must do 2 things. We must return after aborting parsing when the number of child nodes is unexpected, and we must also handle zero child nodes.
Ensure all non-RSS/Atom elements always have extension element nodes even when these elements are supported directly (such as <content:encoded>). This preserves backwards-compatibility in old clients when direct support is added for various extension elements. This fixes the tests that were broken by the previous commit.
Implement a new property FPItem.description. This takes the place of the old FPItem.content. FPItem.content is now used for <content:encoded>. If the item does not contain a <content:encoded> tag, this property will contain the value of item.description. This is a mildly backwards-incompatible change, in that if a client of FeedParser was using FPItem.content along with the extension element mechanism to extract both <description> and <content:encoded>, that code will no longer work correctly. The explicit handling of <content:encoded> removes it from the extension element mechanism. A solution to this is forthcoming. In the meantime, some tests are expected to fail.
RFC822 dates with +/-HHMM dates were not being properly handled. The HHMM string was being treated as HHHH and a nil date was being returned. A few tests were added to test this functionality, and a fix was implemented (thanks jablair).