After I posted yesterday's note about RSS redirection, Dave Winer wrote to remind me that there is a mechanism known to work for both Radio UserLand and NetNewsWire. It looks like this:

<?xml version="1.0"?> 
<redirect>
<newLocation>
 http:\//weblog.infoworld.com/udell/gems/longDescriptionFeed.xml
</newLocation>
</redirect>

If you hit my alternate feed with your browser, you'll see this XML redirect. I'm happy to report that I've just tested it successfully in both RU and NNW. Both adjust the original address to the new one. I'll be interested to know which other readers do, or don't, make the same adjustment.

The reason for the switch is that I wanted to clean up my primary feed. There's no reason for it to contain <content:encoded> anymore, and it confuses NewsMonster. So now, my primary feed is just a short description and an <xhtml:body>. My alternate feed contains the whole body encoded within the description, for folks who want to read the blog in a non-<xhtml:body>-aware aggregator.

Making these adjustments was trickier than I thought it would be. I'm narrating the process here partly so I can remember it later, and partly because it glosses some recent discussion about XML processing[ 1, 2]. There were two parts to the task:

1. Copy the original feed -- that is, what my alternate RSS writer produces. Remove <description> and <xhtml:body> from the copy, and rename <content:encoded> to <description>, in order to create the alternate feed.

2. Modify the original feed in-situ, removing <content:encoded>, to create the standard feed.

I tried three approaches: regular expression hacking, Frontier-style XML hacking, and XSLT.

The regex approach

Despite my earlier regex advocacy, I didn't have much luck. That's partly, I guess, because Radio's regex.dll doesn't think quite like Perl's regex engine. Anyway, it got to be a mess.

The Frontier approach

To use the Frontier-style approach, I started like so:

xml.compile ("c:\\radio\\www\\rss.xml", @rss);

This failed embarrassingly, because (as Dave kindly pointed out) I was trying to compile the filename, not the content. This is the right way to turn your RSS file into a Frontier table:

xml.compile (file.readWholeFile("c:\\radio\\www\\rss.xml"),
@scratchpad.rss);
edit ( @scratchpad.rss );

The edit statement brings up a Frontier editing window, where you can inspect the RSS file as a Frontier table. You can also write code to walk around inside the table, making changes as needed. You have to use special verbs to get at the addresses of the subtables, which I found confusing, but this hybrid interactive/programmatic approach is nifty. It started to add up to a lot of code to do what I wanted, though, so I decided to try things the XSLT way.

The XSLT approach

I started with msxsl.exe, a command-line tool for running XSLT transforms. The first stylesheet, longDescription.xml, was a minor variation on the one that was already transforming my primary feed into my alternate feed (by way of the W3C XSLT service). The only change needed here was to remove <xhtml:body>, so I added this template:

<xsl:template match="xhtml:body">
</xsl:template>

Here's the second stylesheet, xhtmlBody.xml:

<?xml version="1.0"?> 
<xsl:stylesheet 
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
  xmlns:content="http://purl.org/rss/1.0/modules/content/" 
  xmlns:dc="http://purl.org/dc/elements/1.1/" 
  xmlns:xhtml="http://www.w3.org/1999/xhtml" 
  version="1.0">

<xsl:output method="xml" indent="yes" encoding="us-ascii"/>

<xsl:template match="node() | @*">
  <xsl:copy>
    <xsl:apply-templates select="@* | node()"/>
  </xsl:copy>
</xsl:template>

<xsl:template match="//content:encoded">
</xsl:template>

</xsl:stylesheet>

The first template in this stylesheet is something the XSLT geeks call "the identity transform." It just echoes the input to the output. But as you do that, you get the chance to override aspects of the transform. In this case, my second template matches <content:encoded> and does nothing with it. As a result, that element drops out of the feed.

To integrate this with Radio UserLand, I packaged up my two command-line transforms into a CMD file:

c:\\radio\\tools\\msxsl.exe c:\\radio\\www\\rss.xml \\
  c:\\radio\\www\\gems\\longDescription.xml \\
  -o c:\\radio\\www\\gems\\longDescriptionFeed.xml

c:\\radio\\tools\\msxsl.exe c:\\radio\\www\\rss.xml \\ 
  c:\\radio\\www\\gems\\xhtmlBody.xml -o c:\\radio\\www\\rss.xml

Then, I added this line to my alternate RSS writer:

launch.application("c:\\radio\\tools\\fixrss.cmd");

There's one more XSLT stylesheet involved here. The alternate feed's original address invokes longFeed.xml, which used to look a lot like longDescription.xml, but now simply returns the XML redirect.

Here's a tip, by the way. When you're hacking around with your Radio feeds, turn upstreaming off. Otherwise you'll torment your subscribers.

Whew! That was kind of confusing, but I think everything's straightened out now. (Sanity check: is the primary feed valid? Is the alternate feed valid?) As the Perl guys like to say, There's More Than One Way to Do It. Were Radio's regex engine more Perl-like, I'd probably have solved the problem that way. It's a reflex. Were I more accomplished at Frontier XML hacking, I might have gotten the quickest result using xml.compile and friends. In this case, however, XSLT wound up being my weapon of choice. I'm glad to have figured out how to incorporate it into my Radio repertoire.

Finally, I'm really glad to know that RSS redirection works, at least for RU and NetNewsWire.

According to NewsMonster's blog, there's a minor problem with my feed. NewsMonster seems to want to render both the <content:encoded> and <xhtml:body> elements. At this point, I'd just as soon drop <content:encoded>. And I probably will. But in so doing, I'll run smack into a long-unresolved problem. There's still no way to cleanly redirect from one RSS feed to another.

My current (and not well-conceived) strategy is to send <content:encoded> in my feed, and transform it into <description> in the alternate version of my feed. There aren't a lot of people depending on that version, so changing its address won't upset many apple carts. But as I've been reminded several times this week, there's still no solution to this problem. For example, Brian Sobolak wrote to point out that Jim McGee's writing might be of interest to me. Indeed! Jim's was one of the first orange icons on my channelroll. But I missed the announcement that he was moving from the community server to his own address, and so lost track of him.

There was some discussion of this a while back. It's easy to see why these proposals aren't getting over the activation threshold, though. Most people never run into the problem. Those who do run into it maybe once a year.

I've long dreamed of using RSS to produce and consume XML content. We're so close. RSS content is HTML, which is almost XHTML, a gap that HTML Tidy can close. In current practice, the meat of an RSS item appears in the <description> tag, either as an HTML-escaped (aka entity-encoded) string or as a CDATA element. As has been often observed, it'd be really cool to have the option to use XHTML as well. Then I could write blog items in which the <pre> tag, or perhaps a class="codeFragment" attribute, marks regions for precise search. You or I could aggregate those items into personal XPath-aware databases in order to do those searches locally (perhaps even offline), and public aggregators could offer the same capability over the Web. [ O'Reilly Network]

I wound up scooping this article on Monday, because I rolled out xhtml:body sooner than expected. So of course, blog commentary relevant to the article appeared even before the article did -- a curious and delightful inversion. On Sam Ruby's blog, Danny Ayers wrote:

Some very good points made in Jon's piece, though I think it's a bit silly jamming any old XML in and calling it "descriptive markup". We can reasonably assume in this case the implied meaning 'this is the content', but nowhere is it made explicit - no description is given.

I'd like to see more opinions on this, but to me, CSS looks like an excellent bridge technology. It is declarative in nature. If I write <p class="codeFragment"> I am merely attaching a label to that element. I can then, optionally, associate a style with that declaration. But I can use that same declaration for other purposes as well. In particular, I can use it to precisely search code fragments. I've long advocated this dual-purposing of CSS declarations because I think it fits well with how people actually write. I find that people who'll say they have no time for descriptive markup will nevertheless fiddle quite obsessively with presentation. Seems to me that if there can be synergy between the two, we ought to exploit that to the hilt.

Sam Ruby and Don Box have both demonstrated valid RSS 2.0 feeds ( Sam, Don) that include a <body> element, properly namespaced as XHTML. Quietly, last week, I joined the party. My primary feed now includes:

1. A brief <description>.

2. The full text of the item, as an HTML-escaped string, in a <content:encoded> element. ¹

3. The full text of the item, as XHTML, in a <xhtml:body> element

Although it enlarged my RSS feed, the XHTML body shouldn't have affected -- and indeed seems not to have affected -- any existing RSS-aware software. So, what's it good for? In an upcoming O'Reilly Network column, I lay out the case. I want to aggregate feeds into XML-aware databases, and be able to run precise XPath queries against those databases. Given these capabilities, it makes sense to invest in more and better descriptive markup. That, in my view, is how we bootstrap from the existing blogosphere to the semantic web. Not by defining a cosmic ontology. But rather from the bottom up, by building consensus around incremental enrichment of the stuff we write every day.

At the moment, of course, that's just one more theory. So I won't speculate further now. I do, however, want to suggest a way to do the experiment. That boils down to some nitty-gritty implementation details. Here, I'll discuss how to simplify XHTML authoring for Radio UserLand, because that's the blog software I use. I hope users of Movable Type and other platforms will offer similar tutorials.

For me, writing XHTML isn't a big deal. Having abandoned Radio's embedded MS DHTML edit control -- because I'm often working on a Mac nowadays, and also because it sucks -- I just write my blog entries in simple, clean HTML. As a result, they're already very close to XHTML. If you remember to quote all your attributes, and close all your tags (for example, <img ... />, <br />, and <hr />), you're almost there. Of course, I don't always remember that, so I need some help. There's also the nasty problem of bare ampersands and HTML entities, which need to be escaped or altered for XML transmission. Life's too short to deal with this kind of thing; clearly you want some tool support.

I knew, of course, that I wanted to use HTML Tidy, which can not only clean up the worst of the mess that the DHTML edit control makes, but can also be used to XHTML-ify your content. The question was how to integrate it with Radio UserLand's publishing process. I'm happy to report that David Carter-Tod has done the heavy lifting. His Tidy Tool wraps HTML Tidy in a Radio script. (More generally, his tool shows how to spawn any command-line executable from Radio.) To use it, you need a local copy of the HTML Tidy program. Since the instance of Radio that I publish from runs on Windows, I acquired the Win32 version of HTML Tidy, tidy.exe, and put it in Radio's Tools directory along with David's files: tidy.root and tidyconfig.txt.

After some standalone experimentation with HTML Tidy's XML/XHTML output mode, I settled on these tidyconfig.txt settings:

output-xml: true
numeric-entities: true
markup: true

It seemed to me that only the first of these should have been necessary. But without numeric-entities set to true, my HTML entities weren't escaped as they need to be. And oddly, the same thing happened when the markup setting (which pretty-prints the XML output) wasn't set to true. Perhaps an HTML Tidy expert can explain why the first setting alone wasn't sufficient, but in any case, what I show here is working for me.

To initialize David's Tidy tool, I typed CTRL-; to launch Radio's QuickScript editor, entered tidySuite.init(), and clicked Run. This launches a file browser so you can identify the location of tidy.exe, which in my case was c:\\radio\\tools\\tidy.exe.

Next, I tested against some sample postings. In the QuickScript editor, I ran scratchpad.s = tidySuite.clean( "..." ), substituting item texts for "...", and inspected radio.root.scratchpad.s in Radio's database editor. A minor annoyance with HTML Tidy is that it returns complete HTML files, adding <HTML> and <HEAD> and <TITLE> tags if you omit them. In this case, though, only the content of the <BODY> tag is needed, and happily, that's exactly what tidySuite.clean returns by default.

So far so good. Now, how to stuff this XML-ified item into an RSS feed? The new extensibility hooks were almost, but not quite, sufficient to the task. You can do three useful things with these hooks: add namespace declarations to your feed, add channel elements, and add item elements. But when you add an item element, it will automatically be escaped for HTML transmission. That's not what I want here. I really do want to send XML. So, for now, I'm continuing to use the original extensibility hook, which has enabled me to completely replace Radio's RSS writer with a modified version. In that version, here's how I'm adding the XHTML body:

add ("<body xmlns=\"http:\//www.w3.org/1999/xhtml\\">");
add (tidySuite.clean( string ( adrpost^.text) ) );
add ("</body>")

This works. It's a shame, though, not to use the newer, less invasive, more elegant extensibility hooks. If there were a way for item-level callbacks to indicate when angle-bracket-escaping and entity-encoding are not wanted, then you could use this better approach. Of course, for the vast majority of users, a Pref ("Emit XHTML bodies in RSS feed") would be ideal. So would a version of HTML Tidy that's included as a DLL, just as regular expression support is included in regex.dll. But first things first. If some of us try this bootstrap approach, and if it produces real value, then we can make a case for a more general solution. For now, my screen flashes five or six times, as each item on my homepage is processed in a command window -- but there's no real delay, and that isn't a problem.

My next step will be to start aggregating XHTML-aware feeds -- mine, Sam's, Don's, others -- into a database. I want to get a feel for what it's like to search that database with element-level specificity. And then I want to start injecting descriptive markup into my own stuff that will enable me (or you) to search more precisely.

¹ The <content:encoded> element is only used by my alternate feed, which transforms it into <description> for those who prefer reading complete items in RSS newsreaders, rather than the first-paragraph-only truncated <description> I send in my primary feed.

Maybe I'm being naïve, but the inevitable PR discovery of RSS doesn't worry me the way it worries these folks:

So much for RSS The PR People know about RSS now … only a matter of time before it becomes useless. Advertising, PR, and Marketing destroy everything they touch on the internet. [ Lucas Thompson, Sleep When You're Dead]

Attack of the PR people It was only a matter of time before the industry sharks descended on innocent bloggers, coming up with ways to "nudge" them into mentioning their clients' products and services. "Hey, Andrew, as you write about the great victory in Iraq, you might want to let your readers know that those missles were built by Raytheon...." Expect to see more and more of this, ye who run the Big Blogs. [ The Peking Duck]

Here's what the pattern has been:

1) A marketing person is shepherded to a meeting by

  1a) the PR analyst minder, if it's an analyst meeting

  1b) the PR press minder, if it's a press meeting



2) Information is breathlessly conveyed to

  2a) the analyst, who hopes it will help him get quoted by the likes of

  2b) the reporter, who often doesn't know what it's about, but will pass it along



Missing completely from this whisper chain: the people who invented the technology being discussed, and the people who really care and need to know about it. Now, all of a sudden, these two groups can connect directly by way of pub/sub.

I believe journalism can still usefully intermediate. But our information monopoly is weakening. The value of our work never should have depended, and now increasingly will not depend, on privileged access to people and to information. It will, instead, depend on our ability to perform the highest and best functions of publishing: selection, analysis, coherent narrative. If I do that consistently, you'll read me. If I don't, you won't.

I also believe PR can still usefully intermediate. Public relations is about brokering connections. What's new here is the possibility of helping end-to-end connections form. They will anyway. PR's legitimate role is to make the process as frictionless and productive as it can be.

Of course PR will try to game the system. That's part of the job. I expect I'll be asking myself, at some point, whether some executive's or architect's blog was really written by that person, or ghost-written by PR. But I don't think that's going to be an easy Turing test to pass. Direct contact with another mind, over time, has a deep authenticity that is hard (maybe impossible) to fake. The best PR agents I've worked with make those contacts happen. I'm tempted to add: "and then they get out of the way." But it's not that simple.

Beyond merely brokering connections, PR agents assist with communication strategy. Here's where things could start to get really interesting. We are all professional communicators, all the time, but most of us are not very aware of the strategies we could and should employ to be maximally effective. One way to look at PR is as an outsourced provider of such awareness. My $0.02: effective communication strategy is one of those core competencies that you cannot outsource. It's something we'll all need to internalize. Will PR agents become coaches and mentors, helping individuals within companies do that? Again, the best of them already are.

If you build Web-based information systems -- and who doesn't? -- it's a great idea to wrap them in Web services APIs. The more the merrier. By offering a choice between SOAP- and REST-flavored APIs, Amazon embraces diversity. But Amazon is even more inclusive than that. It gets the simple things right. The page that represents a book has a canonical URL that you can construct automatically. It carries basic metadata in standard HTML META tags. These rules seem too trivial to mention. But they are seldom followed, even though they can spell the difference between a healthy information system that integrates with a society of peers and an isolated outcast. Moral: do the simple things. [Full story at InfoWorld.com]

Below you'll find nine examples, one from each of the OPACs currently supported by LibraryLookup. Each example shows a typical URL, and the HTML <HEAD> tag (minus CSS and JavaScript). It's easy to pick on obvious flaws, like a leading <CENTER> tag before the <HTML> tag. But my point, really, is that URLs and HTML metadata are the two most basic kinds of APIs. They are the best ways to encourage unintended use. The failure to recognize them as APIs, and therefore to design them accordingly, is of course endemic. It's not just library OPACs who miss these opportunities. Hardly anyone gets this easy stuff right.

Example 5 is especially ironic. I can envision a glossy marketing sheet with a features checklist, and big green check in the "supports RDF" column. There's even, woo-hoo, a special RDF vocabulary used to describe the browser that fetched the page. Unfortunately, the metadata that would be useful to an integrator -- the title of the book being displayed, its author, its ISBN -- is nowhere to be found.

I'll be giving the keynote at day two of the Open Source Content Management conference. (Dave Winer is keynoting day one.) I've been thinking about elaborating on issues like the ones I touch on in this week's column. The provisional title for the talk: "All you need to know about content management, you learned in grade school." Let me know if that does or doesn't sound useful.

Example 1

<HTML>
<HEAD>
<TITLE>Keene-Link /All Locations</TITLE>
<BASE TARGET="_parent">
<META HTTP-EQUIV="Refresh" CONTENT="600;URL=/search/">
</HEAD>

Example 2

<!-- Start of HTML header portion -->
<CENTER>
<A HREF="/webvoy.htm"><IMG ALIGN=TOP BORDER=0 
 ALT="Start Over" SRC="/images/banner.gif"></A>
</CENTER>
<!-- End of HTML header portion -->
<!DOCTYPE HTML PUBLIC "-\//W3C\//DTD HTML 4.0 
  Transitional\//EN" 
 "http:\//www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>WebVoyage Record View 1</TITLE>
</HEAD>

Example 3

<html><head>
 <meta http-equiv="Content-Type" content="text/html; 
 charset=utf-8">
 <META HTTP-EQUIV="Expires" CONTENT="0"> 
 <title>iPac2.0</title><link 
 title="bannerstyles" href="ipac/css/ipac.css" 
 type="text/css" rel="stylesheet">
</head>

Example 4

<HTML>
<!--Copyright 1996-1999 Data Research Associates, Inc. 
 All rights reserved. Removal of this notice violates 
 applicable  copyright laws.-->
<!--/English/Record.html-->
<META HTTP-EQUIV="REFRESH" CONTENT="900 ;
URL=/web2/tramp2.exe/log_out/A09rr4r4.002?server=1home">
<HEAD>
<TITLE>FLP Catalog - Brief Record Display</title>
</head>

Example 5

<HTML>
<HEAD>
<?xml version="1.0"?>
<rdf:RDF 
 xmlns:rdf="http:\//www.w3c.org/1999/02/22-rdf-syntax-ns#" 
 xmlns:dc="http:\//purl.org/dc/elements/1.0/" 
 xmlns:tal="http:\//www.talis.com/talisxml/schema/1.0/">
<rdf:Description 
 rdf:about=
  "http:\//ustalis.lib.susx.ac.uk:80/www-bin/www_talis32?" 
 dc:publisher="University of Sussex" dc:format="text/html" 
 dc:creator="TalisWeb OPAC" dc:title="www_frame_start.tgml" 
 dc:date="2003-04-08T20:09:01">
<tal:object tal:type="xml-header" 
 tal:browser="Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) 
 AppleWebKit/51 (like Gecko) Safari/51">
</tal:object>
</rdf:Description>
</rdf:RDF>
<TITLE>TalisWeb Opac</TITLE>
<META content="www_frame_start.tgml" name=page>
</HEAD>

Example 6

<HTML>
<HEAD>
<TITLE>Title Information</TITLE></HEAD>

Example 7

<HTML>
<HEAD>
 <META http-equiv="Content-Type" content="text/html; 
  charset=iso8859-1">
 <meta http-equiv="cache-control" content="no-cache">
 <meta http-equiv="pragma" content="no-cache">
<TITLE>Katalog der Universitätsbibliothek der TUHH - 
 Search Full Title</TITLE>
</HEAD>

Example 8

<HTML DIR="LTR">
<HEAD>
 <TITLE>[WebCat] Unicorn</TITLE>
 <META http-equiv="refresh"
 content="3540; 
URL=http:\//verdi.seattleu.edu/uhtbin/cgisirsi/41660019/58">
</HEAD>

Example 9

<html xmlns:msxsl="urn:schemas-microsoft-com:xslt"
 xmlns:PACFfuncs="http:\//www.gaylord.com">
<head>
<META http-equiv="Content-Type" content="text/html; 
 charset=UTF-8">
<TITLE>Polaris PowerPAC</TITLE>
<link rel="stylesheet" type="text/css" href=
 "http:\//www.wilinet.wccls.lib.or.us/Polaris/stylesheets/
   PolarisStyles.asp">
</head>

"Do you want to enhance communications with your key audiences?"

RSS holds the promise of becoming a key part of a company's media relations strategy and execution. [ PR Tactics: Using RSS for corporate communications]

The author, Phil Gomes, cites an item I wrote last August entitled Contacting Me: High-tech PR in the age of blogs. I'm delighted to see MediaMap picking up on the ideas expressed there. I've gotten a few calls from readers of Phil's piece asking: "So, what does this mean for how we pitch things to you?" Let's start with the "tactical news distribution policy" that Phil recommends; I've added the column labeled 'value' to indicate what matters most to me:

Topic	Release/RSS	RSS only	value
Quarterly earnings	X		low
Executives' or engineers' commentary on industry trends		X	high
Major product announcement	X		low 1
Minor upgrades or product plug-ins		X	low 2
Keynote or strategic speaking placement at a major tradeshow or conference	X		low 3
Multi-vendor panel participation at a small tradeshow or conference		X	low 4

¹ If it's of interest, the executives and engineers would be talking about it, wouldn't they?

² Ditto.

³ Ditto.

⁴ Ditto.

In short, I don't want you to pitch things to me. And I don't want your clients to pitch things to me either, at least not directly. I do, very much, want them to speak in their own authentic voices, about the technologies and products and services that inspire their passion, to everyone who might have a reason to care. I want your clients to explain what they do, how they think, and why their efforts matter. And so, of course -- and more importantly -- do current and prospective customers.

What's missing from Phil's chart, I think, is an appreciation of how awareness flows through blogspace. Communication, in this view, is a tactical missile launched by a PR agent and aimed at a journalist. News flash: I'm the wrong target. In fact, and counter-intuitively, blogging doesn't aim at any target! Chris Anderson put it nicely the other day:

Blogs are a way to "publish and forget" -- you fire the information out there, and interested people will find it. [ SimpleGeek]

If this seems like too much of a leap of faith, consider how hard executives and engineers already work explaining to one another the nature and value of what they do. Some of this is necessarily confidential. A lot isn't, and when it isn't, the message could (and should) reach a much wider audience. Some of those readers will be journalists who write for print and online. Most won't be journalists -- but a growing number of those folks will write online too. What is known and thought about your clients will emerge from this melting pot of perspectives.

If you're selling a product or service, you have to be able to tell a good story. If you're advising sellers of products or services, you have to help them tell those stories. If you're a journalist, you have to evaluate all the stories and weave them into a coherent narrative. This has always been true. But we never expected all the storytellers to wear real faces and speak with real voices. Now we do.

Back before there were blogs, my groupthink laboratory was the NNTP protocol, which I used at roughly four levels: workgroup (my new media development team at BYTE Magazine), department (the BYTE editorial team), company (all of BYTE), and world (BYTE's public newsgroups). I learned something then that was, and still is, quite difficult to describe -- but critically important. I call it the principle of scoped collaboration, and I illustrated it in a chapter of my book like so:

The crucial insight, for me, was that a new kind of skill is becoming relevant: the ability to make effective use of overlapping scopes. Here's how I put it then:

If I am seeking or sharing information, why do I need to be able to address a group of 3 (my team), or 300 (my company), or 300,000 (my company's customers), or 300 million (the Usenet)? At each level I encounter a group that is larger and more diffuse. Moving up the ladder I trade off tight affinity with the concerns of my department, or my company, for access to larger hive-minds. But there doesn't really have to be a tradeoff, because these realms aren't mutually exclusive. You can, and often should, operate at many levels. [ Practical Internet Groupware]

Today, you can see a great example of this principle of overlapping scopes. Chris Anderson copies some material from his private "work blog" at Microsoft over to his public blog, SimpleGeek, in order to attract outside perspectives into the organization. This is precisely the maneuver that I have found to be powerful, yet elusive to explain. Chris's entry takes a confessional tone. "I don't understand blogging," he writes, and he worries that software will get written before the subtleties sink in. That's a valid concern, and a great issue to raise now that blogware has begun to issue from Redmond. As a matter of fact, though, Chris's take on blogs is spot on:

One reason I believe that blogs are great for corporation internal communication is the question of distribution lists. Inside of Microsoft we live and die by email. However the constant spam of email to large distribution lists ends up drowning out the important information. For many types of communication (but not all) blogs provide a better way of communicating. There are many cases where you as the publisher of a piece of information don't know who would be interested. Blogs are a way to "publish and forget" - you fire the information out there, and interested people will find it. Once I add our internal blog server to the corporate search service, suddenly I could find people that worked on products that I wanted to communicate with. Amazing. [ SimpleGeek]

Even more interesting, at least to me, is Chris's instinctive use of overlapping scopes, and his positioning of himself as a router among them. "This is quoted from my internal blog at work..," he writes, "I know that there are much better experts out there to answer this question...I hope some of them can respond." Bing!

Mårten Mickos

As the CEO of MySQL, the company behind the open-source database, MySQL, Mårten Mickos is leading the company's move into the enterprise market against players such as Sybase, Oracle, IBM, and Microsoft. The company recently announced optimization for the Intel Itanium 2 processor running Linux, directed at large databases, data mining, and other enterprise applications. Jon Udell, the InfoWorld Test Center's lead analyst, spoke with Mickos about dual licensing, modular architecture, and the perception vs. the reality of MySQL. [Full story at InfoWorld.com]

The notion of building what was for me a mission-critical application on open source foundations was a bit radical, and so I actually prototyped on a dual track: Linux/Apache/Perl and the Solid database versus NT/IIS/Perl and the NT version of Solid. In the end I chose the LAP solution. If I had to make the same choice today, I'm not sure which way I'd jump. My solution depended on Apache's mod_rewrite, a technology that's still not mature in the Windows space. On the other hand, the .NET Framework is very appealing. But here's the real point: LAP has morphed into LAMP, and the landscape of choice is different. A key component which did not then play a prominent role in the open source half of the equation -- the database -- now does.