While it has zero chances of shipping in 2004, this is exactly the premise of Longhorn’s WinFS.


Applications (including but not limited to Outlook V.next) that use WinFS as their store get any number of features from the operating system (query, indexing, replication, o/r-style persistence). These features get tons of attention, mainly because they’re concrete and you can play with them right now (provided you have the pre-release of Longhorn installed on a machine).

To me (and perhaps to Tim), the most important feature of WinFS is that all application data is now transparent. This transparency is the direct result of decoupling the schema and access mechanism for application data from the application itself. In a WinFS-based world, anyone can access an application’s data without having to program/script the application (or even load the application code at all).

WinFS-style data transparency in and of itself is a great thing, but honestly, I’m not convinced that transparency alone is enough to meet Tim’s needs.

To really get out of the roach motel Tim alludes to, common schemas (not just a common schema language) are needed.

Without common schemas, I still need programmer intervention to convert from the schemas used by application X in order to access the data from application Y in any meaningful way.

Getting this right for one-way import is hard enough – it’s considerably harder when application Y wants to make changes that will then be seen by the original application X.

The notion of a common schema reminds me of the REST vs. RPC debate. The RESTafarians argue that having common operations (GET et al) is necessary to achieve a network effect, and that the RPC view of the world results in every endpoint defining its own operations, which requires programmer intervention in order to use a given service.

Though I think their characterization of RPC is a bit naïve (NFS is a great counterexample of a broadly adopted RPC protocol), the argument in favor of common operations is a strong one that I’m extremely sympathetic to (watch this space).

What the REST argument conveniently sidesteps is that had it not been for HTML (a common schema), HTTP (a common set or operations/access mechanisms) would have never registered on most people’s radar.

You really need both common access mechanisms and common specific schemas to get a real network effect going – otherwise you still need programmer intervention to translate at one end or the other.

The notion of defining common schemas inevitably (and quickly) elicits the “how can one entity/organization define once and for all what ‘contact’ looks like” argument. This one requires a combination of technology and good fortune.

The technology issue is easy: if the underlying technology used to define schemas and access data is sufficiently simple and extensible, you have a fighting chance of success.

WinFS looks like it will shake out to be exceedingly simple to work with – this is good news but not sufficient. The key enabler (in my mind) is that the WinFS data model was designed for extensibility as a first principle.

Every schema in WinFS can be augmented by 3rd parties without disrupting the core data model of the original application. The extensibility model is similar (but different) to the RDF model in which external parties can define “buddy” schemas that augment a resource in potentially orthogonal ways.

Will the built-in HYPERLINK "http://longhorn.msdn.microsoft.com/lhsdk/ref/ns/system.storage.core/c/contact/contact.aspx" System.Storage.Core.Contact type be all any application ever needs? Absolutely not. It’s not mean to be (that why extensibility is a first-class concept in the WinFS data model).

Does System.Storage.Core.Contact capture the 80/20 point for what any definition of contact would define anyway? Too early to tell, but anyone with a web browser can look at the current version and hopefully people who actually care will tell the handful of developers with commit access to the source tree what they want changed and why.

As for good fortune, it’s anyone’s guess as to how successful WinFS (or Longhorn, or…) will be. I do think WinFS is a d*mn interesting experiment and I’ll enjoy watching its success (or failure), much of which is predicated on taking a wrecking ball to Tim’s roach motel.

Don Box's Spoutlet