Chronicle Lite RSS

About

Download RSS

License

Contact Us

 

RSS Library

This library is released under a modified BSD license - a certified free software license. Please take a moment to review the terms and conditions of the license.

Philosophy

This implementation of the RSS specification was created from original documents where possible :
VersionSpecification

0.91http://backend.userland.com/stories/rss091
0.92http://backend.userland.com/stories/rss092
0.93http://backend.userland.com/stories/rss093
2.0 http://backend.userland.com/rss

Two branches of RSS exist, rooted in versions 0.9 and 0.91 of the specification. The original 0.9 specification continues on into version 1.0 today, using XML namespaces to define a channel according to the RDF (Resource Description Framework) defined by the W3C. Version 0.91 simplified the format and evolved through versions 0.92, 0.93 and version 2.0 today. Code in this library follows the "0.91" (RSS) branch of the tree due to its greater popularity. Future versions of this library may revisit this decision and implement the "0.9" (RDF) branch also.

Code was created test-first using the jUnit and xmlUnit testing frameworks. Tests captured the specification in an executable form and ensured compliance. Full source for tests is distributed along with the library, in the 'test' subpackages. Test classes begin with a "Test_" prefix and continue with the name of the class they test. For example, Test_RSSChannelRenderer_v091 tests the rendering of a version 0.91 channel definition.

To avoid ambiguity, class names bear a specification number as a suffix. Version 0.91 of the specification bearing a "_v091" suffix, "_v092" for version 0.92 and so on. Where methods deal in objects of particular types, a suffix was added for clarity - for example getItem_v091() and getItem_v092() which return channel items for version 0.91 and 0.92 respectively.

Library Structure

All runtime code is contained under the com.caffeinatedbliss.rss package hierarchy. Tests in the "test" package under any given java package.

Four classes make up the implementation of each version of the specification. Two (Channel and Item) are a pure data model implementation that programmers can use to represent a channel and its items at run time. The Channel class has a number of properties and a collection of Item objects, with simple collection management methods to manage them. The data model is independant of presentation or serialization formats.

An appropriately formatted XML string can be generated for a given RSS Channel by creating an instance of an RSSChannelRenderer, passing the channel. Calling toString() will return XML conforming to the appropriate specification level. The library makes no assumptions as to how applications will use this XML text though it is likely that it will be written to a file on a webserver.

Text can be converted to an appropriate RSSChannel object and associated collection of Items using the RSSParser class. The source of the XML text is not assumed by the library.

RSS v 0.91 Classes

  • RSSChannel_v091
  • Item_v091
  • RSSChannelRenderer_v091
  • RSSChannelParser_v091

RSS v 0.92 Classes

  • RSSChannel_v092
  • Item_v092
  • RSSChannelRenderer_v092
  • RSSChannelParser_v092

XML Parsing

Many XML parsers exist. The library shouldn't place a burden on applications to use any particular implementation of a parser. A reference implementation of the RSSChannelParser classes were created for the standard jaxp SAX parser simply because there was a need to support these parsers in the applications originally driving the implementation of this library. The RSSChannelParserFactory class should be expanded to include other parsers as there is need, for example to utilize MinML, NanoXML, JDOM, DOM4J or (say) Castor.

The RSS Parser Factory creates intances of a given kind of parser. RSS version differences are wrapped up in the RSSParser_v091 and RSSParser_v092 interfaces. Applications need to be aware of the version of the specification that they are dealing with but can ignore the nuts and bolts of the parsing mechanics. In other words, does it matter how it gets to the place it's needed, so long as it's the right type?

SAX Implementation

  • RSSSAXParser
  • RSSContentHandler
  • RSSSAXParser_v091
  • RSSSAXParser_v092

The RSSContentHandler class tidies up the nasty SAX ContentHandler making the _v091 and _v092 SAX parsers a little easier to implement. An inner class in each handles the nitty-gritty of processing the SAX events.

Thoughts for future development

  • Is there a way to drive the parsing based on the version number embedded in the XML text?

  • Is there a way to remove the version specific suffixes?

  • Can the SAX parsers be coded to collect enough data for the channel object's constructor to be called, and thereby avoid all the null's? Possibly, collecting the data in a map and passing the map into a constructor?

  • Add other parser implementations?

  • SINGLETONS ARE EVIL ... so why the heck did I implement the parser factory as a singleton? That needs to go sooner rather than later, as a pretty simple refactoring.

Contacting the author

Feel free to contact me regarding the implementation. If you have suggestions or improvements I would especially like to see them. Simply use the Contact form on the main Chronicle Project website

Main Page

caffeine molecule.
Caffeinated Bliss home

 

Copyright © P and A Hawke 2002. All rights reserved.