XML Reference Guide

In one of my predictions for 2006, I said that "RSS will have become so common that every application for which it makes sense (and probably a few for which it doesn't) will provide an RSS feed for various purposes." Specifically, RSS is being used as a type of announcement service, which makes sense for its original usage, as a listing of blog entries or other web pages of interest. On the other hand, and applications also use RSS as a means for disseminating information on items such as files that are now available, contacts in your address book, appointments in your calendar, and so on.

In many cases, this is information that is shared among multiple points. For example, Ray Ozzie talks about the fact that when he is traveling, he has difficulty coordinating his calendar with his wife. Ideally, he thought, we could find a way to synchronize her copy and my copy. And thus, Simple Sharing Extensions, or SSE, was born.

The purpose of SSE is to add information to an RSS feed (or, as stated in the spec, an OPML outline) that enables users to share the information without stepping on each other. In other words, it adds information that uniquely identifies each item so that it can be included in separate feeds without ambiguity, and allows for changes that can be detected and managed by other users. The spec is just been released, and as such still has a ways to go, but it's useful enough in its current state that it's worth looking at and putting into practice, if only to find all the holes.

As such, I thought I'd take some time to demonstrate how SSE can be used to share information between RSS feeds. Although it was originally conceived for feeds that are, say, informational rather than traditional syndication feeds, I do think that there's a place for it in the traditional RSS world. For example, many bloggers -- myself included -- have more than one blog. How to get all of that information together in one place has been a problem. Oh sure, I could just create one RSS feed that includes all of the information, but that just always seemed kind of messy to me. With SSE, I can create an aggregate feed and keep the information properly segregated.

You can also use SSE to create general aggregate feeds. Consider for a moment this example:

In this case, we have several feeds that are mutually publishing and subscribing to each other. For example, the Chaos Magnet feed includes items from the InformIT feed. Chaos Magnet is then subsequently included in Troy's feed, which includes the blogs of people who work with Backstop Media. Finally, I can create an overall aggregate feed of items that I want to watch for. Note that I wouldn't necessarily have to include Chaos Magnet, in this case, because it's already part of the Backstop feed, but as I own it, I would likely want to maintain it separately. In this case, it would be useful to have unique identifiers for each item so they are not duplicated. And, in fact, SSE provides for that. Let's take a look at how it works.

Consider, for a moment, my original Chaos Magnet feed, which happens to be an RSS 1.0 RDF document:

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  ...
  xmlns="http://purl.org/rss/1.0/">

<channel rdf:about="http://www.chaosmagnet.com/blog/">
<title>Chaos Magnet</title>
<link>http://www.chaosmagnet.com/blog/</link>

<description>The personal and professional ramblings of Nicholas Chase.</description>
...
<items>
  <rdf:Seq><rdf:li rdf:resource="http://www.chaosmagnet.com/blog/archives/000727.html" />
    <rdf:li rdf:resource="http://www.chaosmagnet.com/blog/archives/000726.html" />
    <rdf:li rdf:resource="http://www.chaosmagnet.com/blog/archives/000725.html" />

...
  </rdf:Seq>
</items>

</channel>

<item rdf:about="http://www.chaosmagnet.com/blog/archives/000727.html">
  <title>Virus catches child porn offender</title>
  <link>http://www.chaosmagnet.com/blog/archives/000727.html</link>

  <description>The other day Sarah told me she was a bit disturbed because she'd received an email from the FBI saying they'd found that she had visited illegal web sites. Having received many of these fake emails (usually purporting to be...</description>
  <dc:subject>Technology</dc:subject>
  <dc:creator>roadnick</dc:creator>

  <dc:date>2005-12-22T09:39:24-05:00</dc:date>
</item>

<item rdf:about="http://www.chaosmagnet.com/blog/archives/000726.html">
  <title>Graduation:  it's not just for soldiers anymore</title>
  <link>http://www.chaosmagnet.com/blog/archives/000726.html</link>

  <description>Well, I'm back from South Carolina and Sean's graduation from Basic Combat Training. After all those years of official school papers coming home and talking about "your child" it was a bit jarring, to say the least, to receive a...  </description>
  <dc:subject>Personal</dc:subject>
  <dc:creator>roadnick</dc:creator>

  <dc:date>2005-12-12T20:21:04-05:00</dc:date>
</item>

<item rdf:about="http://www.chaosmagnet.com/blog/archives/000724.html">
<title>Nerdier than I thought</title>
...
</item>


</rdf:RDF>

The feed contains information about itself, and then the individual items to be syndicated. What we need to do is add information to the feed about the what it includes, and information to each item to facilitate its being shared.

We start by defining a new namespace for the additional information:

<?xml version="1.0" encoding="utf-8"?>

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
...
  xmlns:sx=http://www.microsoft.com/schemas/rss/sse"

  xmlns="http://purl.org/rss/1.0/">

<channel rdf:about="http://www.chaosmagnet.com/blog/">
<title>Chaos Magnet</title>
...

This will enable us to add whatever information we need without disturbing the validity of the actual RSS information.

We need to add information about what is actually being shared in this feed:

...
<channel rdf:about="http://www.chaosmagnet.com/blog/">
  <title>Chaos Magnet</title>
  <link>http://www.chaosmagnet.com/blog/</link>
  <description>The personal and professional ramblings of Nicholas Chase.</description>

...

  <sx:sharing window="10" since="Sun, 1 January 2005 12:28:32 GMT"
                       until="Thu, 12 January 2006 09:02:47 GMT">
     <sx:related link="http://www.nicholaschase.com/blog/completefeed.rdf"
               type="complete" title="Chaos Magnet: ALL entries" />
     <sx:related link="http://www.informit.com/guides/guide_rss.asp?g=xml"
               type="aggregated" title="InformIT's XML and Web Services Blog" />
  </sx:sharing>
       
  <items>
    <rdf:Seq>

      <rdf:li rdf:resource="http://www.chaosmagnet.com/blog/archives/000727.html" />
      <rdf:li rdf:resource="http://www.chaosmagnet.com/blog/archives/000726.html" />
...
    </rdf:Seq>
  </items>

</channel>
...

Starting with the sharing element, we are essentially adding the information that will enable the user (or tool, for that matter) to get more information on the resources that are being shared. The window attribute specifies how long changes are kept. For example, in this case, any change is older than 10 days will not be available in this feed. The feed itself contains data from as far back as January 1, 2005, and as recent as January 12, 2006. Note, however, that that does not mean that all of that information is included, just that no information outside of that window is included.

Next let's look at the related elements. Each one describes the feed involved in this aggregated feed. First, we see information on where to obtain a feed that includes all of the Chaos Magnet entries. Now, for a blog this doesn't make particular sense, but in the case of, say, a shared contact list, in which a user or subscribing to this feed will want to obtain the complete set before making incremental changes, it's crucial. The type attribute specifies how the feed is related. In the case of the first entry, as I said, we are specifying a complete feed.

Next, I'm including information on my InformIT blog, which I'm aggregating into this feed, as you can see from the type attribute. Including this information enables a person (again, or tool) to get information on the original source. The spec also provides for optional since and until attributes for the related element.

(I should note here that the initial specification is unclear as to whether the title should be an attribute (as in the seemingly normative description) or child element (as in the examples). Until told otherwise, I choose to stick with the description. Your mileage may vary until the final version of the spec is released.)

Now let's look at individual items:

...
<items>
  <rdf:Seq>
    <rdf:li rdf:resource="http://www.chaosmagnet.com/blog/archives/000727.html" />
    <rdf:li rdf:resource="http://www.informit.com/discussion/index.asp?postid=9207b767-34e5-41c2-8768-05d831b6729e&f1=rss" />

    <rdf:li rdf:resource="http://www.chaosmagnet.com/blog/archives/000726.html" />
    <rdf:li rdf:resource="http://www.chaosmagnet.com/blog/archives/000725.html" />
...
  </rdf:Seq>
</items>

</channel>

<item rdf:about="http://www.chaosmagnet.com/blog/archives/000727.html">

  <sx:sync id="http://www.chaosmagnet.com/blog/archives/000727.html" 
           version="5" />
  <title>Virus catches child porn offender</title>
  <link>http://www.chaosmagnet.com/blog/archives/000727.html</link>
  <description>The other day Sarah told me she was a bit disturbed because she'd received an email from the FBI saying they'd found that she had visited illegal web sites. Having received many of these fake emails (usually purporting to be...</description>

  <dc:subject>Technology</dc:subject>
  <dc:creator>roadnick</dc:creator>
  <dc:date>2005-12-22T09:39:24-05:00</dc:date>
</item>

<item rdf:about="http://www.informit.com/discussion/index.asp?postid=9207b767-34e5-41c2-8768-05d831b6729e&f1=rss">
  <sx:sync id="http://www.informit.com/discussion/index.asp?postid=9207b767-34e5-41c2-8768-05d831b6729e" 
           version="1" />
  <title>Blog :: Artificial artificial intelligence: Amazon's Mechanical Turk</title>
  <link>http://www.informit.com/discussion/index.asp?postid=9207b767-34e5-41c2-8768-05d831b6729e&f1=rss</link>

</item>

<item rdf:about="http://www.chaosmagnet.com/blog/archives/000726.html">
  <sx:sync id="http://www.chaosmagnet.com/blog/archives/000726.html" 
           version="1" />
  <title>Graduation:  it's not just for soldiers anymore</title>
  <link>http://www.chaosmagnet.com/blog/archives/000726.html</link>

...

First, I should note, almost as of version issue, because I'm using RSS 1.0, if I include any additional entries in my feed, I need to add them to the items element in the channel. For other versions of RSS, this is not an issue.

Next, let's look at the individual items themselves. First off, notice that every item to be included in this shared scheme must include a sync element. This element includes a unique identifier for the item. The actual form of the unique identifier is arbitrary; choose what you like, but it must be unique across feeds. For this reason, I prefer to use the URL for the entry, though there are others that would disagree. To me, it is the only way to maintain a truly unique identifier.

The sync element also includes a version attribute that enables you to determine if the entry has been edited since the last time you downloaded the feed. This is an integer value that must start at 1 and be incremented by 1 every time a change is made.

The specification also provides for two additional attributes for the sync element. The first, deleted, enables you to create a sort of "tombstone" for an entry that has been removed. The second, conflict arises in the situation in which two people have edited the same entry and have "stepped on" each other's changes.

In fact, SSE enables you to track the history of an item. For example, you may notice that the first entry in the feed has a version number of 5. Optionally, we can track the history of these changes:

...
<item rdf:about="http://www.chaosmagnet.com/blog/archives/000727.html">
  <sx:sync id="http://www.chaosmagnet.com/blog/archives/000727.html" 
           version="5" conflict="true">
        <sx:history when="Tue, 10 January 2006 11:22:08 GMT" by="roadnick">
            <sx:update when="Tue, 10 January 2006 11:22:08 GMT"
                    by="roadnick" />

            <sx:update when="Mon, 09 January 2006 17:09:54 GMT"
                    by="sorcha" />
            <sx:update when="Mon, 02 January 2006 07:46:18 GMT"
                    by="roadnick" />
        </sx:history>
        <sx:conflicts>
            <sx:conflict when="Tue, 10 January 2006 13:26:08 GMT"
                    by="sorcha"
                    version="5">
                <item>

                      <description>The other day Sarah told me she was a bit concerned because she'd received an email from the FBI saying they'd found that she had visited illegal web sites. Having received many of these fake emails (usually purporting to be...</description>
                </item>
            </sx:conflict>
        </sx:conflicts>
  </sx:sync>

  <title>Virus catches child porn offender</title>
...

The history element includes information on when the item was updated, and/or by whom. (One of these pieces of information must be provided.) This element also contains a chronological history of the changes, each also having information on when and/or by whom the changes were made. By including information on who made the changes, you can "break the tie" so to speak if there's a question as to who's edit should take precedence. Note that you are not required to keep all changes, but you can only delete the oldest.

In the case of a conflict, you have the option to include information on what the conflict actually was using the conflicts element. This element enables you to note when the conflicting change was made, and by whom, as well as what version is in question. You also have the option of including the actual changes that were in question in the body of the element. SSE provides an algorithm for determining whether or changes conflict, as well as a process for "resolving" these conflicts so that changes can continue to be made.

And that, in a nutshell, is it. I've focused here on RSS 1.0 because that was the example I was using, but the specification refers only to SSE in RSS in general. It also defines how SSE can be used in OPML files. What's more, there's nothing stipping you from using SSE in other syndication formats such as Atom.

At the time of this writing, the spec is just been released, and there's no sample code that implements it, but in general it is fairly straightforward. At the very least, you can add this extension to your own RSS feeds, so that when someone finally built an aggregator that pays attention to them, your content will already be SSE enabled.

For more information on Simple Sharing Extensions, check out the following:

• The Simple Sharing Extensions (SSE) specification
• The Simple Sharing Extensions (SSE) FAQ
• Ray Ozzie's Simple Sharing Extensions (SSE) announcement
• More information on RSS
• More information on Atom
• More information on OPML