September 2002 Archives

[UPDATE Oct 19 2002: A maintenance release is now available to fix a few bugs. Users of version 0.1 are recommended to download this new version.]

The next version of mt-rssfeed will feature the ability to loop through a list of URIs to RSS syndicated resource feeds. This feature will avoid the laborious and inefficient practice of cutting and pasting the same blocks of template code to insert multiple syndication feeds.

I believe this functionality would be useful independent of mt-rssfeed plugin and have chosen to release it as its own plugin called mt-list.

The initial release of mt-list, a plugin for creating lists within a template or text file, is now available here.

This provides the following functionality to MovableType templates:

• Creating a simple list from line-feed delimited MovableType data or from an external file.
• Looping through a defined list
• Looping using random non-repeating selection or...
• ...a specific count with an offset.
• Looping sorted in ascending or descending textual order.

More detailed documentation is included in the code.

[UPDATE October 4 2002: A second draft has been published here.]

I continue my exploration of syndication formats. Inspired by some of yesterday's conversations on the RSS-DEV list and past proposals for a simple core I drafted up a more detailed description of such a format. (I'm releasing it in the spirit of "release early, release often.") It maintains backward compatablity with RSS 0.91 and its descendants.

From what I can tell this is the same format that Sam Ruby and Mark Pilgrim proposed except I've documented it in more detail and have classified it as a profile (a restricted subset) instead of a specification. Feedback and suggestions to improve this description are greatly appreciated.

I've set up my weblog to produce feeds in this format (here and here). The MovableType templates I'm using can be found here and here.

[UPDATE: Mark Pilgrim and Justin Rudd have written in to point out that I forgot to add an RDF namespace declaration to the XSS-extensible format. Thanks gents. Fixed. (The RSS 1.0 modules use RDF to structure the extensions in a principled way and avoid trouble.)]

Extremely Simple Syndication (XSS) Profile

DRAFT 1

ABSTRACT

The XSS profile defines a restricted subset of previous RSS formats that balances ease of use and authoring with ease of consumption by applications while maintaining the richness necessary to extended and adapt to various problem domains. It is designed for applications operating in resource constrained enviroments such as mobile phones, PDAs and other devices or sites needing to conserve bandwidth for economic or physical reasons. It is also designed for authors wishing to provide a well-formed "feed" of information to consumers.

The XSS profile is designed around a simple common core of elements that may be extended. It is also designed to maximize backwards compatability with the RSS 0.91 format and its decendents. This allows XSS to leverage the existing install base of 0.91 feeds and prior bodies of work such as Dublin Core meta data and RSS 1.0 modules. The XSS profile contains three document types -- Transitional, Strict, and Extensible.

The goal of the XSS profile is to serve as guidelines to best practices in a balanced and simplified approach to authoring and consuming of syndicated resources with RSS.

COMMON CORE TAGS

<rss>
Description: The root tag for the syndicated resources collection.
Sub-Elements: channel (required)
Attributes: version - a string identifying the version including profile and document type.
Notes: Only one channel is permitted.

<channel>
Description: Container tag for a specific channel
Sub-Elements: title (required), description (required), link (required)
Attributes: none.
Notes: Only one title, description or link is permitted. Language is deprecaited.

<item>
Description:
Sub-Elements: title (required), link (required), description (optional but highly recommended)
Attributes: none.
Notes: Recommended to not exceed 15 per channel.

<link>
Description: A unique URI that specifies the location of the channel or item (resource). A required sub-element of channel and item.
Sub-Elements: none.
Attributes: none.

<description>
Description: A plain text excerpt of the channel or item (resource). A required subelement of channel. Optional, though highly recommended, sub-element of item.
Sub-Elements: none.
Attributes: none.
Notes: The XSS profile supports plain text and does not permit encoded markup such as HTML to be included in the description. Recommended not to exceed 500 characters. Those wishing to embedd markup language or larger pieces of content in the description tag should use the mod_content module.

<title>
Description: A plain text descriptive title of the channel or item (resource).
Sub-Elements: none.
Attributes: none.
Notes: Is the equivelant of the HTML title and only supports plain text. Encoded markup such as HTML is not permitted to be included in the title. Recommended to be no more then 100 characters.

DEPRECIATED TAGS

Tags not defined other tags from RSS 0.91 and its decendents are considered depreciated from the core in the XSS profile. This data can be furnished though various modules such as Dublin Core, mod_content and mod_admin. All depreciated tags in the XSS profile where previously considered optional except language which was required by the 0.91 specification, but made optional in later specifications.

DOCUMENT TYPES

Transitional. RSS 2.0/XSS-transitional. Depreciated tags such as language, copyright, and image found in the 0.91 format and its decendents allowed, but should ignored be ignored in favor of their extension module counterparts. All depreciated tags in the XSS profile where previously considered optional except language which was required by the 0.91 specification, but made optional in later specifications.

Strict. RSS 2.0/XSS-strict. This document type only permits the use of core elements. Depreciated tags are not permitted. This document type does not expect the use of extension modules in order to maintain a simple light-weight footprint. Authors requiring more rich metadata and/or extensibility should use the Extensible document type.

Extensible. RSS 2.0/XSS-extensible. All the stated expectations of the Strict document type apply except modules are permitted and expected. With this added capability to to the document type, the X can be considered as representing 'extensible' rather then 'extremely.' Extensible Document Type can become quite complex and tedious to author without automated tools for generation.

Without detailed information to extending RSS 2.0 with modules and XML namespaces, the XSS profile Extensible document type will follow the guidelines of set forth in the RSS 1.0 format module's guidelines.

EXAMPLES

• XSS-strict example
• XSS-strict prototype of my weblog.

• XSS-extensible example using Dublin Core, mod_content and mod_admin
• XSS-extensible prototype of my weblog.

OUTSTANDING ISSUES

• How to Identify the profile/document type. place in version or use XML document type?
• Should build DTD and/or schema?
• Some deprecaited tags are lacking corresponding modules.
• Need to list out deprecaited tags and map to specific modules and fields.
• Add Background and Requirements section?

Rael Dornfest has started a mailing list for "announcements, contribution sharing, feature requests, bug fixes, Q&A, and so forth" about blosxom his ultra-lightweight weblogging tool.

Jon Hanna gives his admittedly late comments on Shelley Powers' questions.

The Internet and the Web both have current uses quite different to those, and many of their parts are used in manners further removed from their origins (e.g. the use of HTML in many Windows technologies doesn't even make use of the Web's distributed nature).

I maintain that RSS is such a technology. It's designed purpose is the syndication of "news" items from individual websites to a portal website, to be more specific to the MyNetscape portal website. It was *not* designed to be of any particular use to bloggers, aggregators, or metadata providers, but it *does* serve them and others.

Morbus Iff asked "Why is RSS 2.0 bad?"

Dan Brickley replied:

My concern: it introduces the ability to use XML namespaces for future extensions, whilst simultaneously failing to use it for the extensions introduced in 2.0. If those extensions were folded into an extension module, 2.0 and 1.0 would be both technically and conceptually a lot closer. The core of RSS doesn't need much more than 'item', 'channel', 'link', 'title', 'description'. A simple common core could represent that.

Ben Hammersley replied:

...my major concern is also with the namespaces. There appears to be no indication as to how modules should work. With RSS 1.0 there is, more or less (whoa there), a 'grammar' of sorts that tell us how to relate the data within, and how to describe the vocabulary with a schema. With 2.0, there is no guidance, and no thought as to how to deal with the world when there are 50+ modules. Without blathering on semanticwebbaly, I really really like the potential for schema-aware readers that comes with RDF, and the discipline it imposes. I'm lacking that cosy feeling with 2.0.

Morbus replied to Ben:

Ok. Well, if you want, I can take the 1.0 Module Building doc, turn it into a 2.0 Module Building doc, and then that "2.0 roadblock" will be removed.

He later announced that he had begun drafting up "Extending RSS 2.0 With Namespaces"

Sean Palmer posted a detailed (read: long) list of issues. Dave Winer replied on his web site.

Phil Ringnalda writes:

I am not a developer. I am not a professional. I am an interested amateur publisher. I am your audience.

Dave Winer: "I'm going to start posting to this list as long as personal comments about me don't dominate."

Morten Frederiksen notes:

The "simplicity" of HTML was great for its quick widespread production, but as mentioned elsewhere, it's a pain to consume.

This is, I believe, because simplicity is confused with "optional" and other lax definitions, either in the definition or the use.

I would have thought that a lesson was learned there, that what is really needed is *strict* definitions, at least if it is in any way meant to be consumed by machines.

I.e. a <description> element that is not defined as to its contents, and a <link> element that can point anywhere, is useless in practice, even though it's easy to produce.

This is why I like vocabularies like the Dublin Core, which provide precise definitions for syntax and semantics. They may be somewhat more difficult to produce, perhaps needing date format conversion, but they are easily used.

This is also why I dislike RSS 0.9x - it's too loose, it is unusable for anything *but* "the display of headlines in a browser for human consumption", and why I think that the path of RSS 1.0 is better.

The discussion continues.

Its a little known fact to most of you that I used to run an indie music zine for over 7 years called Oculus Magazine. It started out in October 1991 as a free newsprint publication. In 1995 we started posted articles to the web. I loved it and learned a lot about publications, critical writing, and the Internet. (I also lost a lot of my own money, as did my partners in crime.) Alas, we eventually grew bored and burnt-out and Oculus cease operations. I was very uncool and took the site's content down.

Seeing an awesome publishing tool like MovableType pains me inside because we really could have used it back then. Most of my work on the Web site was spent manually coding and maintaining HTML with a lot of SSI tricks. (I wrote scripts to generate our own RSS feeds back in 1999 when Netscape for released it too.)

I miss those days and I've been thinking about putting restarting Oculus as a weblog. Today I woke up and decided to do a little bit of something about that.

One of the most popular articles we ever published was a "Jazz Primer for Rock People." Today I decided to pull that piece from my archive and put it back up -- nasty HTML 3.2 and all. I was still getting a couple hundred requests for it a month despite the content being down for a couple of years. I'll have to go back and clean up the markup and link it better.

We used to run a column penned by one Jim Glauner called "Cringe Factor: Music We Hate." Each issue I couldn't wait to read the draft Jim would hand in. I used to laugh so hard I'd cry reading his work.

I've been encouraging Jim for a bit to start publishing Cringe Factor as a weblog. I even setup one up and added all of the past columns he wrote for Oculus. Check it out here. My personal favorite was "Not Even Retarded Kids Will Like It."

Not many people know this, but I wrote a book a few years back called 1001 Ways To Improve Your Band Right Away. Rule 77 is "Burn all your Chicago records. However, like Dracula, Peter Cetera solo records must be rent with a wooden stake, or else they'll return to haunt you." Rule 915 says, "Fire your glockenspiel player," and Rule 136 says, "If Phil Collins is in your band, lose him like a sock in a dryer."

It only gets better from there.

Jim wrote one entry, but hasn't posted since. If you like what you read please send him a message and encourage him to write more.

The ever-insightful Jeremy Allaire offers his views on "holistic Web services."

...I've continued to be annoyed by the narrow-minded thinking that has dominated discussions of web services to date. Like many IT technologies, the central thrust of the web services worldview has emerged from the classic middleware infrastructure providers, which has in turn colored our thinking on web services significantly. The essential problem is that web services as defined by a core collection of XML protocols (SOAP, WSDL, UDDI) focuses almost entirely on API-level application integration, rather than a broader view of how software will be created, distributed and consumed in the future.

Jeremy goes on to discuss the relationship between Web services and Application Service Providers (ASPs) in addition to "the missing pieces" in ASPs vision.

He concludes, "let's turn the debate around and focus again on the broader vision of software as service rather then keep ourselves down in the plumbing....."

Amen. This is the exact notion I had in mind when I wrote "Flash MX and the Bigger Picture: Lightweight Internet Applications".

[UPDATE: Just catching up on my reading I found that Jeremy also has posted an equally as insightful piece on "The Problem of Scale" that is also worth a read.]

Shelley Powers, through her weblog and posts to RSS-DEV site, offers a refreshingly different and enlightening take on the current discussions about RDF in RSS that has clarified much for me.

The title of her post "Who is your audience, and what are you trying to accomplish?" is her overriding point and brings into focus a crucial issue that is seemingly at the root of much confusion circular debate.

If RSS, past and current, is based on providing syndication and aggregation feeds, and nothing more, than I agree with those that say RDF adds nothing to the mix, and not because RDF adds complexity -- the reason is because the business of RSS isn't necessarily compatible with the business of RDF.

She continues:

If this group wants to continue providing a specification that defines syndication feeds, then it needs to consider that RDF not only doesn't buy the group anything -- it can harm the tool developers that use the spec. (Not to mention that trying to use RDF inappropriately can actually negatively impact the acceptance of the RDF specification.)

If, however, this group sees that what they're working on transcends throwaway syndication feeds, then it needs to formally define exactly what the business is _before_ trying to create a spec that implements it. Hence my questions: who is your audience and what are you trying to accomplish?

In echoing these thoughts on the RSS-DEV list, Shelley asked for some use cases of RDF in RSS in which Danny Ayers offers two:

*** Use Case 1 : Meme of the Moment ***
How do I find those events?
How do I find the people involved in those events?
How do I find the location of those events?
How do I find future events related to these?

The first of these is 'news-like' data, the other information is relatively static. I want this all in a feed.

*** Use Case 2 : Dubya Gets Drunk ***
A newspaper can provide a news headline saying 'Dubya gets drunk', which is fine, if the readers already know all about Dubya. If they don't, then the newspaper can provide some background in Section 2. The background information about Dubya will remain relatively constant, but the headline will change. If semantically rich data is available, then that background information can automatically be linked into the feed.

Shelley responded that case 1 expanded the scope of RSS beyond its current use, and that 2 was in scope and fits a potential need. However her question of purpose and audience where never really answered or agreed upon which prompted her post today.

Making a long story short: though I respect many of the individuals involved with RSS 1.0, their effort and hard work and intelligence and capability as well as energy, I can't continue to support RSS 1.0 or RSS-Dev. Not with this current level of confusion about what the group sees as its purpose.

Unfortunately, not supporting RSS 1.0 is seen as giving victory to Dave Winer at Userland, by forcing us into choosing an RSS 0.9x/RSS 2.0 path. However, I still don't approve of Dave's approach to implementing RSS and his unwillingness to give up ownership of it. I can respect Dave's contribution, and his hard work and effort, and his intelligence and capability, but I can't support a supposedly 'open' spec that's controlled by one company.

Ultimately, supporting either specification means, to me, continuing to support this competition between the groups, competition which threatens to Never...Go...Away, as can be seen in the comments to Phil's posting.

Sometimes, when I read these types of comments, I feel as if you and I don't matter at all; that you and I are nothing more than scraps of meat being fought over by two junk yard dogs. Well, this just peeves me. So, I'm taking the route that's been available to consumers since the beginning of time: I'm not buying.

I understand how Shelley feels. I've appreciated her comments on the RSS-DEV list recently as they have clarified a lot of my confusion and given me a new perspective.

In related news and in commentary made to one of Shelley's posts, Dave Menendez wrote:

This thread got me thinking about what makes RSS useful in the first place. What is RSS about at its core?

My understanding now is that the key feature of RSS is the list of items in the channel. Everything else--textareas, images, titles, descriptions--is secondary (but useful). Boiled down to its essence, the essential part of RSS is rss:items.

Dave has authored a proposal he calls RDF channel that is quite an intriguing and interesting concept. Assuming it fits the purpose once (if?) it's defined.

Yesterday I joined the SETI 1000 data units completed club. Just doing my part in the search for extra terrestrial life.

In his O'Reilly weblog post yesterday, Simon St. Laurent gives his commentary on a warning by Ari Krupnikov about the "ever-growing complexity" of XML technologies. Its an interesting viewpoint to consider. I have similar worries that XML technologies are getting to complex, voluminous and downright heavy, but not to the extent or dismay that Simon expresses. This particular quote rang quite true:

Krupnikov suggests that this complexity isn't an accident. Although some find his suggestions "conspiratorial", it doesn't sound all that far from business as usual by large vendors forging ahead with business plans that they can, in the end, control.

This quote raises a very difficult issue that is not black or white, but very grey. Commercial interests and simple, open and ubiquitous technologies are at odds with each other in a continuous tug of war. These strange bedfellows are a necessary evil to maintain innovation and investment in the space. As technologist we need to be mindful of this and work to maintain a balance that everyone can benefit from.

There has been some interesting discussion over at Sam Ruby's weblog about how to track and enhance comment threads. RSS, publish-and-subscribe mechanisms, instant messaging (IM) and TrackBack all have entered into the conversation.

Sam has now Trackback enabled his non-MovableType (MT) weblog in furthering the discussion. I also noticed that recently Rael Dornfest and Rajesh Jain added TrackBack to their weblogs.

I'm glad to see this type of experimentation final starting. I've always thought that TrackBack was quite an interesting and novel idea that deserved further experimentation and consideration. I've been a bit disappointed that its taken this long to start up. I'm getting over that now.

[NOTE: This is a re-publication of my debut as an O'Reilly weblogger that I made eariler today.]

Last week Sun Microsystems announced plans to offer low-cost desktop computers running open source software such as Linux, GNOME, Mozilla, and their StarOffice productivity suite in addition to identity management capabilities (via smart cards) and their portal software.

I couldn't help but roll my eyes and be a bit disappointed. It's not that I don't respect Sun's accomplishments or that I take great issue with their technical ideologies. I would also not call myself a big fan of Microsoft as a developer either. (I'm quite the contrary these days.) You have to give Sun credit for their "cahones" in challenging Microsoft for so long and continuing to live to tell about it.

According to Sun, 38% of customers surveyed are considering alternate products to Microsoft's. Their survey also found that 90% expect software licensing costs to continue rising. Sun believes that their research indicates there is a great opportunity here. I would have to agree, but am disappointed because their announcement didn't speak to the real opportunity at hand -- to redefine the desktop and differentiate their view.

I think that Sun is too optimistic in its primary reliance on price and total cost of ownership, or TCO. It overlooks the fact that most of the corporate workforce already has a PC and applications that they are familiar with on their desks. Furthermore, replacements for the hardware are available at lower commodity prices. What is the advantage to Sun's proposition if Microsoft modifies their licensing and pricing to close the gap tomorrow? That they are running free software and "sticking it" to Microsoft? This is not nearly as relavent to most end users as it is to Sun.

In order to make a long term desktop play and provide a true alternative to Microsoft's vision, what we know as the desktop must be redefined, not duplicated and made "free." History is littered with the carcasses of companies that have failed to compete with Microsoft on the basis of price/performance.

The notion of redefining the desktop isn't so radical when you consider it has changed very little despite the establishment of the ubiquitous Internet platform and its continuing evolution through initiatives such as Web services, P2P, and wireless networks. The desktop as it exists today is not suited to take advantage of these capabilities or to scale in broad decentralized deployments -- like most corporate office staff that use desktop system to get their work done.

A prime example Sun should note is HomeBase DESKTOP, a task-centric Linux desktop alternative that utilizes Red Hat Linux and Mozilla developed by OEone. HomeBase includes a web browser, multiple account email, basic word processor, calendar, address book, multimedia center and a customizable personal portal. It can also integrate any existing Linux applications into the environment. OEone also offers HomeBase ANYWHERE that gives users access to their information from multiple machines or any machine with an Internet connection and a browser. It’s far from perfect, but highly intriguing and refreshing to consider.

Office productivity tools are also in need of a rethink -- or perhaps a diet would be more accurate. It's been my experience that most features in Word, Excel and PowerPoint are rarely used by most of us. Their existence only weighs down the application requiring more powerful and expensive hardware in addition to distracting and confusing the average user. I recall working with WordPerfect 5.1 and Lotus 123 over a decade ago and comparatively speaking MS Office offers me little additional functional value. (These were apps that came on a couple of floppy(!) disks and ran on 386 processors with 4MB of RAM.)

I tried out OpenOffice, the open source community version of Sun's StarOffice, and abandoned it after a short while. While I was impressed and commend that community's effort and dedication, it wasn't really different from what I already had. I'm ready to switch to an Microsoft Office alternative, but not just because it’s free and not because it isn't Microsoft.

The opportunity to provide a true alternate to Microsoft continues to develop. The key is not in duplicating it with a lower price tag, but in redefining it. I can only hope that Sun and others come to realize this before repeating history and leaving us with a promise unfulfilled.

Tim O'Reilly posts his answer to the question "is O'Reilly a free software business?" that was made on the free software business mailing list. He also points to an answer made by Simon Cozens that he particularly likes:

For programmers, writing software is fun. It's actually enjoyable to produce a free version of something you "can't" have because it's proprietary. Why do people write free software? Because it's either necessary to have a free version, (whether pragmatically - we need a free version of this software because there isn't a commercial one we can actually use - or dogmatically - because we believe that everything should be free) or it's fun to do.

Documentation is different. For most programmers, writing documentation isn't fun. So the question is, is it necessary to have a free version? If there's a reasonably-priced book available in a shop, it's probably not pragmatically necessary. That only leaves dogmatic necessity. And that's pretty weak - the only people who are really interested in dogmatic necessity are those who spend more time playing politicians than they would writing documentation anyway.

The RSS-DEV list has been alive with much discussion and debate to the future direction of the groups efforts. Bill Kearney made a motion to consider a potential name change of the specification given the nasty circumstances and the potential mass confusement that sparked a discussion of redefining the format's purpose. The extent of RDF's roll in what I humorously refer to as the "format formerly known as RSS" or FFKAR (I'm going to be called a problem or a rat or a monster yet) continues to be a hot topic of discussion and debate. I like what Sam Ruby and Mark Pilgrim proposed (stripped down core, namespace support, but no RDF), but I can't help but be intrigued by RDF and its declared potential. Late this week dove into the debate to play devil's advocate to the many well-meaning and passionate advocates of RDF. My hope is to strike a balance between the most RDF support with the least amount of markup while improving my understanding of RDF's merits and uses in FFKAR and beyond. Maybe others will learn from my public ignorance.

Jon Hanna posted his strawman year-zero proposal. It was an interesting and valiant attempt, but my personal view is the "RDF tax" (syntax and rules) are too heavy. The developer community will struggle to understand its use or value and soon thereafter revolt.

As I wrote on the RSS-DEV list, ideally I see the purpose of FFKAR as "...a simple (single?) focus that has broad applications is the way to go. Different 'features' and restraints will come from extensions (modules) and their combination dependent upon the problem domain." I continued, "[The format] should be a simple core of a handful of elements and an absolute minimum of required RDF structures. (Additional RDF would come through optional extensions.) It is a simple, yet extensible, format to represent a collection of resources (URIs) with meta data. When I think beyond news syndication and weblogging this notion of a "collection of resources" makes a lot of sense to me. It is simple and focused, but can be applied to virtually anything and extended for specific problem domains. It also ties into the principles of Web architecture that the W3C and REST advocates profess."

In the spirit of friendly debate and experimentation, I've created my own FFKAR experimental format proposal that is based on one first made by Shelley Powers and later refined by Sean Palmer. A simple version is here and a meta-rich version is here. The MovableType template files can be found here (simple) and here (meta-rich).

They are both well-formed XML and valid RDF. What I like about this format is how it streamlines the overall syntax and still supporting RDF. According to Sean's original post, its using the DAML list construct that has been approved, though not formally to be added, to the RDF namespace in the future. (The W3C RDF validator doesn't support this yet so I used the DAML namespace.)

My modifications where in fact minimal to what Sean produced. (Like I'm an RDF master.) I took the Dublin Core elements back out of the core in keeping with a small tight core. I also changed some of the tag names to all lowercase.

This format is not perfect, but it demonstrates what I think is an important consideration in these proceedings.

The redundant info rss:link and rdf:about will be questioned. Does this have to be this way? In order to not completely break existing aggregators and toolkits you have to leave the rss:link tags. In order to not break with RDF standards you need rdf:about. This is one area that perhaps will have to be solved with education and evangelization over time.

This format does break backward compatibility with all previous specifications. As I have mentioned asserted before the question of compatibility is a difficult one. Its my belief that, under the current circumstances, backward compatibility with existing aggregators and toolkits is more important. I tested both feeds with my liberal parser/MovableType plugin (worked fine) and AmphethaDesk (choked).

This format limits the file to one channel. Personally, I think this is a good thing, but others I know disagree. Someone noted on the RSS-DEV list (I can't recall who) that an item can belong to multiple channels. While understandable, I worry that this capability will be taken too far. The issues of bandwidth efficiency and processing multiple channels and mapping items are likely to outweigh the benefits. I make it a policy of staying out of trouble by avoiding it all together.

Food for thought. Your comments are welcome.

Mark Pilgrim points to Bill Kearney who asks "what's so bad about RSS 1.0?". My instinct is that that the added syntax for ordering is seemingly redundant and/or of little value to the average developer's needs now. This is a question I have to ponder further though. I'd be interested to hear others' thoughts.

Mark and DJ Adams continue their exploration in RDF sharing their links of interest and thoughts along the way. Thanks guys.

Mark has also begun experimenting with the RDF-based FOAF (Friend Of A Friend) format this weekend. Mark wonders what this buys him, but notes he'll try anything once. (Me too.) He is"scrounging" for FOAF files to add to his profile. I've added my FOAF to the world here.

Infoworld is reporting Microsoft announced at DemoMobile that they have come up with the killer application for mobile: Location.

I laughed maniacally when I read this. Its not that Microsoft is wrong. They are quite right. I laughed because I had to wonder "what took everyone so long?!?" Is it so hard to fathom that location would be a crucial factor in mobile data services?

I worked for a company that did some consulting on mobile back when it was the next big thing. It became abundantly clear then that, as they say in the real estate business, it was all about "location, location, location." Despite names like the "wireless web", mobile Internet services are used in a very different context then from a desk with a full keyboard and large color screen. The user's environment necessitates the need for short, time sensitive location-based chunk of information. Mobile users do not surf.

Over two years ago I visited Seattle for the first time. Armed with my then new Blackberry 957 and with a WAP browser I was walking around with a colleague looking for a place to eat. Being enthralled with the power of mobile, I pulled out my device and went into 10best.com's mobile service to find a seafood restaurant. Dozens of clicks and 40 minutes later we found a place almost by dumb luck. I had to navigate through several levels, (Portal menu to 10best menu to Seattle to restaurant to seafood etc.) and manually scan each listing to make a determination. Besides being laborious, I was never in Seattle before and didn't know where most of these locations where relative to where I was standing. I never tried that again.

When asked by clients if they should build mobile app X, we would advise "only if it is better and more convenient then other options." With this understanding mobile applications location because the differentiating factor from mediums like the desktop. This makes location a near requirement to good mobile applications.

In all fairness, I do have some sense of what took so long. Determining location of a mobile user is difficult. Global Position Systems (GPS) requires too much power. Cell-tower triangulation can be highly inaccurate especially in big cities such as New York where signals ricochet off buildings. Determining location also requires the roll out of additional equipment. I am of the opinion that location was more important to mobile data adoption then 2.5G and 3G bandwidth and that the telcos place their efforts in the wrong place.

Going back to my trip to Seattle, ideally I should have only had to select restaurant recommendation and perhaps the type, seafood. I should have then received a list of 3 or 4 of the closest right away because the application new I was in Seattle standing near the Pike Place Fish Market. My personal killer app when I did a lot of business travel would have been a service like this for locating the nearest Starbucks. One click and "Here is the closet Starbucks. Do you want directions?"

In another astounding revelation, CNET is noting that "Push technology is finding redemption in millions of cell phones." What is this push technology? SMS and always-on wireless email. (I developed a homespun solution with Blagg that pushes news excerpts to my device periodically throughout the day. It took me less then an hour to setup.) Once again this makes a lot of sense, but I am astonished at how long it's taken the industry to get it right.

I've always enjoy reading Adam Bosworth thoughts on Web services and hearing him speak. He needs a weblog! (Anyone with a line into him, please let him know.)

Paul Prescod points to a recent article by Adam, "One Fell Swoop," and gives his commentary. Like Paul, I agree with many of Adam's views on Web services. I find Adam to be the most rational and practical voice representing the "commercial Web services product" space. I'd be curious to learn what his thought on REST are. With his obligations to BEA perhaps he cannot.

Once again for the record, I am not a devotee of REST, but I think it makes some good observations that should be noted by the Web services community. My interest in REST is to better understand its priciples and how it contrasts and compliments SOAP et al in order to develop the best solutions with parts of both.

With today's post of his latest missive "Monsters" Dave Winer has taken the "RSS wars" to a whole new level of ugliness. This is sad and nothing I'm going to dwell on, but I am shocked and appalled even after my exchange on Blogroots yesterday. In my exchange with him he told me to be " positive" and "take the high road." I respectively disagreed with his definition of what that high road was, but this what he had in mind?

Yesterday I said he was "incorrigible." Today's post proved he is no longer capable of participating in further discussion of RSS and is now irrelevant.

My letter to the editor gets printed in response to David Berlind's "Binary compatibility: Holy grail or red herring?" The letter was based on this post I made some time ago.

Dave Winer announced "The new target date for RSS 2.0 is Tuesday of next week. Maybe Wednesday. But no later than that." This is despite issues objections and issues raised by the likes of Sam Ruby and Ben Hammersley. An interesting thread on RSS was started over at Blogroots. I have a refreshing debate with Dave Winer ending with his trademark answer-tough-questions-with-the-same-question technique. (My apologies to Meg and all for taking the thread off track.) This dialog was constructive for me (and I hope others) because it help me determine that he is incorrigible and that I should spend my effort elsewhere. I'm starting right now.

There is some coalescing in the community on balancing the simplicity and extensibility (via XML Namespaces) of future RSS formats. The topic of constructive conversation is currently centered on RDF -- how can the "tax" by minimized or does it have a place in RSS at all? RDF is not fully understood by most to really say (a problem for RDF) so there is a lot of instruction on its merits being exchanged. Here are some links on the subject:

• DJ Adams: The RDF in RSS.
• Shelley Powers: RDF: As simple as A, B, C.
• XML.com: What is RDF?
• Ziv Caspi: RDF: As simple as X, M, L.

There seems to be two unification "2.0" formats that are resonating through the mailing lists and weblogs talking up RSS. One derived from the thoughts of Sam Ruby with refinements by Mark Pilgrim. Another is the RDF-friendly proposal made by Shelley Powers and refined by Sean Palmer. Interestingly both proposals break a certain amount of backward compatibility with previous specifications. This is still (at least to me) an outstanding issue -- compatable with what?

RSS 0.91 broke compatibility with 0.90. 1.0 is based on 0.90 while 0.92-0.94 is based on 0.91, but breaks backward compatibility with it. Yet most aggregators and toolkits (I just finished developing one) will derive basic RSS feed information irregardless of which specification a feed may or may not comply with. Standards are not as useful as applications, shouldn't the primary concern be a format that works with most applications rather then a specific standard or fork?

In order to settle this argument, I'm of the mind to let backward compatibility of the specifications suffer a bit in order to serve the greater good of developing a strong "core" with extensibility through namespaces. (I keep an open mind on RDF and have yet to form an opinion.) This is why I like and support the proposals by Mark/Sam & Shelley/Sean and will be studying them more closely.

RSSFeed v0.35, a MovableType plugin for retreiving and inerting RSS feed content into templates, is now available for download here. (Finally.) This release is a maintenance release to fix a few things and test a new parser module.

This release includes an additional module, XML::RSS::LP, a liberal RSS parser. This parser is "liberal" in that it does not demand compliance to a specific RSS version and will ignore tags it does not expect or understand. The parser's only requirement is that the file is well-formed XML. The module is an improvement over the XML::RSS module that versions prior to version 0.35 utilized in that it is leaner -- the majority of code was for generating RSS files which is of no use to us here. XML::RSS::LP will also fall back on XML::Parser::Lite if XML::Parser cannot be found. This will help users who do not have XML::Parser on their system and are unable to compile it. (XML::Parser::Lite is a simple pure Perl module that does have some limitations. Please consult the module's documentation for further information. If you have SOAP::Lite installed you have at least this.)

I ran a few tests against all (yes all) the feeds in the Syndic8 directory that where reachable and had a status of either Syndicated or Awaiting Repair. Just under 10k in all. The success rates, where well-formed XML and did not choke the parser, where encouraging:

Syndicated feeds: 96%
Awaiting Repair feeds: 93.3%

Here is what's new in this release.

• Dropped in RSS liberal parser with minor code edits
• Eliminated version parameter and default
• Eliminated code for fixing malformed XML.
• Minor bug fixes and optimizations (Thanks Chui Tey)
• Added "Exists" and depreciated "If" tags.

Nothing too exciting it is a maintenance release afterall. I promise the next one will be more exciting. Your feedback is welcome. Enjoy.

The Success of Java, an O'Reilly weblog post by Ted Neward, is an interesting viewpoint that I general concur with. Java has not been terribly successful in developing GUI's. The Abstract Windowing Toolkit (AWT) was, and I still believe a mess. (I got burned badly on a couple early projects long ago and never really recovered.) Swing was a noble idea and an improvement, but perhaps an idea, that of write-once-run-everywhere, taken too far. Swing is too "fat" and too complex to be useful. Neward notes that despite Sun's best efforts...

Swing apps "just don't quite look right" to many users--the look and feel just "stands out" compared to other applications for whatever platform you're running, even using the native look & feel for that platform.

This is bad user experience and one that most user-experience saavy developers want to avoid.

Personally, I never understood what the issue was with SWT that provides to a portable interface to the native components of the underlying OS -- other then IBM developed it. J2ME, J2SE's little brother, accepts this in a sense allowing for OEMs to add their own native GUI elements with little chance of portability. Why keep up this fight?

Neward suggestion that Swing be open-sourced is a valid option to consider. At this point they have nothing to lose. Neward writes:

As [Bradley] O'Hearn notes, "Sun needs to realize that the Java platform can't survive against Microsoft indefinitely as a server-side technology only." Particularly, as I've already noted before, the "rich client" (as opposed to the browser-based "thin client") is about to begin a renaissance, and full-featured UIs are coming back in vogue. Not having a rich client technology here would be almost fatal, because it will be far easier to go Java-to-Java client-to-enterprise, rather than .NET-to-Java. If .NET WinForms become the de facto choice for doing client-side development (and WinForms face their own adoption curve, make no mistake, so this isn't a guarantee by a long shot), it'll be very easy to give in to the temptation to just go .NET-to-.NET.

I certainly agree that the "rich client" is about to begin a renaissance. What I would like to see is for Sun to act sooner then later and Java to distance itself from one particular GUI toolkit so the market decide what it really needs. Choice is good. Innovation better.

"Mark Canter asks whatever happened to Microsoft's .Net My Services. Good question." [Kevin Werbach].

I replied:

My only guess, given Microsoft's past track record and comments, is that MyServices is being recast and eventually will emerge with a new a name. Jim Allchin has eluded to MyServices becoming software that customers can deploy and mange themselves as they see fit.

While I too thought "Hailstorm" [the code name for MyServices] was a good though flawed idea, it may have been ahead of its time. I think that Web services adoption by the general computing public has been slower (or perhaps different) then Microsoft had hoped. This combined with Passport and other bits of control-the-world strategy doomed it.

I don't work for Microsoft and have no inside knowledge -- just a well educated guess.

I thought I'd expand on this since its been something on my mind for some time.

The effort, in its initial form, failed to generate any interest because Microsoft has a well established reputation of security flaws and system crashes in addition to ruthless and monopolistic business practices. Developers and corporate entities alike simple did not trust Microsoft to reliably provide a networked service and protect their data. Besides, it doesn't make sense to tightly-control infrastructure whose underpinnings is all about loosely-coupled like Web services.

Despite this setback, I think the rest of the software industry needs to continue paying attention to this effort because Hailstorm may be down, but not out.

Based on the feedback it received on its initial plan, Microsoft is "back in the lab" rethinking Hailstorm. Based on statements made in the press by Microsoft, its customers where interested in the technology, but wanted to be able to host it on its own intranets.

This makes sense. It gives firms the control and increased confidence to move forward and deploying Web services. It also seeds the market by allowing any firm, such as a telco, ISP and portals, to become a service provider to compete and innovate. More importantly, it further simplifies and speeds the deployment of Web services in the marketplace by providing reusable plug-and-play functionality that can be easily installed on a network and integrated into solutions. This empowers developers to focus their attention on issues that are unique to their business and industry.

I am a firm believer that the technology industries opportunity is faster and more effective ways to deploy existing technologies and not new and more sophisticated ones. The torrent of specification development and one-upsmanship duels by the major industry players miss this point. There was been an extraordinary amount of new technology products and specifications released in recent years and IT departments are panting to keep up and choking on a lot of it.

Microsoft would have loved to set themselves up to receive on-going monthly payments for a hosted service, but the market isn't so accepting. At least for now. Selling Hailstorm as software could still prove to be successful in proving Microsoft with something more then license and support revenues. If successful in seeding enterprises with plug-and-play network service components based on its .NET technology, Microsoft would have an important foothold into the future backend its been craving. It would also be able to influence Web service application development and even standards over other software vendors.

The Liberty Alliance is effectively providing competition in identity services arena that are considered crucial to the emerging Web services. What about the other services such as calendar or document services? Will the rest of the industry have a response when Hailstorm re-emerges?

The notion of plug-and-play network service components that Hailstorm introduced are a good idea because it empowers developers and seeds the market. MS may be down, having lost the bid to develop another cash cow, but I don't think they are out. Despite the foibles of recent years, Microsoft understands ease-of-use and developer productivity better then any other major player. If my instincts are right and if Microsoft develops a reasonable software implementation that goes unanswered by other, they will have created a significant advantage for themselves in capturing this nascent market.

Only time will tell.

News.com: "From my perspective," Allchin said, "I would certainly like to see a lot more (consumer-oriented Web services). There are some already out there. There are more inside companies. This is happening inside companies, no question. But in terms of customer-facing (sites), does Amazon have a Web services interface? No." Uh, Jim? Maybe you should take a look at this. [Kevin Werbach]

UPDATE: While this comment by Allchin is amusing, the rest of the interview is quite interesting and supports some the points I make in this post.

Rael Dornfest found the time to release blosxom_0+5i his ultra lightweight weblogging tool written in Perl.

If you're a command-line text editor type hacker-- blosxom is for you. I swear by MovableType, but I use blosxom for some tasks where its streamlined simplicity is attractive.

In related news, some of the expected features in the next version of MoveableType (v 2.5) where published. "Keywords/Metadata" field added to entries. Sounds like I may have some work to do soon.

Jon Udell notes Macromedia CTO Jeremy Allaire has created a weblog and starts off with a post on "rich-text" editors developed in Flash MX. Like Jon, this is a topic that has been of great interest to myself in the past. Jeremy links to a review by Flash VooDoo of three of these editors. They show a lot of potential though none of them are exactly what I want.

Today is a rather blustery day in the NYC area. Trash and leaves are swirling and whipping through the air and down the streets. I can see the Hudson River from my home and it's choppy and full of whitecaps. It seems rather appropriate.

I took my daughter to the Liberty Science Center for something to do. (She has a real fondness for the place, especially the Great Toys from our Childhood display. Me too. Their simplistic genius is a wonderful reminder of better times.) It was a ghost town though. I think there was more staff around then spectators. One of the staff came up to us and emphatically thanked us for coming out today. It sullened my mood on a day when I wanted to be upbeat.

I consider myself extremely fortunate, living so close to Ground Zero, having lost little personally -- my commute, my view and a former co-worker I had not heard from in years. I'm rather worn out by the commemoration of 9/11. It’s not that I don't appreciate the magnitude of the event or the incredible loss. It's that I always remember. I just need to look out my window.

I remember and appreciate the life I still have and want to move on.

Here are a few links that I appreciated today:

• Dan Gillmor
• Amy Wohl
• Joel Spolsky
• Mark Pilgrim
• Kevin Werbach

I'm catching up on my weblog reading. Jon Udell posted a response to a message I sent him pointing out that he should use XML's CDATA rather then entity encoded HTML content. (Also known as HTML-escaped content) He goes on to quote the mod_content (an RSS 1.0 extension module) specification allowing for this technique to used. (Good point. Missed that.) Userland's 0.92 format document also states that entity-encoded HTML is permitted. He concludes "clearly entity-encoding fits best with current practice. But I agree that CDATA is more desirable for a variety of reasons."

It may be the current practice, but its one that needs to change. The reasons are many if you're a content publisher or developer:

1. Unnecessary file "bloat"
2. Non-standard XML encoding
3. It can be prone to error
4. CDATA requires less processing

Unwittingly, I was just as guilty of not encoding my RSS as I should. MoveableType's default RSS templates use entity encoded HTML. Tonight I modified those templates and CDATA encoded my RSS feeds. If your newsreader can't handle my feed, please let me know. I am told that some aggregators do not handle CDATA encoded descriptions. If you have trouble reading my feeds now, please let me know.

In the continuing discussion of the future of RSS, Rael Dornfest, RSS 1.0 working group chairperson, addresses Dave Winer's plan to release the final draft of what he is now calling "RSS 2.0." (It was original conceived at 0.94.) Rael writes "I believe what you're hearing from various quarters is that there are mega problems, minor problems, not the least of which is that you're about to cut off some of the most productive discussion on the future of RSS -- both in terms of community and technical details -- in two years."

It seems alot of the action has been at Ben Hammersley's RSS weblog lately and I had been missing out. Ben is collecting questions for Dave Winer on his RSS proposal. The attached comments to his posts have some insightful observations worth reading illustrating the need to stop rushing the design of the specification. Ben also points to Sam Ruby's suggestions for the Userland proposal.

I like Sam's thinking. With agreement on namespaces in principle, I think cleaning up the "core" is a smart idea. Sam's notion of removing (depreciating?) redundant and "optional" tags in modules strikes a reasonable balance to satisfying the divergent opinions. It also simplifies the format.

It does not end the discussion. In fact it raises a major question in my mind that I have not seen discussed directly: What do we break compatibility with? Looking at it another way, what format do we maintain compatibility with? The is not clear in any of the discussions I've read.

RSS 0.91 broke compatibility with 0.90. 1.0 is based on 0.90 while 0.92-0.94 is based on 0.91, but breaks backward computability with it. Proposals by Rael (2 years ago) Sam, Jon, Mark and Shelley (with refinements by Sean Palmer) strike some interesting compromises with varying degrees and types of compatibility with previous formats.

Perhaps it has not been discussed because it is the no-win scenario. Perhaps backward compatability with existing aggregators and toolkit is the key. Nonetheless, it would seem to me that until some consensus is formed on this issue, other discussions cannot be had.

I'd like to be wrong. Am I?

I've completed my RSS article and sent it along for editing. I'm not done with RSS yet as I intend to finish up my work on some RSS facilities for MoveableType.

The debate has continued through the weekend into today with the reported status of "RSS 2.0" and its roadmap ranging from "frozen/last call" to "have we started yet?"

Mark Pilgrim continues to collect and report many interesting posts and viewpoints on the debate here. Sam Ruby points to three different viewpoints, noting one example where the extremely rushed design process has been disappointing with its results.

On a personal level, I found today terribly confusing and disheartening. Who is this shadow committee making these decisions? What is the truth of the matter? "I feel like Fox Mulder" I quipped in one of those emails.

If RSS 2.0 is to be taken seriously it will need to be the community's specification, designed by the community through discussions and debates in a community forum like a mailing list. If its not, we may as well stop trying to further a simple extensible syndication format for the Internet.

This rushed design process of this increasingly vital format simply will not stand.

Sam Ruby writes "Lots of really, really, really good progress on RSS.  Now, I'd like to make a plea.  Slow down."

I'll second Sam's motion!

Since we are, as Jon Udell put it, "...still at the beginning of the RSS adoption curve", it doesn't seem logical to just say "what's done is done" and continue to build on a shaky foundation. Backwards compatability should be a concern --- some transitional and depreciation work is warranted to start straighten the path forward.

I don't think full backward compatibility is possible with all of the RSS formats that have been published. For instance .9 and 1.0 use <rdf:RDF> as their root while the other .9x formats use <rss version="">.

My first article for the O'Reilly Network, "Flash MX and the Bigger Picture: Lightweight Internet Applications" was published today. Its the expansion and refinement of my past thinking here and elsewhere.

This past week, I've been up to my eyeballs in the delights of RSS feeds. I'm currently for an article and my work to further the MoveableType RSSFeed plugin. I've also been following the rapid fire and some times fierce discussion of how RSS should move forward. Keeping tabs on this discussion has been a full time job. Its been disheartening see such an acute level of acrimony with little relevenance to the mission of RSS. Today the path forward began to come into focus. Here are some of the more insightful, level-headed posts to note.

• Jon Udell: RSS olive branches
• Seth Bokelman: "my tips/demands of web sites that publish in RSS"
• Mark Nottingham: RSS Tutorial for Content Publishers and Webmasters
• Jon Udell: The mission of RSS
• Eric van der Vlist: Time to move along?
• Rael Dornfest: RSS: Let a 1,000 flowers bloom, and all that

My hope is for a social engineering miracle to allow it to happen now.