<buzzword-compliant />

It’s bad enough that mesothelioma, a cancer caused by contact with asbestos, has affected the lives of so many people (and many in my hometown of Baltimore, where Bethlehem Shipyard once was). And it’s bad enough that their suffering enabled Peter Angelos, a personal injury lawyer who specializes in mesothelioma and related asbestos lawsuits, to buy the Baltimore Orioles. But now, as CyberWyre points out, mesothelioma lawyers and “what is mesothelioma” are the two top-paying keyword terms for Google Adsense. Which is leading, of course, to a lot of people with Adsense writing about mesothelioma.

I had two grandparents die of cancer, so I’ve got to say that the idea of profiting from others’ misery is loathsome to me–especially when it’s clear that the kind of things I write about here (application development, Web standards, and general tech company shop talk) do not have the advertising mojo that they once had. Christ, I’ve made all of $22 on AdSense ads in the last year–and I’ve never even seen that money, because Google doesn’t pay you until you hit $100.

But I digress.

If you’re in the publishing business, as I am, you understand the business pressures placed on editorial operations. We like to think that editors shape the content of their publications, and often they do. But on the Web, where everything is measured and moneyballed to death, advertiser demand often plays a significant role in determining what gets covered (especially on business-to-business sites). At less scrupulous companies, it may even determine how it gets covered, but that’s a topic for another time.

So with a trillion “minipreneurs” out there trying to make a buck off a weblog, is it really a surprise that some people chase the ad words? In a way, it’s the way the free market works at its best: supply follows demand, and eventually the demand is met for a reasonable price. So if there’s really a need for information about mesothelioma out there, the least we can do is make sure people get to the right information by Google-bombing the hell out of the relavent links, and maybe someone will reward us for it, right?

Ah, it’s a brave new publishing world. Now if you’re pardon me, I need to go consolidate loans and consider how a refinancing mortgage could help me pay for a tax attorney.

Everybody in IT has their favorite war story, about that time when they were presented with insurmountable odds, asinine deadlines and insufficient resources, but somehow managed to live to tell the tale—or at least went down with their guns blazing. They’re often told with pride, as well as a little gallows humor; IT professionals, it seems, are happiest when the obstacles are close to insurmountable.

It’s part of our psychological makeup (well, at least mine). I got into information technology for the same reason I think most of us are attracted to it: I like solving problems. There’s an endorphin rush associated with getting a new application to work, troubleshooting a network problem, beating a configuration problem into submission, etc. Sure, there’s the glamor, the big money, and the girls who flock to you when you talk about troubleshooting IP address configurations. But mostly, it’s the buzz from making stuff work.

The bigger the problem, the bigger the buzz. When you’ve had your department taking heroic measures to solve an emergency business requirement, working an all-nighter to beat an impossible deadline that the business side needs to seal that multi-million dollar deal or meet that compliance requirement, development queue and process be damned, the power rush can cloud your ability to reason. You and your team nail it and save the company’s bacon, and prove the value of what you do to the rest of the company.

But what if everything suddenly becomes an emergency?

What if, after seeing that you can pull off miracles without following that precious IT process you’ve created, business managers come to expect you to deliver on every project the same way?

Congratulations, your business execs have become IT co-dependent, and you’re their #1 enabler.

There’s a fine line between being “agile” and being an enabler of a dysfunctional business model. You’re agile if you’ve got a process that incorporates flexibility and plans for “ship early and often” approaches to problem-solving. You’re an enabler if you constantly have to go back and fix implementations you rushed to make business deadlines so that they’ll scale or to integrate them into your architecture so you can support them…or if you don’t have the time to do either of those because of more rapidly emerging business requirements.

In an agile IT organization, IT is engaged with the business side, and watching the road ahead. In a co-dependent company, IT is always heads-down and reactive, trying to sprint to meet emerging requirement because business managers didn’t include IT in the decision-making process. A sure sign that you’re headed toward co-dependency is when decisions about projects that affect the technical aspect of their implementation are made at meetings that don’t have someone from IT at the table–or the IT representative is so junior that he or she ends up being cut out of the conversation.

There’s only one way to break a co-dependency cycle: You’ve got to be assertive. Sometimes it takes more personal courage and leadership to balk at another “Charge of the Light Brigade” style project than it does to get your team to once again jump into the breach. When you finally say “no” (or the moral equivalent of it), be prepared for a lot of screaming.

But it’s better than the alternative. Because eventually, if you’re not taking positive control over the project demands your team is faced with–regardless of whether you’re actually successful at jumping through the hoops that the business side of the company constantly presents you with–you’re going to have to face the fact that you’re not going to be able to sustain the pace much longer. While agile organizations have no problem with retaining good people, the smart people at co-dependent organizations are trying to claw their way out.

And if being assertive isn’t an option, maybe you should start clawing.

I just recovered this server from a really hideous .htaccess failure. Since I’m hosting multiple domains on this one virtual server, I had constructed a whole bunch of .htaccess Rewrites to redirect requests to the proper subdirectories. During maintenance yesterday, the .htaccess file got corrupted, and my multidomain housr of cards fell flat–just before I had to leave the office to go visit my wife and son at sleep-away camp (a long story for a different blog).

I couldn’t figure out why the file had gone bad. On inspection, it looked intact; to be sure, I renamed the old file and saved a backup copy to the server in its place. No joy, the site was still sending everything to the root page. Fsk.

Tech support for my host, Powweb, was no help either. “We don’t support .htaccess,” they said. I said that the config had been working for literally years before the failure, and I thought that maybe there was a glitch in the server configuration or there was something wrong with the file system. They “elevated” the call — a fancy way of saying that they would eventually look at it.

So, rather than wait for them, I went back and beat on the server some more in an attempt to evict whatever demon had infested .htaccess. It took about 10 deletions and renames and reloads before I finally got a backup .htaccess file to take properly (or maybe someone rolled back a change they made in server configuration at my hosting company…I’ll never know). So at midnight tonight, I finally had everything where it should be. Sort of.

I’ve added a link to the footer of each post (at least on the main page) that allows you to quickly add articles here to digg.

If you ever doubted that personalities shape the path of technology, all you have to do is look at the checkered history of RSS. Even its acronym is the source of rancor: is it Rich Site Summary? RDF Site Summary? Really Simple Syndication? Any answer is bound to piss someone off.

When Steve Bryant pointed me at Rogers Cadenhead’s blog today, I suspected I was in for another RSS-related rumble. And I wasn’t dissapointed. Cadenhead got a letter from Winer’s attorney last week, threatening legal action over a variety of claims, such as infringement of copyright and a dispute over “third-party information”–other people’s publicly-shared OPML feeds.

Here’s Dave Winer’s side of the story.

Update: Here’s Burningbird’s summation of the whole timeline of this mess.

At its most basic, this is the story of a verbal agreement that went bad. But at another level, this is a fight over the future evolution (or not) of RSS, and something much subtler –if someone makes an API “public”, how public is it? And how open is a standard if someone can come along and slap you with a legal threat when you don’t use it in a way that they like? And just how far can you go using information provided openly by an agreement between two other parties–like an OPML feed, or phone directory listings?

The future of RSS is of more than passing personal interest to me. As the newly-minted director of IT strategy for Ziff’s enterprise group, I have to figure out how to make stuff work together, and right now RSS figures pretty heavily in that. But Atom could just as easily fill that role for my integration purposes, and if the whole RSS process is going to drop dead because of personality issues, I’m going to get as far away from it as I can as quickly as I can.

It doesn’t help any that the entire blogosphere is gathered around Winer and Cadenhead chanting, “Fight, fight, fight!” But then, we’ve seen this happen to people who’ve gotten on the wrong side of Dave before. And inevitably, it makes the higher questions involved subordinate to the battle of personalities. Which means the movement toward fixes in the holes in RSS is going to cease while Dave postures.

Before I go into full rant mode here, it’s time for full disclosure. I once worked with Dave Winer tangenially, as he was a columnist for XML Magazine, of which I was editorial director. I have spoken with Rogers Cadenhead all of twice or three times, more if you include comment threads on blogs and email exchanges (but not much). None of the above qualifies me to be much of anything other than an informed passing observer of either of these guys at the moment. But I do know that Rogers is one of the nicest guys in tech that I’ve ever interacted with, and Dave is…well, Dave.

If you take everything at face value here, the center of the dispute is OPML content. OPML is an outliner format, widely used as a format for exchanging sets of RSS feed subscriptions. We use it on Ziff to package our feeds for easy uploading onto RSS readers, and it’s used by a variety of blogrolling and RSS-based services for similar tasks.

The OPML Factory site that is the main point of this dispute is a port to the LAMP platform of the functionality that Winer had originally run at feeds.opml.org. The site didn’t scale well, so Winer turned to Cadenhead to port it to LAMP. Cadenhead had stepped in to save the bacon for Weblogs.com users who found their Manila blogs dropped when Winer could no longer support them, and had also helped Winer port the Weblogs.com “ping” service to LAMP before Winer sold the service to Verisign.

The two never arrived at a formal contract for the OPML project — the verbal agreement included parntership, says Cadenhead, and the written contracts offered none of that, making his contribution purely work-for-hire. So he refused to sign them, and now Dave wants to take his ball back (plus the $5,000 he paid Cadenhead up front for the work he’s done so far) and go home.

Cadenhead says the third-party data is “open” by agreement–it’s subscribers’ OPML files, which they voluntarily posted to Dave’s defunct OPML service in 2004. But Dave says that the data is not “open” — that people trusted him with the data, and he’s claiming copyright on it.

The dispute is not over OPML itself. OPML is claimed on opml.org as “a trademark of Scripting News Inc.”. The specification for OPML, however, states: “No claim of ownership is made by UserLand to the format it describes. Any party may, for commercial or non-commercial purposes, implement this protocol without royalty or license fee to UserLand. The limited permissions granted herein are perpetual and will not be revoked by UserLand or its successors or assigns.”

The OPML data from subscribers is another matter. Winer’s interest in it is probably fuelled by the indications it provides of what subscribers’ “attention” is trained upon. My former colleague Steve Gillmor, and my boss Mike Vizard, are both big fans of the potential of the “attention economy,” and I’m sure that Winer sees some potential “monetization” of information about what RSS feeds people are subscribing to. And I can see Winer being reluctant to dilute his interest in that cash flow by sharing it with someone who merely stepped up on more than one occasion to save his ass with generosity and programming skill.

But the dispute does have other root causes. In a post I made about RSS advertising recently, I noted that Dave and Rogers were having something of a disagreement about the future of RSS. Rogers wants it to keep evolving, as he thought Dave had intended when he set up the RSS Advisory Board and licensed RSS under Creative Commons, donating the standard to Harvard’s Berkman Center. Dave doesn’t want anybody touching the damned spec, because he says it’s done.

There is no other single person I can point to in the world of web technology who has shaped the development of web standards so much with his or her personal enmity as Dave Winer. If you’re involved in blog or syndication technology, odds are you’ve at least virtually bumped into Winer in some way, and you’ve formed very strong opinions about him. The Atom spec came about mostly because Dave claimed RSS as his intellectual property, and a large set of web developers just couldn’t bring themselves to work with him. Some, like Rogers ,who intially had mostly good things to say about Dave’s knowledge and contributions, have been driven off later by his orneriness.

Scoble weighs in on the competing lynch mobs, or at least on the group that’s been gathering around Rogers’ blog. Mike Arrington, Winer’s former lawyer who is now better known for TechCrunch, takes a driveby potshot at Rogers without any sort of explanation. Rogers responds to Arrington’s comment here.

It’s almost impossible to have a civil conversation over any topic through duelling weblogs. In the end, nobody’s mind is going to be changed about Winer one way or the other. All this argument will do is cast a bigger shadow over further development of the RSS standard for new applications, and we’ll be stuck with whatever proprietary extensions of RSS get hoisted on us by Apple, Microsoft, Yahoo, et al.

And so, I’ll be left with having to deal with a different framework for every point-solution integration point for my syndicated content, podcasts, etc.. All because of a clash of personalities.

Here’s another fun server-side XSLT (Extensible Stylesheet Language Transformations) hack for you. Previously, I talked about the idea of using RSS for loosely coupled content management. Well, I’ve been wanting to do some Web 2.0 mashup kind of stuff, but given that my XPath skills are a lot sharper these days than my JavaScript and AJAX (Asynchronous JavaScript and XML) skills (I still need to find the time to exercise that part of my brain again), I decided I’d attack them from the server side with PHP and XSL instead of writing some pretty browser-choking client-side applet. And the first target of opportunity was Flickr.

I’ve been wanting to add a live feed of my Flickr photo stream to one of my sites for a while. Fortunately, Flickr provides an Atom 0.3 feed (as well as RSS feeds) for each photo stream, so there was already a well-structured XML source to pull the data from. So, using Dreamweaver’s PHP XSLT library, I created a component that pulls in the Atom feed, strips off the extraneous text that gets put in front of each image, and renders the images from the feed wherever I use a <?php include(’flickr.php’); ?> in the page.

In the Atom feed for Flickr, every item starts with the user name and the text “posted a photo:”. So, I wrote an XSL statement using the “substring-after” function of XSLT to prune off the extraneous text. Then I made sure that the image tags in the feed would render properly by disabling output escaping:

<xsl:value-of select=”substring-after(atom:content,’posted a photo:’)” disable-output-escaping=”yes”/>

I didn’t want every photo in my feed to get displayed, so I used a parameter, “ItemsPerPage”, to control the number of items processed by the XSLT. The parameter makes it possible to select the number of images displayed from the feed at run-time. Alternatively, I could use two parameters to select a window of items to display, and use PHP or Javascript code to page through the feed. (I’ll save that for another project.)

Here’s the full XSL file:

<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<!DOCTYPE xsl:stylesheet [
<!ENTITY nbsp ” “>
<!ENTITY copy “©”>
<!ENTITY reg “®”>
<!ENTITY trade “™”>
<!ENTITY mdash “—”>
<!ENTITY ldquo ““”>
<!ENTITY rdquo “””>
<!ENTITY pound “£”>
<!ENTITY yen “¥”>
<!ENTITY euro “€”>
]>
<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” xmlns:atom=”http://purl.org/atom/ns#” xmlns:dc=”http://purl.org/dc/elements/1.1/”>
<xsl:output method=”html” encoding=”ISO-8859-1″/>
<xsl:param name=”ItemsPerPage” select=”4″ />
<xsl:template match=”/”>
<xsl:for-each select=”atom:feed/atom:entry[position() <= $ItemsPerPage]”>
<p><xsl:value-of select=”substring-after(atom:content,’posted a photo:’disable-output-escaping=”yes”/></p>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>

The results of this XSLT can be seen in the right-hand sidebar of the example attention stream page I built in PHP, combining this blog, a del.icio.us feed and Flickr.

For the past month or so, I’ve been busy working deep under the hood here at eWEEK to pull together the worlds of lightweight content management (or, in other words, weblogs) and “enterprise” content management (as in the software guts that drive eWEEK.com) to create a new set of hybrid sites that my colleague Mary Jo Foley jokingly christened “blortals”. They combine the interactive, personal approach of blogs with the stream of news, analysis, opinion and product reviews related to a particular topic from eWEEK and other Ziff publications. And they’re put together almost entirely with RSS and XML Style Language (XSL).

While XML-based client-side browser magic like AJAX is all the rage right now, sometimes simple server-side XML magic is better–especially when you’re dealing with aggregating content from multiple sources, and you want your page to load somewhat faster than continental drift. Besides, syndication formats aren’t just for clients anymore–as the number of applications and services that produce RSS and Atom feeds grow exponentially, the XML syndication formats can provide a quick and easy way to integrate related content from disparate sources. Call it “Loosely-coupled content management.”

For example, take a look at Stan Gibson’s new IBM Watch site. It runs on our weblog server, but it could really run just about anywhere, because almost all of the content is rendered from XSL files that are pointed at RSS feeds from Stan’s weblog, eWEEK.com, and other Ziff sites. In the case of Stan’s site, the inbound IBM news feeds from eWEEK are created by a query against our content management system for any stories where IBM is a related company.

In fact, getting the RSS feeds configured was half the battle. That’s because Adobe’s Macromedia Dreamweaver 8 not only includes a relatively designer-friendly mechanism for adding XSL transforms to dynamic pages, but the actual code components required to do server-side transformations for ColdFusion, ASP, ASP.NET and PHP.

The only real coding I had to do was in XPath language in the XSL files used to define the transforms, to control how many items from each RSS feed are displayed on the page. So, for example, to only get 4 items from a feed, I could just use:
<xsl:for-each select=”rss/channel/item[position() <= 4]”>
…
</xsl:for-each>

And, since in some cases I was able to re-use existing RSS feeds (for example, the “What Your Boss Is Reading” section of the right sidebar of Stan’s site uses the RSS feeds of Baseline and CIO Insight), I also had to strip out the advertisments that get inserted into those feeds.

Thanks to XPath, that’s not a problem, since I was able to insert conditional statements into the XSL. The ads in our RSS feeds all have “ADV” at the beginning of the title, so all I needed was a conditional statement that skipped items starting with ADV:
<xsl:if test=”not(starts-with(title, ‘ADV’))”>

</xsl:if>

Since I wanted to be able to reuse the XSL fragments I created to render other feeds, and wanted to be able to set the number of items rendered and the advertising test string at the time the RSS feed is rendered, I made those values into parameters. Here’s the XSL fragment I used to render the headlines from an RSS feed, linked to their stories:

<?xml version=”1.0″ encoding=”ISO-8859-1>
<!DOCTYPE xsl:stylesheet [
<!ENTITY nbsp “ ”>
<!ENTITY copy “©”>
<!ENTITY reg “®”>
<!ENTITY trade “™”>
<!ENTITY mdash “—”>
<!ENTITY ldquo ““”>
<!ENTITY rdquo “””>
<!ENTITY pound “£”>
<!ENTITY yen “¥”>
<!ENTITY euro “€”>
]>
<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” xmlns:wfw=”http://wellformedweb.org/CommentAPI/” xmlns:slash=”http://purl.org/rss/1.0/modules/slash/” xmlns:dc=”http://purl.org/dc/elements/1.1/“>
<xsl:output method=”html” encoding=”ISO-8859-1″/>
<xsl:param name=”ItemsPerPage” select=”4″ />
<xsl:param name=”advertcheck” select=”ADV” />
<xsl:template match=”/”>
<xsl:for-each select=”rss/channel/item[position() <= $ItemsPerPage]”>
<xsl:if test=”not(starts-with(title, $advertcheck))”>
<a href=’{link}’><h3><xsl:value-of select=”title”/></h3></a>
<p><xsl:value-of select=”description” disable-output-escaping=”yes”/></p>
</xsl:if>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>

So, throw five or six transformations onto a dynamic web page, and before you know it you’ve got a portal. As they used to say in the Ronco ads, “It’s just that easy.”

And, since it’s XSL, that means that I can move the pages that render the feeds to any dynamic server platform I want with minimal recoding– to do a proof of concept, I took a site developed on our .NET-based Telligent blog server and ported it over to a Linux box running Apache and PHP in just under 4 minutes.

I’ve been at Search Engine Strategies the past few days, and I’m feeling a little unclean right now.

When you’re in the content creation business, you like to think that your content will succeed on its own intrinsic merits. Right?

Think again, friend. The days of “build it and they will come” on the Web were over before they ever really started. And the best practices of yesterday — things like META tags and keywords — aren’t enough to cut through the buzzcloud between you and your intended audience.

Search engines have become the new intermediaries (along with A-list bloggers and other big-draw websites), and gaming the search engines is now big business. So to make sure your content, your product, or your service gets noticed-especially when your competitor may already be paying for premium positioning–you’ve got to be increasingly aggressive about jockeying for position in search results. But don’t be too aggressive, or Google will ban your ass like BMW and throw you right out of the search results.

And it’s not enough to just search-engine optimize (SEO) your web pages anymore. With the increasing “verticalization” of searches,if you’ll pardon an Alexander Haig kind of turn of a phrase, you’ve got to make your RSS feeds, podcasts, blogs, and everything else more search-engine friendly as well.

RSS feed SEO is all about volume, according to the experts who spoke at SES–volume of items, volume of content in the “description” tags for each item, and how well you keyword-load the channel title and channel description for your feed.

Podcasts have been notoriously bad at searchability, to the point of satire. But now that RSS feeds are increasinly being crawled by search engines like Technorati (and even Google), what you put into the RSS feed for the podcast can raise its visibility. It’s all about keyword-loading. You still can’t search the contents of the audio, but you can at least make it more likely that people will find the audio to listen to.

But one of the hottest topics among search marketers at SES was social tagging. There was even a whole session at SES on how to leverage del.icio.us and Wikipedia to pimp your website for profit. ( The answer seems to be, “carefully”. Who knew?)

Stephan Spencer of NetConcepts also praised the power of tag clouds as a way to totally keyword-saturate blogs, making them veritable search-engine sandtraps. And just when you thought you’d seen enough spamblogs, search engine marketers just seem to be discovering the power blogs have as search-rank-pimping tools–of course, in a kinder, gentler, less black-hat kind of way. All those luscious inbound links, all those ways to leave legitimate comments (with tasteful promotional links), all of those trackback mechanisms for tree-hugging, non-evil marketers to pollinate with their totally relevant referencing posts…

All this brings new meaning to Google’s “I’m feeling lucky” button. Maybe next year they should hold SES in Vegas.