When a journalist blogs

Jeremy Mazner is asking some great questions:

Jeremy's questions were motivated by a series of questions I've been asking about Longhorn. This is part of a strategy I've been using -- since the pre-blog era, in fact, when my medium of choice was NNTP -- to deepen the stories I research for magazines. When the subject is not a secret, I find it extremely helpful to raise some issues publicly and invite a range of interested parties to react to them. A recent example was this entry in support of this story.

In that spirit, I owe Jeremy a response to his questions about my take on WinFS. He asks: "What is an 'XML-centric database' anyway?" A good example of the basic idea -- and the one I've been working with -- is Berkeley DB XML (which has also been adopted by the Chandler project). DB XML supports indexed XPath search, a poweful capability that's now being woven into both RDBMSs with XML support, and "native" XML databases. An even more powerful standard is XQuery, which though not a final recommendation is implemented provisionally in both conventional RDBMSs and native-XML dbs.

We have standard query languages (XPath, XQuery), and standard ways of writing schemas (XSD, Relax), and applications (Office 2003) that with herculean effort have been adapted to work with these query and schema languages, and free-text search further enhancing all this goodness. Strategically, why not build directly on top of these foundations?

Tactically, why do I want to write code like this:

public class Person
  [XmlAttribute()] public string Title;
  [XmlAttribute()] public string FirstName;
  [XmlAttribute()] public string MiddleName;
  [XmlAttribute()] public string LastName;
in order to consume data like this?
    DisplayName="Woodgrove Bank"
    UserTile=".\user_tiles\Adventure Works.jpg">

I believe two things to be true. First, we have some great XML-oriented data management technologies. Second, the ambitious goals of WinFS cannot be met solely with those technologies. I'm trying to spell out where the line is being drawn between interop and functionality, and why, and what that will mean for users, developers, and enterprises.

1 David Clarke, of CapeClear, points out that "this statement, precisely by virtue of its obvious lack of sub-editing ('are', not 'is'), re-inforces the very point it seeks to make!" Delightful! As David mentioned to me in email, there ought to be a word for this reflexive case.

Former URL: http://weblog.infoworld.com/udell/2004/06/15.html#a1023