Consider Eliyon, a company that's gathered public information about more than 22 million people to support sales, recruiting, and other applications. As it turns out, I am several of those people. In addition to my current title, InfoWorld Test Center lead analyst, I show up as executive editor of Byte Magazine and contributor to Linux Magazine. And while those were once accurate descriptions of me, I have never been a member of Blue Titan's board of advisors, and I am not the inventor of RSS.

It's true I could register with the site, coalesce my correct identities, and purge the wrong ones. But authenticating with a credit card in order to update a profile that Eliyon owns is a nonstarter for me. Back in June, on my weblog, I suggested the alternative that would suit me: I'll maintain my own profile on the Web and syndicate my data to anyone who needs it.

Semantic Web naysayers think people and organizations can't be bothered to assert machine-readable facts about themselves. And, today, that is undoubtedly true. But when others assert facts about you -- as they increasingly will -- the tide could begin to turn. Individual acts of self-defense may ultimately combine to bootstrap the semantic Web. [Full story at InfoWorld.com]

I was reminded of the twin themes of this column -- digital identity and the semantic web -- when Sean McGrath pointed to John Sowa's essay The Law of Standards which states:

Whenever a major organization develops a new system as an official standard for X, the primary result is the widespread adoption of some simpler system as a de facto standard for X.

As Doc's article noted, two grassroots alternatives emerged at the DigitalID World conference this fall: IdentityCommons and Sxip Networks. Both, in different ways, aim to empower me to assert facts about myself and to control the syndication of that data. In the case of IdentityCommons, I buy this service directly, licensing a permanent i-name through which I co-ordinate the activities of identity providers and service providers. In the case of Sxip, the service is free to me as an individual -- it's the identity providers and service providers who pay a licensing fee.

In both cases, the reference business model is explicitly that of DNS.

IdentityCommons: "The i-names will eventually be similar to DNS names in pricing, for people in the $10/year range." [IdentityCommons' Owen Davis: ITConversations interview]

Sxip: "Our business model is that member sites pay a fee along the lines of a domain name registration to be part of the network, and a home site pays a fee along the lines of an SSL certificate to be part of the Sxip network." [Sxip Networks' Dick Hardt: ITConversations interview]

As we contemplate the invention of new DNS-like systems, let's bear in mind this wonderful quote from former UUNet chief scientist Mike O'Dell, which I found by way of Tim O'Reilly's blog. In an email to Dave Farber's mailing list entitled "DNS Governance" - the 4 bugs, O'Dell wrote:

the first bug was creating a structure which *needs* governance

the second bug was creating a monopoly to own the structure

the third bug was creating yet another monopoly to provide "governance"

and the fourth bug is not adopting distributed system technology to render the other three bugs irrelevant.

Admittedly that last bit smacks of handwaving. I have no idea whether, or how, "distributed system technology" might finesse the governance issue. But it's a challenge worth pondering.

When a family member underwent a series of minor medical procedures recently, I got a front-row view of the hospital's data entry systems. As I'm sure is also true elsewhere, it wasn't a pretty picture. The ordeal begins at the registration desk where, no matter how many visits you've made recently -- perhaps even on the same day! -- you're required to "verify your information." It's always bugged me to listen to someone read off, from a screen, such facts as date of birth, address, employer, and insurer. But when the procedure is repeated at the surgical registration desk, it becomes a flagrant HIPAA violation. Anyone within earshot is made privy to information the hospital has sworn to safeguard.

Once you're admitted, each exam room and lab that you visit requires its own consent form. They're all identical, so you wind up repeating the same information that you just painstakingly verified, scribbling it onto one piece of paper after another.

...

I've griped before about Microsoft's weird reluctance to saturate the market with copies of InfoPath. And I've suggested that a competitor might leverage open source (Mozilla) and open standards (XForms) to create a ubiquitous next-generation platform for data collection. One way or another, something's got to give. Locating human proxies between customers and our database records isn't cheap, reliable, or secure. [Full story at InfoWorld.com]

We normally think of self-service as a way to reduce cost. Push people to the web, and you can reduce or eliminate human operators. But that view short-changes the affirmative value of self-service. It's a way to restore some of the dignity that is otherwise eroded by institutional protocols. Customers who control their own information feel less helpless. Operators freed from data entry become available for a job worthier of human talent: good old-fashioned customer service.

In his .Net rollout speech four years ago, Bill Gates used the memorable phrase universal canvas to describe this concept. At the time, Internet Explorer's support for open XML and Web standards was still advancing. Now, of course, it's back to business as usual at Microsoft. In the realm of graphics, Longhorn's XAML (Extensible Application Markup Language) turns inward, reinventing SVG rather than supporting it.

It's tempting to conclude that SVG just plain failed. Yet it keeps popping up on my radar screen lately. Case in point: Lighthammer Software's innovative use of SVG. The company's toolkit creates applications for the manufacturing sector, where dashboard-style visualization of meters and gauges is a key requirement. As Lighthammer's CTO Rick Bullotta showed me in a video demonstration, the toolkit can animate user-supplied drawings of these widgets -- if the drawings are provided in SVG format. Tools that export SVG include Adobe Illustrator and open source vector illustration programs such as Inkscape and Sodipodi. [Full story at InfoWorld.com]

Several folks wrote to say, in effect, "Be patient, these things take time." A couple of years ago, I wouldn't have predicted that Mozilla, in the form of Firefox, would stage the comeback that it has. Today, although Firefox neither enables SVG by default nor includes the most up-to-date code from Mozilla's SVG implementation, it seems plausible that these things will come together over the next year or so. There's also been movement on the Adobe front. The current plug-in is version 3, but last summer, Adobe released an preview of version 6. (Versions 4 and 5 were, evidently, stillborn.)

Among the applications that could ultimately drive mainstream use of SVG, mapping seems most compelling. As a developer, I want to be able to fuse data with maps that work like component libraries. As a user, I want to do more than just view those fusions. I want to select subsets, annotate them, copy and paste them, publish them, and intelligently search them. As more devices produce location data and more applications use that data, these use cases will become more obvious.

Patience.

If you've never tried dictation, you can get a sense of how it works by watching a video screencast I made shortly after I installed Version 8 of NaturallySpeaking. The out-of-the-box experience was dramatically better than before. It got even better when I fed the program all the articles and blog entries I've written during the past few years.

...

What I find most interesting about this process is the way in which I train the computer to be an intelligent assistant. Because recognition accuracy is such a difficult problem, dictation software has to pay very close attention to me. It has to learn everything it can about my speech patterns, vocabulary, and writing style. And it must leverage all this information to the maximum degree possible.

Perhaps because we imagine that other application domains are not as challenging, other programs pay strikingly little attention to what we do. Sure, the browser will remember the last thing that you typed into a field on a form, and your e-mail program will help you keep track of whom you've replied to. But by and large, our so-called productivity software does not monitor what we do, is not meaningfully trainable, and does not grow more valuable over time as our relationship with it deepens. We are creatures of habit, but we are ill-served by software that does not notice or respond to those habits. When I organize my e-mail or conduct research on the Web, I exhibit predictable patterns of behavior. We have long expected but rarely experienced personal productivity software that absorbs those patterns, automates repetitive chores, and can be taught to improve its performance. [Full story at InfoWorld.com]

People reacted to the screencast in quite different ways. It knocked Chris Sells' socks off, and Jeremy Zawodny found it oddly compelling, but Darren Barefoot was underwhelmed. That's understandable. Software whose performance is so intimately related to human performance can't easily be assimilated. The acceptance threshold will vary wildly from one person to the next, and crossing it takes you deeper into cyborg territory.

Richard Sprague, who works on speech technologies at Microsoft, has a chart that illustrates how speech recognition is on the glide path toward becoming "uncannily useful." I'm inclined to agree. It'll be fascinating to compare my 2004 dictation screencast with future editions!

In my October 22 column, I argued that Gmail's aggressive use of dynamic HTML qualifies it as a kind of rich Internet application (RIA). As email correspondents and bloggers pointed out, the technique has a fairly long history. Many many wonder why it remains on the fringe. The reason, I think, is partly a weakness common to all RIA technologies. Whether it's based on DHTML, Java, Flash, .NET, or just a standard GUI, an RIA has a client/server architecture. Unlike a Web application which manages state information almost entirely on the server, though, an RIA achieves a more balanced distribution of that information between client and server. The benefits that flow from this arrangement can include responsiveness, context preservation, and offline capability. To achieve these benefits, though, we have to make some painful tradeoffs.

...

RIAs are protocol-driven. A programmer who masters an application's protocols can extend it or combine it with other applications. But there are no integration hooks available to the user. In a Web application, those hooks are simply URLs. Consider what happens when you include a MapQuest URL in an email to someone. A piece of state information -- namely, the state of the MapQuest viewer when displaying a given location -- has been reduced to a token that one person can hand to another. The same thing can usefully apply to the state of a shopping cart, or an airline reservation.

...

The idea that an application wears its state information on its sleeve, readily available for users to bookmark, modify, and trade, is an underappreciated strength of Web-based software. As the RIA bandwagon picks up steam, let's honor that idea and find a way to move it forward. [Full story at InfoWorld.com]

Over the past few weeks I've discussed this idea with folks at Macromedia and Laszlo. It's related to what Adam Bosworth has been saying recently:

The customers are, very literally, in control. Think of it as democracy versus totalitarianism. This last point showed up almost from day one in the web. The user interface customized itself to the users needs, location, and data in a dynamic way through the magic of dynamic page layout. Today, a full ten years later, most windows apps still don't do that. But heck they are only 2 or 3 or 4 generations evolved. Services, in the last decade, may have evolved 600 times by now all in reaction to what they have learned directly from customer use. [Adam Bosworth]

Flash needs to figure out how to enable this collaboration, fundamentally and pervasively. Likewise DHTML. Likewise Java, .NET, and all the first-generation GUIs.

System administration has always been Windows' Achilles' heel. The graphical tools that simplify basic chores just get in the way when there's heavy lifting to be done. And CMD.EXE, the hapless command shell, pales in comparison to the Unix shells that inspired it. Win32 Perl has been my ace in the hole, combining a powerful scripting language with extensions that can wield Windows' directory, registry, event log, and COM services. But I've always thought there should be a better way.

Jeffrey Snover thought so, too. He's the architect of Monad, aka MSH (Microsoft Shell), the radical new Windows command shell first shown at the Professional Developers Conference last fall.

...

MSH is quirky, complex, delightful, and utterly addictive. You can, for example, convert objects to and from XML so that programs that don't natively speak .Net can have a crack at them. There's SQL-like sorting and grouping. You write ad hoc extensions in a built-in scripting language that feels vaguely Perlish. For more permanent extensions, called cmdlets, you use .Net languages.

With MSH, Windows system administration manages to be both fun and productive. And the story will only improve as the .Net Framework continues to enfold Windows' management APIs. Competitors take note: Windows is about to convert one of its great weaknesses into a strength. [Full story at InfoWorld.com]

Here's a sequence of examples to give you a bit of the flavor of MSH. First, a raw process dump:

MSH> get-process
 
Handles  NPM(K)    PM(K)      WS(K) VS(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    105       5     1224         88    32     0.11   1956 alg
     41       2      816        180    23     0.09   1340 aspnet_admin
     69       3     2336         68    36     0.86    760 cmd
     35       2      860        148    27     0.23   1352 Crypserv
    539       6     1868       2312    27    44.89    556 csrss
    100       5      960       1308    29     1.30   1252 ctfmon
 
...etc...

The console output doesn't show everything that's in the returned set of System.Diagnostics.Process objects, but here's one way to see more:

MSH> get-process | get-member -p
 
Class       Name                      MemberData
-----       ----                      ----------
Property    __NounName                System.String
Property    BasePriority              System.Int32
Property    Company                   System.Management.Automation.MshObject
Property    Container
Property    CPU                       System.Management.Automation.MshObject
Property    Description               System.Management.Automation.MshObject
 
...etc...

Alternatively:

MSH> get-process | out-grid

Or:

MSH> get-process | out-excel

Here are processes using more than 15MB of virtual memory:

MSH> get-process | where { $_.virtualmemorysize -gt 150000000}
 
Handles  NPM(K)    PM(K)      WS(K) VS(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
   2411      89    74680      42572   211 1,176.00    396 firefox
    395      11    32720      14848   272    79.89   3504 msh
    484      18    30180      16012   235   337.41   2068 OUTLOOK
    398      16    19172       1220   173    12.33   3636 WINWORD

Grouped by vendor:

MSH> get-process | where { $_.vs -gt 150000000} | group-object company
 
Count Name                      Group
----- ----                      -----
    1 Mozilla                   {firefox}
    1 -                         {msh}
    2 Microsoft Corporation     {OUTLOOK, WINWORD}

Just selected properties:

MSH> get-process | where { $_.vs -gt 150000000} | pick-object name, path, id, vs
  
name                 path                                 id                  vs
----                 ----                                 --                  --
firefox              C:\\firefox.09\\fi...                 396           220983296
msh                  C:\\Program Files...                3504           285908992
OUTLOOK              C:\\PROGRA~1\\MICR...                2068           245936128
WINWORD              C:\\Program Files...                3636           181805056

Ordered by virtual memory size:

MSH> get-process | where { $_.vs -gt 150000000} | pick-object name, path, id, vs |
sort-object vs -d
  
name                 path                                 id                  vs
----                 ----                                 --                  --
msh                  C:\\Program Files...                3504           285908992
OUTLOOK              C:\\PROGRA~1\\MICR...                2068           245936128
firefox              C:\\firefox.09\\fi...                 396           220983296
WINWORD              C:\\Program Files...                3636           181805056

Results assigned to a variable:

MSH> $v = get-process | where { $_.vs -gt 150000000} | pick-object name, path, id, vs |
sort-object vs -d
 
MSH> $v
 
name                 path                                 id                  vs
----                 ----                                 --                  --
msh                  C:\\Program Files...                3504           285908992
OUTLOOK              C:\\PROGRA~1\\MICR...                2068           245936128
firefox              C:\\firefox.09\\fi...                 396           220983296
WINWORD              C:\\Program Files...                3636           181805056
 
MSH> $v[0].id
 
3504

Results as XML:

MSH> get-process | pick-object name,vs | where { $_.vs -gt 150000000} | convert-xml
 
<?xml version="1.0" encoding="utf-16" standalone="yes"?>
<MshObjects xmlns="http://msh">
  <MshObject ReferenceID="ReferenceId-0" Version="1.1" 
          xmlns="http://schemas.microsoft.com/msh/2004/04">
    <MemberSet>
      <Note Name="name" IsHidden="false" IsInstance="true" IsSettable="true">
        <string>firefox</string>
      </Note>
      <Note Name="vs" IsHidden="false" IsInstance="true" IsSettable="true">
        <int>220983296</int>
      </Note>
    </MemberSet>
  </MshObject>
 
...etc...

Preview a request to kill processes using more than 20MB of virtual memory:

MSH> get-process | where { $_.vs -gt 200000000} | stop-process -whatif
# stop-process on firefox (Mozilla Firefox)
# stop-process on msh (Windows command shell preview)
# stop-process on OUTLOOK (Inbox - Microsoft Outlook)

Large-scale software systems are staggeringly complex works of engineering. Bugs inevitably come with the territory and for decades, the software profession has looked for ways to fight them. We may not see perfect source code in our lifetime, but we are seeing much better analysis tools and promising new approaches to remedy the problem.

TDD (test-driven development) is one increasingly popular approach to finding bugs. The overhead can be substantial, however, because the test framework that ensures a program's correctness may require as many lines of code as the program itself. Run-time checking is another popular approach. By injecting special instrumentation into programs or by intercepting API calls, tools such as IBM's Rational Purify and Compuware's BoundsChecker can find problems such as memory corruption, resource leakage, and incorrect use of operating system services. TDD and run-time checking are both useful techniques and are complementary. But ultimately, all errors reside in the program's source code. Although it's always important for programmers to review their own code (and one another's), comprehensive analysis demands automation.

One compelling demonstration of the power of automated source code analysis is Coverity's Linux bugs database. Viewable online, this April 2004 snapshot pinpointed hundreds of bugs in the Linux 2.6 source code. Coverity's analyzer, called SWAT (Software Analysis Toolset), grew out of research by Stanford professor Dawson Engler, now on leave as Coverity's chief scientist.

In the Windows world, a static source code analyzer called PREfast, which has been used internally at Microsoft for years, will be included in Microsoft Visual Studio 2005 Team System. PREfast is a streamlined version of a powerful analyzer called PREfix, a commercial product sold in the late 1990s by a company called Intrinsa. Microsoft acquired Intrinsa in 1999 and brought the technology into its Programmer Productivity Research Center. Full story at [InfoWorld.com]

For more background on this story, see this set of links I posted to del.icio.us. Although I haven't drawn attention to it until now, this is another aspect of my ongoing quest to bring more transparency and accountability to journalism -- or anyway, to the little corner of the journalistic world that I inhabit when I'm wearing my journalistic hat.

Elsewhere I've outlined my general approach to blog/print synergy. Social bookmarking is a natural complement to that set of strategies. Here are some of the outcomes I foresee:

Passive amplification. By "amplification" I mean using the Net to amplify the effects of my research efforts. Such amplification can occur, for example, when I navigate from my set of sourcecodeanalysis links to everyone's sourcecodeanalysis links. Of course if nobody else is using that tag, as is currently true in this case, then those two sets are identical and I've gained no wider view of the subject.

Recently, though, del.icio.us has added a related-tag feature. So for example I can navigate from judell/sourcecodeanalysis to rickduarte/codeanalysis -- where I'll find some overlapping links but also some new ones.

Active amplification. Passive amplification flows automatically from posting research links in a public place where a correlation engine, such as del.icio.us, can work on them. Active amplification is a new concept I haven't actually tried yet. Here's how it would work. Consider, for example, the reading list I accumulated for a recent feature article on Microsoft security. Because this story was posted on the editorial calendar, I was flooded with email from public relation folk hoping to inject their clients' perspectives into the story. What if I ask people -- and not just PR folk, but anyone with a perspective that ought to be considered -- to route links to a del.icio.us tag that I'll preannounce?

I've already established the prececent of blogging, in advance, the key points I see as relevant to a story in progress, and inviting the story's constituency to help me refine that agenda. The idea here would be to extend that collaborative process to the development of the story's background reading list.

As with all schemes involving a world-writable database, this one will be inherently spammable. But the two-tier arrangement -- everyone's links versus my links -- affords some control.

Here's the protocol I envision:

For a story on TOPIC, I'm collecting links at del.icio.us/judell/TOPIC. To monitor that evolving collection, subscribe to del.icio.us/rss/judell/TOPIC. If you would like to suggest links I've missed, please post them to del.icio.us/YOURNAME/TOPIC. I guarantee that I'll monitor the aggregation of contributed links at del.icio.us/rss/tag/TOPIC. I don't guarantee a response to follow-up email requests. If I judge an item you've posted to be significant, however, you'll see it show up at del.icio.us/judell/TOPIC.

Interesting, eh? Next time I write a big feature story I'll give this a try, and we'll see whether theory translates into practice.

I'd been experimenting for a few months with Gmail, Google's Web mail system, without really taking it seriously. But this week I decided to take the plunge and try using Gmail not only as a mail search engine, but as a replacement for Outlook (on Windows) and Mail (on OS X). Now I'm ready to join the chorus singing the praises of GMail's user-interface technology. Its combination of HTML, JavaScript, and the DOM makes the browser do some remarkable tricks.
...
As early adopters discovered long before I did, there's an architecture behind this JavaScript/DHTML wizardry. The best description I've found is from Johnvey Hwang, who deconstructed Gmail's JavaScript code and created a .Net-based Gmail API. As Hwang described in his July 5 write-up, Gmail loads a JavaScript UI engine into your browser at the beginning of each session. Oddpost, he noted, was the first Web mail application to perfect this technique. That was a prophetic statement: Just four days later, on July 9, Yahoo acquired Oddpost.

Because Gmail's behavior is embedded in the UI engine, all subsequent interaction between the browser and the Gmail service is just an exchange of data. What Hwang calls the DataPack format is not XML, though; it's JavaScript. When you make a request to the Gmail service, whether to refresh your inbox or to modify the list of labels you can attach to messages, the response is a minimal set of JavaScript function calls and associated data objects that the engine uses to update the display.
...
So is Gmail a rich Internet application? Sure. Although that label most often applies to Java, .Net, and Flash clients, Gmail shows that Web clients can join the club too. But crucially, Gmail's architecture is open to other kinds of rich clients, too. It doesn't have to be a zero-sum game. [Full story at InfoWorld.com]

There's been a fair bit of blog commentary about this column. I've also received a number of emails, several noting that even an envelope-pushing Web UI such as Gmail's can be fruitfully enhanced with Java, .NET, or Flash.

I couldn't agree more. This morning, while testing some new screen-recording tools, I cooked up a nice A/B comparison in the application domain of photo sharing. As a test, I made and viewed an album in two¹ different applications. Webshots is a straight HTML/JavaScript app², and Flickr³ is an HTML/Flash hybrid.

Here's the five-minute video: Flash, high-res, 30MB, Flash, low-res, 6MB, QuickTime, high-res, 10MB⁴

I think you'll agree that Flickr's selective and strategic use of Flash is enlightening. So what's this got to do with Gmail and the future of Web UI? I suggest there's no one-size-fits-all solution. In many cases, what will make the most sense is a hybrid application that uses Web 1.0 for all it's worth, pushes the DHTML envelope, and weaves in rich-client technology where it adds the most leverage.

¹ Webshots album here, Flickr album here.

² Yes, I'm aware that Webshots' strong suit is its downloadable/installable photo management application. For my purposes here, though, I'm just exploring what can be done through the Web and on the fly.

³ Full disclosure: I know, and have hung out with, some of the Flickr folks.

⁴ I'm still sorting out the tools situation here. Too many players, too many formats, too many moving parts.

The users of a Wiki think of the process as organic growth. Enterprise IT planners tend to regard it as unstructured chaos. They're both correct. JotSpot's aim is to harmonize these opposing views by empowering users to create islands of structure in their seas of unstructured data. The company's founders, Joe Kraus and Graham Spencer (two members of the original Architext/Excite team), showed me how this works. You write simple Wiki markup to define a form and to display data gathered through that form. When you need to add a new field later, just tack it on. Under the covers, it's all a collection of objects that render as pages and attributes that render as fields.

Of course, there's no free lunch. You pay a price for this kind of flexibility. Systems based on alternative object-oriented styles of data management tend to lack standard query languages, programming interfaces, management tools, and well-defined techniques of schema evolution. These are real problems. But the solutions that address them don't adapt well to the niches where small teams live and work.

An example of a system that is well-adapted to those niches is Lotus Notes. Although it has never meshed cleanly with conventional databases, it has nonetheless enabled programmers -- and quite a few power users -- to create software that deals with idiosyncrasies of data and social context. Internet pundit Clay Shirky calls this "situated software." It's cheap and easy to build, it targets a specific group of people, and it achieves a degree of customization that is not otherwise economically feasible.

I asked the JotSpot guys what will happen if Wiki applications become a maintenance challenge, as did many Notes applications before them. "That's a good problem to have," Kraus said. I agree, up to a point. Messy organic growth is better than no growth, and object-style data makes good fertilizer. In the long run, though, we shouldn't have to make such difficult trade-offs. As object, relational, and XML disciplines converge, all I can say is: Hurry! [InfoWorld.com]

The Wiki lineage traces back to Ward Cunningham's original (and still active) Portland Pattern Repository Wiki. Other Wikis I've used over the years include:

• ZWiki. A Zope-based (and therefore object-database-backed) Wiki.

• TWiki. A popular choice on corporate intranets. As TWiki founder Peter Thoeny reminded me, TWiki's forms capability predates JotSpot's. For a wonderful demonstration of the Wiki way, incidentally, look at this page. The TWiki team compares JotSpot to TWiki; JotSpot CTO Graham Spencer acknowledges TWiki as an inspiration; Spencer makes factual corrections to the comparison; TWiki contributor Crawford Currie in turn acknowledges some of the heavy lifting done by the JotSpot team. How cool is that?

• Socialtext. The first company to commercialize Wiki technology for the enterprise. (See The Social Enterprise.)

Wikis have come a long way, but an equally long road stretches ahead. I'm convinced that creating and managing microcontent will be an important part of the journey. That's why I've instrumented my blog so that you can, for example, find all the Ward Cunningham quotes, and why I find JotSpot's microcontent strategy so interesting. There are still some missing puzzle pieces. In particular, we need content editors and databases that enable people to live comfortably in the zone where documents meet data. Perhaps mainstream awareness of Wiki technology will help drive that convergence.

Led by Michael Howard (among others), Microsoft has embarked on a serious program of reform and claims it is committed to implementing these best practices. The comprehensive effort begins, Howard says, with mandatory training. Within 60 days of hiring, every developer assigned to a product team is indoctrinated with the principles of what Microsoft calls its Security Development Lifecycle.

"The level of security expertise in the marketplace -- in the industry in general -- is abysmally low," Howard says. "So we need to bridge that gap."

Independent experts, including Schneier, Metzger, and Cooper, can't accurately gauge the extent or the effect of these reforms. But they all know people who work inside Microsoft, and they all relay anecdotal reports that there has been real change in the right direction. Could Microsoft's military discipline make it a leader rather than a follower in the quest for more secure software?

Of course, even if Microsoft did everything right from now on, the sins of the past will be with us for many years to come -- and no one believes that Microsoft is doing everything right. The bottom line? We're in a world of hurt because of Microsoft's past practices. That pain can't and won't go away anytime soon. But some of the right medicines are finally being applied, the results are tangible, and there's a reason for Microsoft to stay the course.

"The problem has always been economic, not technical," Schneier says. "It was never in Microsoft's economic interest to make its stuff secure."

But now, as growing numbers of people abandon Internet Explorer for Mozilla Firefox and as organizations look to Linux and OpenOffice.org as alternatives to Microsoft's OS and productivity suite, the cost of insecure software is starting to be felt in Redmond. If that pressure keeps up, we'll all be safer. Eventually. [Full story at InfoWorld.com]

Like religion and politics, security tends to defy rational discussion. Among open source advocates, for example, it's an article of faith that Microsoft is incapable of fixing the mess it has made. There's also a presumption that open source systems and methodologies are inherently more secure simply because they are open source. While I understand the reasons for these views -- and partly agree with them -- I worry when complex issues are reduced to simple credos.

One of the most interesting things I read, while researching this piece, was John Viega's Open Source Security: Still a Myth. He writes:

All in all, in some cases open source may have more eyeballs on it. Are those eyeballs looking for security problems, though? Are they doing it in a structured way? Do they have any compelling incentive? Do they have a reason to focus dozens or hundreds of hours on the problem to approach the level of effort generally given to a commercial audit? The answer to all of these questions is usually no. A good deal of software doesn't get examined for security at all, open source or not. When it does, commercial software tends to receive much more qualified attention.

I think Microsoft's software is neither more nor less inherently securable than open source software. When a source code analyzer was pointed at Microsoft's code a few years ago, it found a bunch of bugs. The same thing happened more recently when another analyzer was pointed at the Linux code. It's just plain hard work to write secure software. Microsoft is handicapped by its history of wrong thinking on the subject. But open source ought not rest on its laurels. Everyone needs to work harder, and more importantly smarter. If Microsoft finally starts to be credible on the issue of security, it's good news for everyone -- including open source. The competition between these two software superpowers will keep everyone on their toes.

The other day I had one of those living-in-the-future moments. An important phone call came in, but the colleague I needed to bring into the call wasn't available, and the caller couldn't wait. So, with the caller's permission, I recorded the call and forwarded it as an MP3 file to my colleague. When she later replayed the conversation, she got crucial points -- both factual and emotional -- that I never could have accurately reported.

VoIP fantasy come true? Not even close. The call came in on a POTS line. I answered on a regular -- not even cordless -- telephone. The integration between the voice and data networks was courtesy of JK Audio's QuickTap.

...

There are dozens of ways in which personal computers can add value to the PSTN. Caller ID screen pops, conference call setup, call logging, voice archiving, and user-programmable IVR (interactive voice response) are just some of the productivity aids that we should all take for granted by now -- but that almost nobody can.

The story of the Bellheads vs. the Netheads is a myth in the primary sense of that word. It explains a real conflict between worldviews in a way most people can easily understand, and that's useful. But we can't believe it literally. If the mammals keep waiting for the dinosaurs to die out, we'll keep missing chances to exploit them. [Full story at InfoWorld.com]

Here's an variation of the example I gave in the column. Recently, while recording a phone conversation, I wanted to bring new participants into the call. On my end of the call, I used three-way calling to bring in another POTS line. On the other end of the call, my partner did the same. Using my Internet-attached computer, I can do all sorts of interesting things with the resulting MP3 file: filter it, edit it, email it, blog it. Just because your phone and computer don't use the same network for audio data doesn't mean your phone and computer can't be usefully combined.

Here's another example: Asterisk, the open source PBX for Linux. It supports various flavors of VoIP. But fundamentally, it's a PBX. You can use it simply to add intelligent control to your POTS lines, and that's just what some folks do.

VoIP is terrific, and it's the future. But that future isn't evenly distributed yet, and won't be for a while. In the meantime, let's not lose sight of the original sense of the phrase computer telephony. It's compatible with, but not necessarily the same as, IP telephony.

"I'm worried about the up-and-coming generation of geeks," a leading Internet innovator told me at a recent tech gathering. "They try stuff, use it, and throw it away. But I don't see many of them inventing new foundation technologies." In other words: rip, mix, burn.

Is this a bad thing? Perhaps quite the opposite. There's no shortage of foundation technologies, and latent within many of them are unanticipated uses. Discovering new ways to use existing technologies is arguably as important as inventing new ones.

...

I don't want to overstate the case, because the architecture of the Web has plenty of limitations, but it's amazing how it continues to be a fertile source of these happy discoveries. In a December 2002 column titled "Nobody Expects the Spontaneous Integration (with apologies to Monty Python), I enumerated the key features of an environment conducive to innovation: Web services (broadly construed), REST, loose coupling, and scripting. It's even clearer to me today that these are the right ingredients.

But somebody has to see what's possible and then make it happen. Lots of key insights require no fundamental new invention, yet remain undiscovered. If it's true that "Generation Z" techies are hardwired to think this way, it would be great. And if they aren't, we ought to be teaching them how. [Full story at InfoWorld.com]

In the physical world we rely on eyewitnesses and increasingly, especially in Britain, on cameras. In the virtual world, according to Dan Geer, we're now approaching a critical fork in the road: "To the left, we surveil people. To the right, we surveil data. I'm arguing for data-level file-tracking because if I have to surveil either people or data, I think it's highly important that we choose to surveil the data, not the people. [Full story at InfoWorld.com]

Everybody who is a leader in the security field today came at it from some other field, because when we all started, you couldn't get trained for this formally.
...
Right now, if we want to extract knowledge, skill, method, technique, you name it, from other fields, this is our last best chance.
...
We do not have time to invent everything we need in security from scratch. We have to steal it from every other field that has something worth stealing.

It's funny how circumstances can change your perception of what's possible. A few months ago, key Microsoft architects were telling me that it would be impossible to decouple the Avalon presentation subsystem from the Longhorn OS. Now they're huddling in conference rooms trying to figure out how to do just that. It makes me wonder what else might turn out to be possible after all.
...
Here's an interesting footnote to the WinFS news: According to John Montgomery, director of product management for the developer division at Microsoft, good old full-text search will play a larger role in Longhorn. Empowering us to find and organize our stuff was, after all, one of the major goals of the project. The early rhetoric discounted full-text search in favor of the highly structured WinFS approach and suggested it would be impossible to deliver the desired benefits any other way. Now architects are huddling in conference rooms trying to figure out how to do the impossible. Of course, Apple had already previewed a similar strategy for the forthcoming Tiger version of OS X. If Steve Jobs can demonstrate Spotlight in 2004 and if Apple can ship it in 2005, Microsoft ought to be able to match that by 2006. [Full story at InfoWorld.com]

For those who discount Microsoft's strategy, that's another link in an evidence chain leading to the conclusion that WinFS will never ship. As I mentioned [1 min, mp3] on last week's Gillmor Gang show, I see no reason to leap to that conclusion. We will want a universal database, with hybrid object/relational/XML capabilities, on the desktop. Microsoft is closer to delivering it than anyone else, and the WinFS delay doesn't change that.

But we also want the Google effects: aggregation, search. As usual, the discussion tends to polarize. We need to get past the clichés -- "structured search trumps freetext search" versus "freetext search trumps structured search" -- and recognize that these are complementary modes that need to work well individually and better together.

Every fourth summer, IT trade pubs write about the technology that powers the Olympic Games. It's always an interesting topic, but apart from an enhanced focus on security, the Athens 2004 stories were little changed from their Sydney 2000 counterparts. And yet, this Olympics was utterly transformed, for me and for a few million other viewers, by TiVo.

Thanks to this cheap, Linux-based appliance, I was able to compress all of the events that interested me into a fraction of the time it would otherwise have taken to watch them. I'll always remember the Athens games as the first TiVo Olympics. Now I'm thinking about ways to make the next one even better.
...
In our world -- where blogs, Wi-Fi, and computer-attached video cameras are the norm -- we've begun to redefine the art of event coverage. If you want to see how the Beijing Olympics should be covered in 2008, visit a tech conference next year. [Full story at InfoWorld.com]

In last week's column, I mentioned del.icio.us, Joshua Schachter's "social bookmarking" service. Since then, I've explored the service more deeply in a series of blog entries. Using del.icio.us, I'm now able to process information in dramatically more efficient ways.
...
In a March 2003 column, I wrote about the challenges of doing publish/subscribe at Internet scale. David Rosenblum, who was then CTO of messaging startup PreCache, had described to me an optimization procedure he called "filter merging." The architecture of del.icio.us lends itself to just that kind of optimization. The combination of several trusted human filters, with respect to some topic of interest, yields a powerful merged filter. [Full story at InfoWorld.com]

I was offline writing this column, at the tail end of vacation, so I missed the big news about Microsoft's delaying WinFS in order to make a 2006 date for Longhorn. It's tempting to observe that my current fascination with del.icio.us (a lightweight, collaborative, web-native metadata system) helps prove that WinFS (a heavyweight, single-user, desktop-bound metadata system) really is the over-engineered solution-in-search-of-a-problem that many people now claim it to be. For what it's worth, I don't think that. If you haven't seen my extended interview with Quentin Clark, the director of program management for WinFS, you may find it a useful read now. Granted, I found that URL by way of this tag. But there's no question in my mind that a smart local datastore has to be part of the equation. Or that the "object/relational/XML trinity" envisioned by Clark is an inevitable and necessary convergence.

It's hard to cry a river for a company like Microsoft, but sometimes they're damned if they don't ("Microsoft never innovates") and damned if they do ("Microsoft never ships").

Next month I'll be giving a talk on social software to an audience of CTOs. To prime the pump, I've been spending some time with two of the newer services in the space: Flickr and del.icio.us. Neither focuses primarily on the six-degrees-of-separation dynamic that drives LinkedIn, Orkut, Friendster, and Spoke. Flickr, as I would explain it to my friends and family, is a way to easily upload and share digital photos. And del.icio.us does the same thing for Web bookmarks.

To CTOs, though, I'd say that both are collaborative systems for building a shared database of items, developing a metadata vocabulary about the items, performing metadata-driven queries, and monitoring change in areas of interest. [Full story at InfoWorld.com]

For example, several of the responses tracked here on del.icio.us also show up here in Bloglines. Fabio Sergio has the explanation:

I've joined the ranks of those using Del.icio.us to keep track of random sightings.
In case you're interested here's freegorifero's Del.icio.us page and its de-rigueur RSS feed.

Update:
The great folks over at FeedBurner have enhanced their SmartFeed to enable Del.icio.us and Flickr users to neatly package their social bookmarks and photos together with their "regular" weblog feed.
This means that freegorifero's weblog RSS feed will now also include freegorifero's Del.icio.us links.
Isn't life wonderful?

Talk about the power of small pieces, loosely joined. [freegorifero]

Here's another interesting ripple effect I noticed. To help me decide which tags to assign to this item I'm now writing, I took advantage of the fact that the column it refers to has been percolating for a week. The tags that the del.icio.us collective applied to that column, excluding those used only once, were as follows:

         del.icio.us: 16
              flickr: 10
                 web:  9
              social:  8
            software:  6
      socialsoftware:  6
           delicious:  6
       collaboration:  6
            metadata:  5
                tags:  4
           knowledge:  4
            taxonomy:  3
knowledge_management:  3
                  km:  3
            internet:  3
          folksonomy:  3
           community:  3
             tagging:  2
      socialnetworks:  2
     social_software:  2
         photography:  2
             network:  2
 knowledgemanagement:  2
               ideas:  2
       collaborative:  2
            articles:  2

del.icio.us flickr socialsoftware metadata folksonomy

At one time or another, nearly every kind of information technology has been judged and found wanting. The failures are often summed up in that most damning of epithets: "It doesn't scale." The reason, of course, is that at one time or another, for one reason or another, every kind of information technology has failed to scale.

Unfortunately for the victims tarred with that brush, scalability is a wildly imprecise term. Applications may be expected to scale up to massive server farms or scale down to handsets. And size is only one axis of scalability. Others include bandwidth, transactional intensity, service availability, transitivity of trust, query performance, and the human comprehensibility of source code or end-user information display.

...

It's tempting to conclude that the decentralized, loosely coupled Web architecture is intrinsically scalable. Not so. We've simply learned -- and are still learning -- how to mix those ingredients properly. Formats and protocols that people can read and write enhance scalability along the human axis. Caching and load-balancing techniques help us with bandwidth and availability. But some kinds of problems will always require a different mix of ingredients. Microsoft has consolidated its internal business applications, for example, onto a single instance of SAP. In this case, the successful architecture is centralized and tightly coupled.

For any technology, the statement "X doesn't scale" is a myth. The reality is that there are ways X can be made to scale and ways to screw up trying. Understanding the possibilities and avoiding the pitfalls requires experience that doesn't (yet) come in a box. [Full story at InfoWorld.com]

Discussions about open source and innovation tend to cluster around two opposing memes. One says that open source can't innovate; the other that only open source can innovate. Both are wrong. Sometimes large, well-funded R&D programs can achieve breakthroughs that lone geniuses can't. And sometimes the reverse is true. Either way, the real innovation of the open source movement is the architecture of participation. It can help turn a good idea -- wherever it came from -- into a best-quality implementation. Software companies that don't choose the open source model have to find other ways to recruit and reward participants. [Full story at InfoWorld.com] [See also: other open-source-related items]

Of course, participation needn't involve programming at all. Much of software's value is created by the community that surrounds it. Such communities can flourish, or not, independently of whether source code is open or closed.

As operating systems consolidate around managed interfaces, they'll choose the Java and .Net VMs, not the Perl, Python, or PHP VMs. But the agility of the dynamic languages and the collaborative energy of their open source communities are two of the pistons that crank the engine of progress. These worlds need to converge -- and at the O'Reilly Open Source Conference there was new evidence that they will. Jim Hugunin, father of Jython (Python for JVM), made a pair of dramatic announcements. He has released the first version of IronPython (Python for CLR/Mono). And by the time you read this, he'll have started his new job at Microsoft. Good hire! [Full story at InfoWorld.com]

Ascher's whitepaper lists a series of challenges for dynamic languages. Topping the list is Lack of strategic vision:

To date, dynamic languages have not been driven by strategic plans. In fact, most successful open source projects (Mono and Gnome being notable exceptions) have enjoyed success in spite of a lack of a long-term plan, let alone a clearly defined vision. The pragmatic, tactical approach to fix what's broken today as opposed to anticipate the problems of tomorrow, has, when combined with the selection processes inherent in the open source ecosystem, led to a survival of the fittest for today's problems, rather than rewarding those with the most compelling vision for future success. It's worth asking if the lack of a plan is guaranteed to be a winning approach in the long term. A good example to highlight here is the different approaches toward newer standards such as SOAP, evident in dynamic languages vs. Java and C#, for example. The dynamic language communities are generally content with letting "someone else" worry about the standards-definition process, and are confident that they'll be able to support them when they are defined and stable. In contrast, Microsoft and Sun have committed significant resources to defining the standard, for clearly competitive, non-altruistic reasons. It is reasonable to expect that the resulting standards have been more influenced by how well they fit with those languages than with languages that got involved late in the standard-definition process. In this case, the combination of strategic planning and the resources of large corporations clearly resulted in shifts in the standard toward more strongly-typed languages. An interesting counter-spin is that dynamic language enthusiasts tend to prefer a different approach to web services over SOAP (namely REpresentational State Transfer, known as REST), which (they claim) is simpler, more pragmatic, portable, robust, and less resource-intensive. [David Ascher]

Shortly before Bosworth left BEA for Google, we met to discuss the Alchemy project. He remarked, in passing, that he thinks there's a 40% chance that SOAP may still fail. I hope he's wrong. We're going to need a fabric of pervasive intermediation, and the TCP/IP of Web services -- that is, SOAP -- will enable that. But we're also going to need a whole lot of agility woven into that fabric. I want middleware that works like Indigo, but I want to program it in a language that works like Python.

A recent survey found that 75 percent of Dartmouth students have shared their network passwords. They like having people who know their password, explained Denise Anthony, a sociologist who spoke at the PKI summit conference I attended earlier this month. "They like having someone who can check their e-mail for them or log them in to places where they're supposed to be."
...
As security technologists, we're easily dazzled by our shiny cryptographic swords. But while we're brandishing our swords, our users -- like Indiana Jones in that famous scene from Raiders of the Lost Ark -- might simply pull out their guns and shoot us. Better security protocols alone can't thwart such game-changing behavior. We need to understand what motivates the behavior and figure out which carrots and sticks will influence it. [Full story at InfoWorld.com]

The takeaway point, for me, is that Dartmouth's team of security researchers includes a non-geek whose role is to try to understand the motivations and behaviors of users. This kind of cross-disciplinary approach is the exception. It should be the norm.

In last week's column, I suggested that individuals and corporations should be the authoritative sources of basic information about themselves. That way, if an application needs my name, address, and phone number, I can refer it to a source that I control and guarantee to be correct. But how many applications really need my name, address, and phone number? Capturing the identity of individuals, along with personal information about them, has become a habit. In a climate of increasing concern about privacy, it's a bad habit we must learn to resist. [Full story at InfoWorld.com]

As I mention in this week's column, the notion of selective disclosure is a core value of Shibboleth, an Internet2 project that's gaining some real traction in the higher-ed world.

What's up with the name 'Shibboleth'? Here's the scoop:

A shibboleth is a kind of linguistic password: A way of speaking (a pronunciation, or the use of a particular expression) that identifies one as a member of an 'in' group. The purpose of a shibboleth is exclusionary as much as inclusionary: A person whose way of speaking violates a shibboleth is identified as an outsider and thereby excluded by the group. (This phenomenon is part of the "Judge a book by its cover" tendency apparently embedded in human cognition, and the use of language to distinguish social groups).

The story behind the word is recorded in the biblical Book of Judges. The word shibboleth in ancient Hebrew dialects meant 'ear of grain' (or, some say, 'stream'). Some groups pronounced it with a sh sound, but speakers of related dialects pronounced it with an s. [Suzanne Kemmer]

What if it were possible -- and convenient -- to affiliate with these groups without giving up personally identifying information? In reaction to registration regimes that are too granular, the bugmenot.com hack abolishes granularity. But maybe there's a middle ground.

Many folks wouldn't want to be reminded how easy it is to convert sparse input into a detailed profile that includes a phone number, a street address, a satellite photo, and driving directions. Re-entering the basic facts each time perpetuates an illusion of privacy. Yet the reality, for many of us, is that these facts are public.

Since I haven't told Google (or any other directories) to delete my records, I've implicitly given permission for Web applications to use that data. Let me now make that permission explicit. I'd be happy if a Web form made intelligent use of public information about me.

I'd be even happier if I could control the source of that data. Public information is a poorly defined concept, after all. There are online directories that still remember an address I vacated five years ago. I'd like to maintain the facts about me that I deem public. When applications need those facts, I'd like to refer them to a service that dispenses them. [Full story at InfoWorld.com]

When I previewed this column last week, it occurred to me that FOAF is an example of a mechanism that empowers users to assert facts about themselves. I don't expect earth-shattering results from the publication of my own FOAF file. But if for now it does nothing more than neatly encapsulate certain facts I'm sometimes asked to produce -- my picture, my bio -- that's useful.

In theory, it would be straightforward for business homepages to adopt a similar approach. They all do the same stuff: About, Company, Products, News, Contact. There's an obvious XML format for News -- RSS -- but not for these other things. It's easy to imagine a virtuous cycle. Companies publish their facts in a structured form. As a result, more directories list them -- and do so more correctly. As a result, more companies are incented to publish XML facts. And yet in practice, this hasn't happened.

Agreeing on a format is, of course, always a huge obstacle. But I suspect the Web design reflexes that we carry forward from the 90s are also getting in the way. It's been a very long time since I visited a company's home page and thought: "Wow, get a load of those DHTML menu effects!" Or: "Nice font!" I'm there for the information, and I'll shred the site trying to find it, grumbling the whole time. I know I'm not the only one who feels this way.

Of course I'm not wholly insensitive to aesthetics. In fact, I worship CSS wizards who can dress a skeleton of structured information in beautiful clothing. But people really hate looking at, or thinking about, that skeleton. Steve Jobs' demonstration of Safari RSS at Apple's recent developer conference was a great example. At one point, he flipped back and forth between the skeletal (RSS) and clothed (Web) views of a page. It was the least compelling moment of the keynote. Jobs himself sounded unconvinced, and the audience responded with silence.

It'd be great if business websites formed a FOAF-like "web of machine-readable home pages." But I don't expect that'll happen anytime soon. When people look at websites through X-ray glasses, they don't like what they see.

The Longhorn cover story ran this week. It includes a main story, an interview with Quentin Clark, and an interview with Miguel de Icaza and Brendan Eich. Here are some outtakes from my interview with Quentin Clark, director of program management for WinFS.

On XML datatypes

We see being able to store structured data (like contacts), semi-structured data (XML), and unstructured data. In the case of a Word document, the XML isn't described by the doc type in WinFS, but the WinFS type defines an XML datatype, you can stick in the XML there, and we can reason over that. A JPEG, when you pull off the excess headers, is just a series of 1s and 0s you feed into an algorithm, that will never be structured. But even within a WinFS type, like a doctype, we allow for all three components to be within an instance of that type. A photo is a good example. We have a picture/photo type, things like what camera model, where the picture was taken, plus the unstructured bitstream. With respect to metadata handling -- and property promotion is only part of that -- we talk about picking the author out of a Word doc, putting it into a WinFS property. We also have property demotion, so coming through the APIs you can reprogram the title of some item, and it finds its way back into the filestream.

Just ignore WinFS types for a second, let's say I don't need no stinking types, I'm gonna build my own. You can make it from scalars, the XML datatype, and a binary field. We've defined the Windows doctype to have the ability to have a filestream as well as an XML datatype. That gives you a lot of power. You can walk up to WinFS, create a scope -- all documents, the whole store -- and then issue XPath queries into items that have XML datatypes, then we can go reason over those things.

On sharing

We want to use synch as a way to enable people to share stuff with each other, and to enable offline experiences. It's the Outlook 11 idea that I'm working always locally -- we're bringing that model to all data. You'll have ability to use any scoping mechanisms -- querying, or explicit wrangling where you drop 16 things into a list -- and say, hey, I want to share this with whatever, another machine or with another person.

Relationships that exist within the scoping are no problem, we know how to rehydrate them on the other end. For relationships outside the boundary, there's a couple of different mechanisms. So if you got the document from me, but I didn't give you contacts, then if you do have that contact, Sarah Wiley, on your end, we'll reconstitute the relationship. If it's not a thing we can positively identify, then it would dangle. But after the PDC we changed the data model to make dangling references not really dangle any more. There was a point where we tried to work through the user experience of finding and showing danglers where we realized hmmm, that sucks, people won't know why are they even doing this. Can we change how we store and model the data so that's not an issue? So you'll have a document, and an author, and the system knows nothing about that author because you don't.

On things being in more than one place

Consider three scenarios. First, I want to keep a list of stuff I need to do today -- a piece of mail, the notes preparing me for this call. Let's assume there's no query-based way to do this, it requires explicit wrangling.

Second: in Outlook 11 I have search folders -- stuff from direct staff, stuff where I'm on the To line, the Cc line -- I use these every day as part of my reasoning over my life. A lot of the reasons you want to do things in that query way imply that you don't want to manually intervene. You wouldn't want to inform the system manually about the To line, although you tell the system that my staff is the following people.

The third case is about where you want things to live, physically. Where they are contained. In Outlook, I have a PST and the OST, which is the reflection of my online Exchange mailbox. No big surprise, the 200MB Microsoft gives me is not big enough to contain all my mail, so I have PSTs to keep stuff. That's a containment thing, where do I want it to actually live? I have a removable hard drive at home, at some point I decide this photo will live there.

So those are the three axes. The limitation of Outlook 11 is that it doesn't allow you to put an item in more than one user lassooing. We want to allow multiple lists, or folders, where you can put the same thing in both. We're removing that Outlook limitation.

We encountered significant design challenges around user experience and expectations, and also problems around the DAG (directed acyclic graph). Consider security. I take an item, it lives in a bunch of folders, what is the security on that thing? Folder 2 has it too, then moves to folder 3. All the way back on folder 1, does the owner have any way to know what's happened? Then there's naming. If I have a doc, call it "jon's doc," created in a single folder, then I want to have it appear twice in that same folder, what is it called? If it's in a second folder, and I delete it from folder 1, then at some point I rename folders and put the doc back, calculating namespaces becomes complex.

On the object/relational/XML "trinity"

Why do you need all three? I take it that it's obvious why you need objects: you program to them. The CLR has given us some language independence, and we've done a fairly good job building an object universe better than we had before, we're strong believers in that. As for XML, there's no argument there either. The big thing isn't turning out to be industry schemas, but the fact that you have this self-describing thing, this is what I can learn about it, and I can reason on it in a programmatic way by pulling it up into an object.

Then there's relational, this is harder to describe. I will observe that nobody has built an XML store that has the level of scale, performance, or capabilities of today's relational stores. It's just true that the relational model has a set of design characteristics that give it performance characteristics that are are just inherent. Doing things in the XML store doesn't give you the same benefit -- and that's not even accounting for the fact that there's so much data in relational stores today.

But we're taking the start of the Yukon XML work, and bringing it into WinFS. Our vision is a marriage of these worlds, this is why they did so much work around SQL/CLR in Yukon. And we've done more since then in the WinFS part of the code.

Yukon doesn't reach the end of the journey, WinFS the client does not, but that's where they're headed. In terms of a data platform, that's what we want. This couples with the discussion of structured, unstructured, and semi-structured data. XPath doesn't make sense with the JPEG bitstream. Having that object/relational/XML trinity over a breadth of datatypes, that's the holy grail, that's completeness.

On WinFS benefits

First, having datatypes in Windows, so you can do things like program around a contact. The shared data is a huge benefit, though admittedly it's tricky to get it right. If you are Eudora or Act, how do we make sure you can plug in and own the contacts that are yours, while ensuring that Amazon can still query into a contact and pull out an address?

Second, the Outlook 11 experience of being always local. So an ISV builds a specialized app for architectural firms. Thanks to WinFS synch, the user can go offline and online. Using rules, if meeting notes come in that talk about changes in plans, he gets an action item.

Third, customized experience. If I drill into docs by Jon about WinFS, I can name that query, reuse it, write rules about it.

Fourth, finding things. How many times do you get the call: "I created this doc, help me find it." You'll never get that call again. If their field of view is too broad, they can narrow it easily. Fulltext search is there. Life will become a lot easier for end users. We had to turn off indexing in XP by default, it was too slow and chatty. When you're chasing the truth, it's hard to do. Being the truth is easier to do. When people come in and make changes, we know about it, we're built on a database.

BPEL (business process execution language) is the XML-based language of Web services "orchestration" -- that is, a means to connect multiple Web services to create end-to-end business processes. Recently, InfoWorld Test Center Lead Analyst Jon Udell interviewed BPEL expert Edwin Khodabakchian about the future of this language. Khodabakchian is CEO of Collaxa, a pure-play BPM startup whose BPM orchestration product has supported BPEL for more than a year. Collaxa was acquired by Oracle earlier this month, and its BPEL Server product is now marketed as Oracle BPEL Process Manager. Full story at [InfoWorld.com]

In this outtake from our interview, Edwin pushes back against the notion that BPEL is overly complex. A lot of the complexity, he argues, has to do with XML Schema, not BPEL itself. He goes on to describe how alternate bindings -- based on WSIF and JSR 208, as well as Indigo -- will extend BPEL's reach beyond SOAP Web services to the full range of legacy protocols.