Windows types and universal types

Dare Obasanjo differentiates the WinFS data model from the structures definable in W3C XML Schema as follows:

The WinFS schema language and W3C XML Schema do two fundamentally different things; W3C XML Schema is a way for describing the structure and contents of an XML document while a WinFS schema describes types and relationships of items stored in WinFS. [Dare Obasanjo]
As I see it, there are two major classes of XSD-governed XML documents. Both are well-supported by Microsoft and by other players. First, in the realm of Web services, we have SOAP messages wrapped in WSDL interfaces. Over the past two years, thanks in large part to Microsoft efforts which I've lauded, there's been a shift from an RPC-oriented style of SOAP messaging to the document-oriented style that better suits the coarse-grained, asynchronous, message-driven architectural pattern. XSD is how we define the datatypes and structures in those messages.

Meanwhile, at the intersection of users and data, we have XML documents that people can read, exchange, and interact with. Here too, we've agreed on XSD as a good way to define the types and structures found in these documents. I've long applauded, and forcefully evangelized, the XML Schema support that became available last month in Office 2003.

Finally, I've drawn attention to a remarkable synergy that InfoPath, most notably, makes possible. The message payloads exchanged on the Web services network, and the documents read and written by people, can be the same texts, governed by the same datatype and structure definitions. And those texts are universal in scope, not tied to any platform or framework. True, InfoPath is a Windows-only creature, but since it's built on open standards, InfoPath-like software can exist on other platforms and can interoperate with InfoPath.

We have yet to even scratch the surface of what's possible given these circumstances. And now here comes WinFS with its own proprietary schema language. In recent years, it's been popular to layer innovation on top of base standards. So XSLT, XQuery, and SQL200n all rely on XPath, as WSDL relies on XSD. Yet no base standards beyond XML itself were of use to WinFS? It puzzles me. The things defined in WinFS don't seem exotic or mysterious. "A WinFS Contact type," the docs say, "has the Item super type. Person, Group, and Organization are some of its subtypes." If XSD can't model such things, we're in real trouble.

Of course WinFS does much more than model datatypes and structures. It's a highly sophisticated storage system that supports relational, object, and XML access styles, and that treats relationships among items as first-class objects in themselves (a potent feature I first encountered in the object database world years ago.) Great stuff! But the terminology of the Longhorn docs is revealing. Person, Contact, and Organization items are referred to as "Windows types," presumably because their schemata appear as classes in Longhorn's managed API. But to me these are universal types, not Windows types. I had expected them to be defined using XML Schema, and to be able to interoperate directly with SOAP payloads and XML documents on any platform.

To use XML Schema, Dare suggests, WinFS would have to do one of two things:

  1. Support a subset of W3C XML Schema
  2. Extend W3C XML Schema to add support for WinFS concepts
It seems to me there is lots of precedent for a third approach: use XSD for base datatype/structure definition, and advance a new layered standard (if needed) for relationship definition.

Dare concludes:

Ideally, even though WinFS has its own schema language it makes sense that it should be able to import or export WinFS items as XML described using an W3C XML Schema since this is the most popular way to transfer structured and semi-structured data in our highly connected world. This is functionality is something I've brought up with the WinFS architects which they have stated will be investigated.
Good. That would be a minimal expectation. It's troubling, though, that the architects must be consulted to find out whether Longhorn's "Windows types" will be transferable to standards-based software. Note that such software now prominently includes Office 2003 along with other Microsoft and non-Microsoft apps and services. "Connected" is one of Longhorn's key marketing terms. Yet I am not alone in observing that Longhorn's approach is, in various ways, oddly self-contained.

Former URL: http://weblog.infoworld.com/udell/2003/11/03.html#a838