I can't understand why people are making so much noise over the use of clipart person pictures in the Microsoft testimonials.  Apparently, people are applying different standards to Microsoft than to breasts.  Hey, if it looks too good to be real, it probably isn't.  Besides, I don't think there was anything in the testimonials that said the picture was that of the author.  Its shabby practice, but I doubt anyone making noise now expected anything better from Microsoft before.

I hate XML Namespaces.  Its ugly and difficult to grep (pun intended).  Its also makes hand coding XML difficult since one has to remember those namespace URIs.  There can be no defense for XML Namespaces, for the controversies over it can not be denied.  While RSS 2.0 introduces XML Namespaces into RSS, I intend to present a simpler approach that does not use XML Namespaces.

In RSS, there are two areas where extensions are most likely, inside <channel> and inside <item>.  To support extensions in these two areas, we introduce three rules:

1. RSS parsers must ignore unknown tags.
2. Unknown RSS tags are opaque – this means you cannot enumerate its children.
3. Encapsulate custom tags inside a tag whose name starts with domain name.

Here is an example:

<channel>
  …
  <com.docuverse.daily.tags>
    <title>semantics of extension tags are context sensitive.</title>
  </com.docuverse.daily.tags>
  <item>
    …
    <org.slashdot>…</org.slashdot>
  </item>
  …
</channel>

This approach to extensions can easily be manipulated using simple regular expression based tools.  Its easy to read and write.  Its namespaces done right.  Its a solution that is willing to sacrifice that problematic 20% in return for simplicity.
   

RSS is currently used for syndicating unstructured textual data, but Web consists of wider variety of resources such as images (see my Syndicated Image and related use cases posts), sounds, movie clips, animations (Flash and SVG), PDF, packages (ZIP, gz, etc.), and structure data (XML).  How do we syndicate these resources using RSS?

Here is one approach.  Add 'type' and 'encoding' attributes to <item> for specifying item's MIME type and encoding method.  Default MIME type is 'text/html'.  There is no default encoding type and unspecified encoding type means it is unknown.  Alternate versions can be use multiple <item> with matching <guid> with order of appearance indicating the order of preference.

An RSS channel typically has one writer and multiple readers.  Some bloggign software allows multiple writers per channel, channel sharing is limited to the deployment site.  How can we have shared channels across sites and writers?

First, feed directory services like syndic8.com and weblogs.com must support multiple channel feeds per channel.  To identify channel, we can either use the channel title or add <guid> to <channel>.  With <guid> approach, title coherency is a problem.

Second, some arrangement must be made to make it easy to subscribe to shared channels.  Client-based approach could start with one feed and find other feeds for the channel either directly from a channel directory service or from the feed itself.  In later approach, each feed is responsible for finding other feeds for its channel.  Server-based approch relies on channel directory services like syndica8.com to provide channel feed aggregation service.

I am done with an initial pass over my Java RSS Parser.  Its supposed to handle all variations of RSS including 0.9x, 1.0, and 2.0.  Its a forgiving parser designed to handle the meanest and ugliest RSS feeds.  It still requires well-formed XML though.  I'll add a regular expression based version as a fallback parser to handle not so well-formed XML if there is a need.  I'll need more information on variety and quality the feeds out there though.  If you have a RSS feed, this baby will likely visit you sometime over next few days.  Its name is Daily, Docuverse Daily that is.

You can now put two spaces between sentences with Movable Type using a plugin by Kelsey Group, thanks to a suggestion by Scott Johnson.

Here are some use cases for Syndicated Images:

• News Images – news organizations have hundreds of thousands professional photographers around the world.  As news happens, bloggers will talk about them and photos taken by the photographers will help spice up those posts.  Throw in millions of amateur photographers and you got enough chaos to drive major market shifting events.
• Porn Images – porn businesses and enthusiasts (?!?) joins the blogspace.  Replace all those free thumbnail websites causing popup hell with image syndication.  Keep track of your favorite porn stars by subscribing to their image feed.
• Space Images – NASA and observatories can syndicate images taken by all those fancy telescopes for consumption by space enthusiasts.
• Style Images – designers and clothing industry can distribute images of latest design and fashion.  Wanna keep track of latest in bikini?  Kiss my RSS.
• TV Images – keep track of your favorite TV shows by subscribing to image feeds of memorable moments, upcoming episodes, and behind-the-stage images.
• Food Images – we got zillions of restaurants, cooks, moms, and food enthusiasts.  When they talk about food in their blogs, they will want pictures.  I want a picture of Kimchee!
• Talent Images – actors, models, talent agencies can provide feeds of their latest portfolio and clients.
• Destination Images – what better way to publicize your hole in the wall tourist spot than with syndicated images?  Hand your bellboy a digital camera and feed images of incoming guests.  Oops, she is not your wife, monsieur?

I could go on and on, but I gotta make a living.

Scott Johnson asked me to expand on my Blog Inline Image Service idea so here is the result of a cup of coffee.  There are two parts to the idea:

1. Syndicated Images – Allow people and organizations to syndicate images along with associated title, link, and description.  RSS already has <image> tag used for channel image, so all we have to do is add an attribute to distinguish non-channel images and allow multiple <image> inside <channel>.  I would also add a child element for specifying suggested use (i.e. icon, blah, blah).
2. Blog Inline Image Service – Integrate blogging tools with web services that provide content-related images to be inlined into weblog posts.  The idea is to make it really easy for bloggers to add images to posts by searching image database with words and phrases extracted directly or indirectly (by association) from the post content or the channel title and description.

Tie two parts together and you got something neat.  Imagine writing a post about Bill Gate and being presented with a selection of Bill Gate pictures including one taken this morning by himself.  Cool!

It would be cool to have an online service that integrates with blogging software to provide small images to be inlined in blog posts.  When a post is made, blogging software shows a small selection (based on the words and phrases of the post) of possible pictures to be inlined.  This service could be offered as a premium service for around $5-10 per month or so.  Just thinking out.