Atom v. RSS

Both Atom and RSS get the job done when I comes to providing feeds of site content to users, but it's decided, Atom wins hands down. Just take a look at RSS 2.0 and Atom 1.0 Compared. I will admit that it may be easier to generate RSS 2.0 because it has fewer requirements (because you get so many standards to choose from - yea!), however, Atom fits very nicely into the XML suite of standards that I have learned, whereas RSS does not.

RSS 2.0 was a much needed 'standard' to combine all the previous RSS versions as well as prepare the way for future formats, like Atom, but it has many shortfalls. It was known to be less than perfect, but instead of creating more confusion with a new version, it locked the standard and declared that any other predecessors should be given a new name. Atom is that new name and has one large shortfall: it is not as widely supported as RSS. However, such a thing is temporary.

Short of not having a namespace (which just urks me), RSS is not intended to include XHTML and shows. That is why I didn't even go there and just have summaries instead of full-text-posts on the feed. Also, the channel element always threw me off - if I squinted, I could see a purpose, but otherwise I found it useless. As a developer using XSLT, RSS made it very difficult to specify times, albeit, a very valid standard of the day. I needed to use EXSLT's format-date function. However, no XSLT processor supports such a thing. So I end up including a XSLT style sheet that implements the function. This isn't that bad, but it hurts to take a 40% performance decrease. What is even better is that I get to put Atom's date format into the format-date function since this is the standard format used in XSLT. Of course, if you are using PHP, you don't care that much, but at least with Atom you don't have to lookup the argument syntax for date().

Atom in general makes much more sense and is more familiar looking then RSS.

First Post - Heck yeah... No php

Okay, I have now done something with XSLT that should not have been done. This entire site is generated on-the-fly with XML data files in a folder-oriented heirarchy and XSLT. Currently all text other than the sidebar and footer are completely dynamic.

I checked to see how slow the XSLT was because I was loading many files and such, so on my AMD64 it took .015 seconds (real) to build a page on this blog compared to .075s to do a blank php file. That is nice when you begin running the markup on a server that is 13.5 times slower than your machine (and 32bit). In addition, since libxml2, libxslt, and mod_xslt are so small, they will not require as much RAM (which is nice if you only have 16MiB).

Organization

I use the following list of standards and solutions to form this site:

  • XHTML 1.1
  • CSS 2.0 (plus one Mozilla extension)
  • Javascript
  • XSLT 1.0
  • mod_rewrite

Although I am using the XHTML 1.0 doc-type, the markup is based on XHTML 1.1. This is because I have to use the text/html media type. I am using CSS 2.0 to do some of the nicer presentational effects without adding markup. I still have to split up the CSS into multiple files. The Javascript is just to give IE some of the CSS 2.0 features of the site and to swap between a fixed and fluid layout (will be working after I separate the CSS). The XSLT converts the XML files into a page. And mod_rewrite just makes the "Recent Posts" the main page (try /index).

I will need to use php to build a front-end for adding posts, but they are not too much of a pain to do by hand.

When I have more time I will describe more of how it all works and enable a way for the XML files to be viewed raw, but for now just look in /shared and see what you can find.